From https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/775608 : The best way to explain this bug is with a simple example. Type the values 0.1, 0.2, and 0.3 in cells A1, A2, and A3; then on cell C1 type "=PRODUCT(1+A1:A3)-1" without the quotes; and then press <Control><Shift><Enter>. (If you do this correctly, cell C1 will display the formula in curly brackets, i.e., "{=PRODUCT(1+A1:A3)-1}", signifying that C1 contains an array formula.) If you do this in OpenOffice Calc, cell C1 displays the correct result, 0.716 -- the product of (1+0.1) times (1+0.2) times (1+0.3), less 1. If you do this in LibreOffice Calc, cell C1 displays 0 !!! Interestingly, this calculation error appears to be a problem only with the PRODUCT function in LibreOffice Calc. For instance, if in the above array formula you substitute PRODUCT with, say, SUM, both OpenOffice and LibreOffice Calc display the correct result, 2.6. ADDENDUM: I just noticed this calculation error seems to occur only when constants are used as inputs. For example, "=PRODUCT({1, 2, 3})" produces an erroneous result, 1; however, if you enter the values 1, 2, and 3 in cells A1, A2, and A3, "=PRODUCT(A1:A3)" and "=PRODUCT(A1,A2,A3)" both produce the correct result, 6. I can reproduce this bug a vanilla tag on tag 3.3.2.2 with ./autogen.sh --disable-binfilter --disable-mozilla --with-max-jobs="4" --with-junit=".../junit-4.9b2.jar" --with-system-icu --with-system-db --with-external-tar=... --disable-gtk. I can _not_reproduce this bug on master as of now, but think we should investigate this issue as it might lead to erroneous calculations that slip by unnoticed for long.
Reproducible in 3.3.2 but not in 3.4 beta 3. I suppose it was fixed.
Ok. I'll mark this fixed in 3.4.
IMHO this would warrant an investigation for the 3.3.3 release. Opinions?
To me the fact that this hasn't been reported until 3.3.2 suggests this is a minor case. I don't think it's worth fixing this again for the 3.3.x branch which is soon to become obsolete. But if someone is willing to submit a patch, I'll review it, and if it's safe enough change, why not.
Created attachment 46313 [details] patch from launchpad lp#775608 It looks like the error has been introduced with: http://cgit.freedesktop.org/libreoffice/calc/commit/?id=c9d53a9a25770f6736c5f2342d57c237bde2f23 Copy-paste from https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/775608 : = RATIONALE = This is: - a severe regression from the previous release of Ubuntu - while it might directly not cause a loss of user data, it might cause corruption of user data which might be even worse = RESOLUTION = The bug has been found to be caused by an call to the function IterateMatrix() in sc/source/core/tool/interpr1.cxx with the wrong order of parameters. This causes the initial value of the iteration to be wrong for PRODUCT. It seems to be right still for other functions by pure luck (i.e. as fMem is 0 it works out correctly for most calls - but for PRODUCT calls fRes has to be 1 initially). = REPRODUCING THE BUG = TEST CASE: - Open calc spreadsheet - type in "=PRODUCT({1, 2, 3})" as formula for a cell - expected result: 6 - actual result: 1 Reopening from review and commit to 3-3 branch as patch is available.
Reassigning to kohei for review.
Ah, that looks very safe. I'll commit this to the libreoffice-3-3 branch with my sign-off. Good work Bjoern and thanks. :-)
Fixed in the libreoffice-3-3 branch http://cgit.freedesktop.org/libreoffice/calc/commit/?h=libreoffice-3-3&id=3152922a95e18814e32bcf8bc29c872077d05a65 As this is a generic 3.3 branch (not a specific branch for 3.3.3) one sign-off is all that's needed to commit.
I'm not sure if it should be considered a new bug. But on LO 4.0.03 on osx, product has strange behavior with array: if you type 2, 3 in A1, A2 and 2 , 2 in B1, B2 if you type =power(A1:A2,B1:B2) in C1 (and press ctrl+shift+enter), you get the good 2x1 array 4,3 in C1:C2 if you do =product(C1:C2) in C3 you get the good result 12 if you do everything in on shot =product(power(A1:A2,B1:B2)) (and press ctrl+shift+enter) you get 3 as a result.
according to comment #1 and comment #2 the original bug was fixed in release 3.4. if the PRODUCT function gives incorrect results in 4.x releases please file a separate bug for that.