Age | Commit message (Collapse) | Author |
|
dependency for XLOOKUP and XMATCH because of better compatibility.
The idea is to specify, that the global setting 'search-criteria-must-apply-to-whole-cell'
is ignored and XMATCH and XLOOKUP always behaves as if 'search-criteria-must-apply-to-whole-cell'=true.
That would affect exact search in Match_mode value 0. Users would need to use wildcard or regex
to get a match to part of the content. But removing dependency to the global setting increases
interoperability with MS Excel.
Also the ODF TC will follow that in the final specification of these functions:
https://issues.oasis-open.org/browse/OFFICE-4154
Follow-up commit: 17d578ba91f9c78a0e41d19b58183d2214c0b7a4
(Related: tdf#127293 Add new Match_mode option for XLOOKUP and XMATCH functions.)
Change-Id: I1317865631d2925eaff72e9c1425d93386c3d016
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169582
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Tested-by: Jenkins
|
|
and ScSortedRangeCache classes to support binary search mode in case of
different columns. Which is used by the new XLOOKUP function from now on
in case of binary search mode.
Change-Id: Ibb2ae33670cbe9b47110de57afb6376cd829b465
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166758
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
search than Excel.
Some rework for xlookup binary search in rows to get the correct results
when we are searching with binary mode in rows.
Change-Id: I7ef710c4ae638e2cf5d4bee45810cec7057f5d4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166451
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
|
|
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>
|
|
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>
|
|
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>
|
|
Profiling shows this to be a noticeable cost.
Change-Id: Ib247a75b77d721f2486a1fe50eb243437d865561
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134127
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ifa769e20d91f7899fa81df537a7f3b7aeff52115
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134125
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The idea is that there's a cache for a given range, which keeps
a vector of SCROW items, sorted by values of those cells. This
allows some specific cases of e.g. COUNTIF to simply use
BinarySearch() to find the range that matches and work only with
that. This commit implements using this cache for COUNTIF.
Change-Id: I5b36b289b4aecb3b8245bbb447fbb299371262e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134120
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|