This is intended to handle possibly unallocated columns similarly
to CreateColumnIfNotExists(), but unlike that one this one does not
allocate, if the column is not allocated then the default column
data is returned. This is intended for reading of columns.
Change-Id: Ic3b637eb3d16bac69ebc7ecd389973407db4f7fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140737
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Without this, it may not actually be there, so interning "" would
use a different string instance, and then comparing with
SharedString::getEmptyString() would actually compare non-equal.
Change-Id: I22660f63aa321e3a8f72cfb96df1db56e08fbb84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140402
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Input data to this function is not required to be sorted, so implementing
this would mean sorting it in opencl, which is not exactly trivial and
not worth the effort. There also exist algorithms that find the median
without sorting an array, but they work by guessing it and looping until
their guess is right, so again, not worth the trouble. I'd say there's
nothing to be gained here from using opencl.
Change-Id: Ic6d6efdfc59b9058bdae50d07d8039db481dfb75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140397
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
These mostly exist in "old" and _new variants which are more or less
the same, sometimes there are minor differences. Keep just the _new
ones, everything still seems to work, all tests pass.
Change-Id: I903ea3f11bad6c5e1301febe03974469eb414368
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140396
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
As one of the code comments said the code used string hashes to represent
strings and this was a broken idea. But the basic idea of that is actually
valid, so just implement that properly and use it only for comparing
strings. See the code comment in opbase.cxx for technical details.
Change-Id: I113d6b4d5e1e78bbe2c05aafc0572605e2595ad8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140395
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This is what core does, it also extends the range (the casting to int
variant limited to the range of the int, which the core variant doesn't).
Change-Id: Ib93bc57b38c0927f9732742d116d0f40700a0abb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140394
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
These are quite tricky due to rounding errors, the pown() used
to "shift" the decimal point left-right increases the rounding error,
so this must be compensated for. The round adjustment is based
on rtl_math_round(), the up/down variants check for valid 12 places.
Change-Id: I940f11f4e913665a5248463cf826ab5e5dcbe797
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140368
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
I don't quite see why this one would need such a special handling,
when most other functions (e.g. the very similar HARMEAN()) can do
with just generic handling.
Change-Id: I31f3772ffdf9540178a42f11ae4e376023ad2413
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140257
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
ocVar, ocStDev etc. Besides the copy&paste reductions, these also
need to use fsub_approx() otherwise they can fail with large numbers.
Change-Id: Ic96caaa0d5711d811a27b0e2034db357a71b9fa1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140255
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
- These are hard/impossible to implement properly, since they all
use 'SearchCriteria' argument, which is an expression to be matched,
and already strings are hard in opencl and parsing/evaluating/whatever
an expression would be so complex. Maybe number matching or very basic
expressions would be possible, but not much more.
- The opencl implementations of these are (hopefully) very unlikely
to be ever used, since they generally do not make much sense to be used
in formula groups (except if the result is repeated in the group).
As such, simply remove these, as it's just not worth it.
Change-Id: If007c84c1ff684a94cfce0fe171691d9b3578658
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140250
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Some of the code handling ranges of cells wants empty cells to be zero,
some wants to skip them, and few want special handling. So just make
three generic cases that handle these, which somewhat simplifies this
while still allowing flexibility where needed. Also handle better
Test::testFuncSUMXMY2, which works on a pair of ranges, sets a cell
in one to a value and another is empty, in this case it is necessary
to iterate over this pair with SkipEmpty even if for the second one
it's beyond GetArrayLength().
Change-Id: I6c8edaaadb02ffe2a6a7a9399347909008ea188e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140249
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
These work just like their non-A counterparts, they just also accept
strings and treat them as zeros. So instead of having a duplicated
function for everything, use the basic functions, detect that string
arguments should be treated this way and then convert them in the input
data. This as a side-effect also makes
the ScCalcConfig::StringConversion::ZERO part work (no idea if that's
even been used).
Change-Id: I3385b5363c15b0ae45ff191df00ac357e80bd3c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140226
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Functions_Excel_2016.fods incorrectly used "=AND(Sheet2.C22;C33)"
instead of the correct "=AND(Sheet2.C22:C33)" (colon vs semicolon),
and C33 is an empty cell. The return however was true because empty
cells get special treatment because of Excel compatibility.
Change-Id: I6d0b28280059fd6fc945e77c7b5d714b5e4727a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140224
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This was claiming e.g. =TTEST(A1:A10,B1:B10,1,2) had implicit intersections
because the 3rd and 4th arguments were found to be implicit intersections.
Change-Id: I9cba7e63330dd170ef0ea1ab03d33a653000e669
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140189
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The 'nested' arguments means the value is used inside a loop, which
already implicitly does range checking.
Change-Id: I71ccbded2f9d623f58d11f11316aab28385f1614
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140193
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
formulagroupcl.cxx is already large enough, move away code that
implements some operations and also move some type declarations
to a header.
Change-Id: I28fe59275f4fb89c3e530d77b08e7f2fcad02781
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139971
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
VclCanvasBitmap keeps one around for no good reason, and I don't
feel like digging into it. Since there's no pixel data involved
in that case, let's assume the reader knows that the info about
the bitmap will not change. Making this difference is actually
what I suggested in 0e5b473a63.
Change-Id: I302a9c2c63c8b9474a541a963928933e223f4b45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139873
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The svDoubleVectorRef stuff in OpAnd etc. didn't make sense, those
operators are required to do implicit intersection (which can be done
in sc core in ScCompiler::HandleIIOpCodeInternal()).
Change-Id: Ic970c8e649a651f6a804b5ed265fe2e08ff29681
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139485
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
These function in the base class are protected, and apparently some
GCC versions warn about other overloads being hidden.
Change-Id: I9d2e674b4fc9eedc97f586bbe4e4f21a6954b8a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139161
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
I'm not quite sure what this GetBottom() thing is, but e.g. acosh()
treating empty cell as 1 is not right.
Change-Id: Id86ab979598603c12cec99ec5758c27a99589107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139078
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The default precision of both iostreams and stdio is 6 decimal places.
This means that e.g. =POWER(1.0000001,2) becomes 1, since buf << number
will write that first number simply as '1'.
Moroever some generated code actually doesn't compile because ambiguous
overloads, because '1' is an integer and not a double, thus floor(1)
is ambiguous, as there are only floating point overloads (and C/C++
are stupid about these conversions).
So force using a wrapper class that forces a higher precision and
the decimal separator. For debug builds, also avoid excessive precision.
Apparently, neither iostreams nor stdio are capable of simply printing
a reasonable floating point representation that wouldn't be too precise
or imprecise.
Change-Id: Ifa045712d90e6a6bbe5781ac3c805c989673dc8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139073
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
That is the algorithm that doesn't change colors, BmpScaleFlag::Fast
works the same way only because it's mapped to this algorithm
(which may not necessarily be the case forever).
Change-Id: Ibebfff668eaa1da93963f8e8601fec51cfdfca34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139128
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
That should never happen, as the size should originally come
from the formula group size.
Change-Id: Ic429ef498bb56d589c04a07d0fb44d9841deb19f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139090
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
I have patches rewriting this code to be much cleaner, so this
won't be necessary and it makes it hard to rebase those patches.
Also at least the CheckVariables::CheckSubArgumentIsNan() change
actually makes the code worse.
Change-Id: I5d63c158c6883200e2c6e03d02e00f6672d6a1af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139048
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The normal core implementations use approximate comparison. Also
add the two missing operators.
Change-Id: I98f65b4fed70dd40f9087b6d98696b3bb10ea194
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139053
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This is part of "using string hashes for strings is kind of stupid"
removal. And it seems this is never used for all of Calc's tests.
Just keep it for numeric comparison.
Change-Id: I1c5e3b10c9cacf3d163a675373f14d879a857db8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139052
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Part of removal of string handling in opencl (using the hash here
is not that bad, a hash collision is unlikely, but still).
And the code handles only two conversions (m<->km and sec<->min ?
I'm not even sure). And it seems it's not used a single time
for all of Calc's checks.
It could be added back if there's use for it (possibly with handling
the strings better, e.g. by converting them in the C++ code
to enumeration values passed to opencl).
Change-Id: I65a6ab51d8fb42c09d8a76a1e09f6f5fcbae099a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139051
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
OpenCL code doesn't actually work on strings themselves, but only on their
hashes. And comparing hashes doesn't necessarily have the same result
as comparing the strings themselves.
This is a part of preparation for removal of string handling in opencl,
as the whole idea of handling strings in opencl is probably stupid.
Change-Id: I8fa98bca0af14832f0d76135c1e195e1fb24451a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139050
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
There's no need to check in every loop iteration if the vlookup should
be sorted or unsorted, and this needless branching slows the execution.
Change-Id: I4f3072ddeaf54269cfec51043e84adb2571f0f73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139027
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
VLOOKUP searches only the first column, I have no idea why this was
made to search all of them.
Change-Id: I3297a723a727ba3f56db9bbb320d5b868b247db7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139026
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Before 7674399aac the code tried
to range-reduce all operations except for COUNTIFS, the commit added
handling also COUNTIFS and then later undo the rare cases when it
shouldn't be done, but the undo wasn't specific to COUNTIFS even
though it should have.
Change-Id: Ibdb6516a1ac7bc7d34f16f8a99781859e9fc7b60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138880
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
SwViewShellImp::AddPendingLOKInvalidation() collects invalidations,
but this was relying on something eventually calling
flushPendingLOKInvalidateTiles(), which wasn't guaranteed.
If e.g. a spellchecker caused an invalidation from in idle callback
and nothing else changed, then the LOK callback handling code
didn't know there was something pending. So add an explicit
call to ensure to notify about these pending invalidations.
Change-Id: I0a9cb0d5aba2fdbbac126cd8a4a3412bef1cab25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136531
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
ScFormulaCell::Interpret() tries to interpret the whole formula group
(or the given range of it), but it's not guaranteed, and possibly
just the called cell will be interpreted. So if a specific range
really needs to be interpreted, handle that case.
Change-Id: I7fb563ae471eefd49e5bb6c92b6aff98c42a440e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138741
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This reverts most of commit 09558e2f45,
the problem is that GetNextToken_() resets aToken, overwriting the value
created by this function.
Change-Id: I1daca07a6e01cfecfeff9fbf7c311b0d392d84d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138190
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Glyphs in RTL mode are in reverse, which includes the fast that
a cluster start is last, not first. So going back requires means
going back just one glyph, not a whole cluster. I'm not sure why
I originally did it this way, tdf#148954 works fine even this way,
so presumably I got confused.
Change-Id: I6ed0caf4e64e93e0643f7b88099bc7c992ea3329
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138144
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Otherwise OutputDevice::ImplLayout() might use a temporary cache
just for the subtext while SalLayoutGlyphsCache would use cache
for the whole string, and those two might differ e.g. with an arabic
string starting with numbers when the subset is just the numbers.
Change-Id: Idea7ef277beae07e39e4a714088a7585361d13e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138143
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It is actually needed to process SwViewShellImp's paint region,
as otherwise testTablePaintInvalidate::TestBody from
CppunitTest_sw_tiledrendering will end up in an infinite loop
repeatedly calling SwLayIdle ctor. That's what I tried to handle
in b9c2207e1b and got it wrong.
This reverts commit 2aa2d03ec4.
Change-Id: I25e897ea4e38db48cd969a3c21d677701f75a0aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137293
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
EmbeddedObjectRef::GetGraphicStream() creates a writable
SvMemoryStream, read the graphics data into it and then returns
the stream, which will be afterwards used to decode the graphics.
But if the data is broken, incorrect seeking may cause a seek
way past the buffer, and since the stream is writable, it would
be done and cause problems such as running out of memory.
The VersionCompatRead class is one such place that reads size
from the stream and then seeks based on the read data.
Add SvMemoryStream::MakeReadOnly() that will change the stream
to be read-only after the initial read of the data into it.
Change-Id: I1d44aabaf73071a691adafa489e65e4f5e3f021d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137002
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
When writing out OLE frame, if a picture of it (or is it preview?)
is not available, the code bails out, but that leaves the object
tag unclosed. Since it sets only a warning and so it appears to
be non-fatal, close the tag properly before bailing out.
Change-Id: Ib8a6d692b0c3b4cb9ff5bcfe3c964efdaed3dab0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136962
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Both the documents from the bugreport use COUNTIF where the range
includes the cell itself. So trying to create ScSortedRangeCache
for the range would try to read the values of the cells in the range
including the cell itself, which would try to interpret COUNTIF,
which would recurse and deadlock on the mutex.
Change-Id: I95c33d0b75015dcd1d628740ef52c2d680864791
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136581
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
My fix for tdf#149071 actually disabled the optimization for all
ByValue lookups, because in fact all such lookups have maString set.
So lookups where the cells are a mix of numeric and string values
need different handling. A simple solution is detecting such a mix
when collecting the values for ScSortedRangeCache and disabling
the optimization in such a case. But it turns out that queries
containing such a mix are not that rare, as documents may e.g.
do COUNTIF($C:$C) where the given column has numeric values that
start with a textual header. So bail out only if the string cell
actually could affect the numeric query.
Also fix ScSortedRangeCache usage depending on query parameters,
different instances are needed for e.g. different ScQueryOp,
because the ScQueryEvaluator functions may return different
results (isQueryByString() is automatically true for SC_EQUAL).
Change-Id: Ib4565cbf6194e7c525c4d10d00b1c31707952a79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136403
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
As can be seen at the beginning of ScQueryEvaluator::ValidQuery()
in the for loop condition. Comes from 4fd1333ba4,
and I'm not quite sure if the passed value is really supposed
to be always true or if it's a mistake.
Change-Id: I44bde5d50ac70332d6e48ee583ffed13e664cd61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136396
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The import of pivot tables in xlsx triggers recalculations, even
though it's not necessary. Fixing that properly seems complex given
how ScDPObject is designed, so at least ensure the calculation is
efficient (formula grouping is otherwise done only after pivot
table import). This can especially noticeable for formulas where
groups make a big difference (e.g. COUNTIFS uses ScSortedRangeCache
only for formula groups).
Change-Id: I8dbdf854880707a9707cdc9dc3d73fc1d6b6b000
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136362
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Using just two corners to build the new resulting rect works only
if the new rectangle actually really extends the previous one,
but the <= means that this may compress also rects that are already
contained in the previous rect, in which case it's necessary to
make sure to use union to get the larger coordinate).
Change-Id: Ie4303dfef903bded6d63625531e424a32cc01b06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136144
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The code passes adjusted position for pixel data in order to create
a sub-rect of the pixmap without copying, but at least on Intel Mac
the GC* functions then try to read the entire pixel row even though
it shouldn't be necessary. Since that may cause reading past the
pixmap data if the last line is involved, use entire pixmap width
to avoid that.
Change-Id: Ia08059b363d39dd465b2cadde5138ee045628f59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136003
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It's the same data for all threads, they access it as read-only,
so it doesn't make sense for each thread to build its own copy.
Change-Id: Ia1559c61d976bcce78661cae7e030bb8430aed7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135794
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Luboš Luňák