Created attachment 103755 [details] ODS file doing this... I did a quick CALC form to check some ins and outs and put in the following 4 values: 715,68 -710,00 52,80 -58,48 than I do =SUM(A1:A4) - result should be 0 but instead result is -4,974E-014
This is on a AMD Phenom II X2 555 I also tried on a Windows 8 PC (AMD) with v4.1.4.2 Windows Vista PC (INTEL) with v4.1.5.3 and result is 0 in all cases... same Windows Vista PC after update to v4.2.5.2 error occurs also fails with: 400,10 -600,30 100,10 100,10 result 5,6843E-014
this is a duplicate of #80638 and maybe others with floating point numbers. *** This bug has been marked as a duplicate of bug 80638 ***
reproducible with LO 4.3.0.4 (Win 8.1) @Sophie: For me this is a bug. Therefore, I think it should be marked as a "Confirmed bug" but not as "RESOLVED NOTABUG" by referring it to 80638 ? Otherwise, maybe nobody will take care / notice of it because it is marked as RESOLVED?
I'm also happy if this issue can be resolved. But Kohei has stated this limitation regarding floating point in Bug 50299.
80638 has been closed as NOT A BUG. This is something that happens with a short columne of low-precision numbers. Also probably very commun to get a result 0. It's easely reproducable It has been intruduced after 4.1.5.3. Please reconsider confirmation.
This is a technical limitation and fixing one problem may introduce another one. Additionally results are not stable as any change in the Libreoffice code may result in slightly different results. Please read http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems to understand the problem around floating point numbers.
The accuracy problem does NOT APPLY in this case. Accuracy problem might happen if your figures are results of math operations with high precision. In this case we are talking about figures with an accuracy of one digit after the point which I enter directly into a spreadsheet (not a result of previous operations). This is not something that is computer/precision related as has been suggested but has been introduced after v4.1.x.x Please reconsider to take a more careful look at the problem before citing answers that have been given to DIFFERENT inquiries. The row: 410,5 -561,4 150,9 sum(A1:A3) has a result of 2,8422€-014 This is not inaccurate but wrong!!! If I use this result for further math operations – those operations will be wrong.
If you use =410,50-561,40+150,90 result IS 0.
removing me from CC - Sophie
Also removing from CC - Markus and Kohei are two of our core spreadsheet developers and both agree on this one. I see no reason for me to keep seeing emails about it.
(In reply to comment #7) > The accuracy problem does NOT APPLY in this case. Accuracy problem might > happen if your figures are results of math operations with high precision. > In this case we are talking about figures with an accuracy of one digit > after the point which I enter directly into a spreadsheet (not a result of > previous operations). This is not something that is computer/precision > related as has been suggested but has been introduced after v4.1.x.x > > Please reconsider to take a more careful look at the problem before citing > answers that have been given to DIFFERENT inquiries. > > The row: > 410,5 > -561,4 > 150,9 > sum(A1:A3) > has a result of 2,8422€-014 > > This is not inaccurate but wrong!!! If I use this result for further math > operations – those operations will be wrong. I'm a calc developer and know for sure a bit more about IEEE 754 than you think. You can try to represent 0.1 as 64bit IEEE 754 flaoting point number without loosing any precision. Please reopen the bug report only when you managed to do that. If you don't believe me I will happily point you to http://grouper.ieee.org/groups/754/faq.html#binary-decimal Please don't reopen this bug report before you understand what a floating point number is and why for example 400.1 can not be represent without a loss of accuracy in this format.
It has been brought to my attention by one of the developers that this behavior is debt to that every value you put into a spreadsheet is converted to an IEEE 754 float which is very fast to work with, but inherently inprecise. So in easy terms: once you put 410,5 into A1 it is internally seen as 410,500000000000008422. Whatever you do with those figures now the result is going to suffer from this same inprecision. This is not going to effect your results under normal circumstances but if you do not limit precision for your result – if the result is 0 – the leftovers will actually show up. If you do not want to see such effect an easy enough work around would be to limit your precision to less then 12 digits after the dot. Big 'Thank you' again to the developer who took his time and explained it all to me.
*** Bug 87875 has been marked as a duplicate of this bug. ***