Created attachment 47528 [details] example.ods Downstream bug may be found at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/360836 1) lsb_release -rd Description: Ubuntu 11.04 Release: 11.04 2) apt-cache policy libreoffice-calc libreoffice-calc: Installed: 1:3.3.2-1ubuntu5 Candidate: 1:3.3.2-1ubuntu5 Version table: *** 1:3.3.2-1ubuntu5 0 500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages 100 /var/lib/dpkg/status 1:3.3.2-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages 3) What is expected to happen in LibreOffice Writer via the Terminal: cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/360836/+attachment/2154833/+files/example.ods && localc -nologo example.ods is cell A1 =-1 cell A2 =0 cell A3 0=A1*A2 4) What happens instead is cell A3 shows -0.
Partially confirmed. When opening your testfile with LO 3.4 RC2 / LO 3.4.0 it gives indeed the wrong version. But when doing it from scratch (see my example), it works as expected. So you might wanna check out that version. Win2K [LibreOffice 3.4.0 OOO340m1 (Build:12)]
Created attachment 47536 [details] -1*0=0 in LO 3.4 RC2
(In reply to comment #2) > Created an attachment (id=47536) [details] > -1*0=0 in LO 3.4 RC2 I checked the content.xml in your file and it contains value -0. Actual displayed value depends on number format, locale, etc. I think that value of -0 should not happen at all. Kohei, what do you think?
in calc, the numbers are floating point numbers. IEEE 754 says, there is a difference between positiv and negative numbers.
wope, having LO display -0 does not make sense & does not uphold with Excel expectations compatibility.
Excel expectations compatibility are of really low interest for me, is there any mathematical text (public access) that seconds "-0 is wrong" and also may be some ODF explications? May be A "0" definition is "+0 = -0"? The old Summary seems to be incomplete, for me (with preference "precision as shown unchecked"): Standard FORMATTING can sow result "-0" for multiplication with 0, after result field showed result of multiplication "0 * negative Number" before; negative number also might have been "-0". My results: [Reproducible] from the scratch with "LibreOffice 3.4.1RC1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:103)]". It's a matter of formatting. With "Standard" formatting "-0" will be shown, with "0 decimals" or more than 0 decimals "0.0", "0.00" or similar. The result is not 100% reproducible, sometimes after some testing a normal "0" will be shown as "-0", but when I save the document the view changes to "-0". Currently I do not understand the regularity. Steps to reproduce: 0. Open new Calc document 2. Make sure that 'Tools > Options > Calc > Calculate - "Precision as shown" unchecked And cells have number format "Standard" 3. Type A1: 0 A2: 0 A3: =A1+A2 Result in A3: 0 4. Save: Nothing Happens 5. Type A2: -1 Nothing happens 6. Save A3 switches to -0 7. Type A2: 0 A3 remains -0 8. Save: A3 switches to 0 OOo 3.4-dev (obsolete) behaves in the same way. I was not able to reproduce th "-0 effect" with OOo 3.1.1 and OOo 1.1.4 So I believe this bug is not a matter of mathematical correctness but a matter of unpredictable 0 sign
Dependency to result view to an older calculation result is not a good idea.
Maybe for 3.5. FYI in the scenario presented in the description Excel produces 0, not -0. So the interoperability argument does not hold in this particular case.
I have a fix based on the assumption that -0 is a valid IEEE 754 number that should never appear in the view. We just need to check in the number formatter that we show the minus sign only if the value is unequal to 0.0. IEEE 754 allows -0, 0 and +0 but asks that the check -0 == 0 returns true.
pushed my fix to master for the 3-5 release