https://bugs.documentfoundation.org/show_bug.cgi?id=158789
--- Comment #11 from Eike Rathke <er...@redhat.com> ---
(In reply to Mike Kaganski from comment #8)
> and the specific detail
> of the *current* behavior is a real bug: *if* the functions follow ODF spec
> literally (as in "Constraints: Does not accept constant values as the
> reference parameter" on ODF 1.3 6.13.9 COUNTIF, 6.16.62 SUMIF, etc.), then
> it must emit an *error* when user passes inline array with constant values
> in that argument, not a 0 with absent third argument, nor a correct result
> with the third argument present. So the current 0 is a bug from any point of
> view.
Indeed.. the implementation is wrong. In the case of a matrix to be queried and
missing 3rd parameter it iterates over an "imaginary" (likely empty set, didn't
check) cell range.
I don't know if that was trying to mimic some hidden Excel feature nor recall
why it was ever implemented that way (probably because Excel does not support
the array case), it's there since 2009 already, and wasn't handled at all
earlier.
See the else{} block at
https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/interpr1.cxx?r=2e1f9da8#5602
That should be executed only with 3 parameters and a cell range given as 3rd.
To me it looks like a 3rd branch is missing for the case that no 3rd argument
(neither matrix nor cell range) was given, that sums elements of pQueryMatrix
for pResultMatrix conditions fulfilled.
That ScInterpreter::IterateParametersIf() is used for both SUMIF() and
AVERAGEIF(). COUNTIF() has a different implementation and works as expected.
ODFF constraint for these functions is likely there because of Excel. I suggest
to not follow it but rather add a remark in the standard, as more
implementations do support that feature than don't.
--
You are receiving this mail because:
You are the assignee for the bug.
