Age | Commit message (Collapse) | Author |
|
Newly added calc array functions didn't handle empty matrix cells
as empty cells but they were handled as empty strings.
Change-Id: Ie24a38dd8c3f947cfe10ba05b234807891453824
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168591
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
and for the duration of Threaded calculation where there will be
no new formats required we can drive number formatting with the
unlocked RO policy.
Change-Id: Ic0e449acdcf834bc569d13b4a984f13c55316801
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165160
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Id36a104e9d016dfc72477000c3899cf8682ad102
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164007
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
https://issues.oasis-open.org/browse/OFFICE-4156
TODO: add dynamic arrays would be useful: Older array formulas,
known as legacy array formulas, always return a fixed-size result
- they always spill into the same number of cells. The spilling behavior
described in this topic does not apply to legacy array formulas.
More info about it:
https://support.microsoft.com/en-gb/office/dynamic-array-formulas-and-spilled-array-behavior-205c6b06-03ba-4151-89a1-87a7eb36e531
Related Bug: https://bugs.documentfoundation.org/show_bug.cgi?id=127808
Change-Id: I1c3769ef33fa0207f55e1c96083717c2d90402e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163955
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
and
cid#1546474 COPY_INSTEAD_OF_MOVE
cid#1546473 COPY_INSTEAD_OF_MOVE
cid#1546469 COPY_INSTEAD_OF_MOVE
cid#1546467 COPY_INSTEAD_OF_MOVE
cid#1546458 COPY_INSTEAD_OF_MOVE
cid#1546448 COPY_INSTEAD_OF_MOVE
cid#1546446 COPY_INSTEAD_OF_MOVE
cid#1546441 COPY_INSTEAD_OF_MOVE
cid#1546424 COPY_INSTEAD_OF_MOVE
cid#1546377 COPY_INSTEAD_OF_MOVE
cid#1546374 COPY_INSTEAD_OF_MOVE
cid#1546352 COPY_INSTEAD_OF_MOVE
cid#1546334 COPY_INSTEAD_OF_MOVE
cid#1546328 COPY_INSTEAD_OF_MOVE
cid#1546310 COPY_INSTEAD_OF_MOVE
cid#1546303 COPY_INSTEAD_OF_MOVE
Change-Id: I8a43fdd574857ba1d3ec416f23c8269a9a08e12f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160515
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Move the AddSub calculation inside ScMatrix so we
can use an iterator to walk the matrix and avoid lookup
cost for each element.
Shaves 50% off the time spent here in my test sheet.
Change-Id: I171d7dd4ae86419a563342a4120d14106e8d71db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144826
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7ed48c3f1005a0efe42d5378ed25e57ae63dd712
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136346
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I79bd2f0eaa7287f0568366ee5627e11a65d2aec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116717
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The old definition would have unused mnCount s.
The template has been modified to expand functionality.
Redefined operator for sum and sum square.
Memory usage change explanation:
The old code would use an array of IterateResultMultiple.
Then use them to iterate.
The count is stored in a last IterateResultMultiple.
So if we are inputed N operators we are:
Wasting N counters.
Wasting 1 accumulator.
Solution:
We move the array to the accumulator place (inside the structure).
Then we use only N accumulators.
The structure with the array has only 1 counter.
Change-Id: I76de74214d9bcb245f009e1226020bfe4dce40d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115542
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: If094c33d396dc5aba31b37a3042add72076f344f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115468
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7913fd8144d521b8293ac43036d0fad82e457cd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115145
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
May also want implement Kahan sum in there:
sc/source/core/tool/arraysumSSE2.cxx
sc/source/core/inc/arraysumfunctor.hxx
Under some conditions the sum of a pointer type vector
may be perforemed by arraysumfunctor on NumericCellAccumulator.
arraysumSSE2 implements part of it.
This code has been left unmodified.
Why the test has been modified:
The error was: 238.89000000000001 != 238.89
|
17 th digit
IEEE 754 double-precision has 53 log10(2) ≈ 15.955 digits.
So it's just noise.
Change-Id: I6f84826bf3875be4f444f5eb61854bc1f95769bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114627
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
sc, scaddins, sccomp, scripting
Change-Id: Ia99fec9e238033821cb784810edd4762c09bd5db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112049
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
For Excel interoperability this somewhat is a *visual* blank,
unlike ISBLANK() empty strings are counted as blanks. An empty
string in a matrix can be either a formula result transformed to
matrix, or literal input in an inline array. There's no way to
differentiate the origin.
Change-Id: Ib799e95517d95e1a7c28fc4335bd0040f3629ad1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101083
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
This also changes AGGREGATE() 3rd and subsequent parameters'
classification from ReferenceOrRefArray to ReferenceOrForceArray
to force the expected array mode on inline calculations.
Change-Id: I53a5591e46bfbabbfa6a273f5b9590a69fad87a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86388
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
...that trigger -Werror,-Wdeprecated-copy ("definition of implicit copy
{constructor, assignment operator} for ... is deprecated beause it has a
user-declared copy {assignment operator, constructor}") new in recent Clang 10
trunk (and which apparently warns about more cases then its GCC counterpart, for
which we already adapted the code in the past, see e.g. the various
"-Werror=deprecated-copy (GCC trunk towards GCC 9)" commits)
Change-Id: Ie37bd820e6c0c05c74e1a862bb1d4ead5fb7cc9c
Reviewed-on: https://gerrit.libreoffice.org/83698
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie211eea01eaceb718f701d3fdbb6253700d14e5e
Reviewed-on: https://gerrit.libreoffice.org/66831
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6a048a51eacaa7063318cdc27d5bc25cc96d557b
Reviewed-on: https://gerrit.libreoffice.org/65304
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If4ae97b43f012f1770213d99407ffaadac05f9de
Reviewed-on: https://gerrit.libreoffice.org/63756
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes after recent improvements
- remove UNO headers from blacklist
- remove newly found unneeded fw declarations
- fix up some not self contained headers
Change-Id: I605656bc98a64640a78d2ff4de9c7c37326033cf
Reviewed-on: https://gerrit.libreoffice.org/62264
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Icd7a0f9909f36363b307b4fe7ee920183881afbb
Reviewed-on: https://gerrit.libreoffice.org/61576
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ever since
commit b26f83b1cc184a79caa9e9c0ae15717ef61dde4a
Date: Fri Aug 10 21:43:32 2018 +0200
loplugin:unusedmethods
mostly this seems to be fallout from
commit 089a4f245325a5be5cd5951d85305d791b4d9cb6
Date: Mon Aug 6 14:55:04 2018 +0200
remove Calc's software interpreter
Change-Id: Id1cb89bb3d95521b7ddf7d072ee9392053e5a52b
Reviewed-on: https://gerrit.libreoffice.org/61257
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I676a8408e97cc8134009f764736cad68513c89ad
Reviewed-on: https://gerrit.libreoffice.org/58875
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
mostly this seems to be fallout from
commit 089a4f245325a5be5cd5951d85305d791b4d9cb6
Date: Mon Aug 6 14:55:04 2018 +0200
remove Calc's software interpreter
Change-Id: Ib48696e724969a28a7d41155ba1573fd9cd58be6
Reviewed-on: https://gerrit.libreoffice.org/58869
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Removal proposals and fallout management are dealt with here.
Change-Id: I21217fbac071f06987b989e735982b2dfad6a54e
Reviewed-on: https://gerrit.libreoffice.org/55537
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
|
|
... to prevent further confusion what it acually returns.
Follow-up inspection of places where used might be necessary, and
whether an IsEmpty() is used and necessary or an IsAnyEmpty() or
some such would be needed.
Change-Id: I7975a97f0d16442cf195956d148bfb7fbdf89c6a
Reviewed-on: https://gerrit.libreoffice.org/51055
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Nothing else is using it so we don't need it in .hxx
Change-Id: I0df879a7be2c56a70c30f50f44a92bb527b5a9ed
|
|
To 85M elements per matrix. The effective allocation depends on data types and
distribution and is not statically predictable here. Previous limit (allowing
128M elements) in the fuzz case allocated 6.5GB temporarily, it now fails early
with matrix size error. With the case's string data types and changed input
ranges probably still 4GB could be allocated.
Change-Id: I20ab3cf22705bf022f1c8c8e55b1c412380915dd
|
|
Change-Id: Ic648fd2b0a1424aa5ae5d924b29dfd2cb8dddbf9
|
|
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
add method in scmatrix to get Gcd and lcm
modified function scinterpreter::ScGcd() and scinterpreter::ScLcm()
now should be ok
Change-Id: I1e41fa5707bc4b637a986f2fc0a2358ac0121af1
Reviewed-on: https://gerrit.libreoffice.org/34110
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I973c5253b385a5495bec38201655e3dbcb9a6f81
|
|
Change-Id: I5ff214bf1ec9031e30344bc125bc99916fd11bfb
Reviewed-on: https://gerrit.libreoffice.org/28897
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
|
|
Change-Id: I26f46ddac3d7d810ebfa1c3e7f1a77427369828e
Reviewed-on: https://gerrit.libreoffice.org/28451
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
For two reasons:
* introduce a new PushTokenRef() to push an already existing token,
which can be used in several places that currently unnecessarily
copy-construct a new token to be pushed
* prevent unwanted side effects in case a token on the stack would be
fiddled with, which was possible but just by convention wasn't done
Change-Id: I715d81bcba8bdb415af45e889e9f9db1e0ac4888
Reviewed-on: https://gerrit.libreoffice.org/28377
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I2de90e1cdfc4f215f6d7c644e0ab74372a4c2639
|
|
... as GetDouble() returns 0.0 for any string and we don't want to
change that, most relevant places already check for numeric/text
beforehand.
Change-Id: Ifbc04e892f6f504040026042faa38674ced880fb
|
|
and remove that 'using namespace' statement in the header...
Change-Id: I2f994af5088ce6d1ffe92c8d36285a4f6fdd2248
Reviewed-on: https://gerrit.libreoffice.org/24628
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
|
|
Change-Id: Idf00ff11e1aa4a3439e17938570385ee3b25726c
Reviewed-on: https://gerrit.libreoffice.org/24125
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I75c483972db787ea9c941eaac0df023f1929b09c
|
|
Change-Id: I6155b86d0afbefafdf982962ffd0216334834379
Reviewed-on: https://gerrit.libreoffice.org/23425
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Attachment 123203 of tdf#98389 has external references of the form
[1]Data!$1:$1048576
which effectively address the entire cell range of sheet Data and
allocating a matrix for a billion cells attempted to allocate 8GB+xGB of
memory which the system said no-no ...
Some brave soul along the road once decided that a check on the number
of elements wasn't needed anymore and dared to remove it during
refactoring.. This change reintroduces the check and adds it also to
other places that try to instanciate or resize a matrix.
When allocation of a matrix for an external range reference fails it is
checked whether the request is for such nasty entire rows or entire
columns ranges and if so tries to shrink the range to the actual data
area used, which at least in this case helps and works.
Additionally it fixes a long standing bug in the cached area to array
mapping which caused the cache to not be hit but instead the matrix was
aquired over and over again for the same range, causing a serious
performance bottle neck specifically for VLOOKUP and related functions
where the same external range is used in a lot of cells.
Change-Id: I35f67b48e665bf1cc8d672325c32b889f2e05c57
|
|
Change-Id: I202dcc2a2b90ee8ed27815b97a2aad6e4df2f1b9
|
|
Change-Id: Iefffba765ff3e651fa0f6d4067ab3a335ec187c0
Reviewed-on: https://gerrit.libreoffice.org/22456
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I93690dcfefbda9f642b8bbe55b9e2f4f348d446d
|
|
Change-Id: I5491ba0bc44a9ce8844b31126835671c5d5abcaa
Reviewed-on: https://gerrit.libreoffice.org/22386
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
For the operations that we haven't implemented directly in ScVectorRefMatrix
yet, create the ScFullMatrix the same way as we used to do before, and call
the appropriate method of ScFullMatrix.
This commit only moves the code, does not turn the 'throw
std::runtime_exception' into actually using the new ensureFullMatrix().
Change-Id: I336a4ddf07b0b60a5a41036e19c70a44ba575834
|
|
This is a ScMatrix implementation that operates directly on
formula::DoubleVectorRefToken, saving tremendous amount of copying data back
and forth.
Change-Id: I027e6cb668ef40eb474773a0ce8d0eeefc1ab71c
|
|
We want to introduce another type of ScMatrix that will directly contain
DoubleVectorRefToken and operate on that. The idea is that it is pointless to
construct a ScMatrix via lots of copying around, when we already have a nice
array of doubles.
Change-Id: I3e5d7b9e2e0f9b9bf350336a8582cfd852586b3f
|