Bad calculation result

os: windows 11
Onlyoffice desktop
In the following table the result of the operations should be zero!

Hey @Pascal :handshake:

Thank you for providing the script and screenshot of the issue! :hugs:
We are analyzing the situation. Once we have more information, I will let you know.


We have created bug report based on this case!
Thank you for reporting this issue. :hugs:

Hi @Nikolas
I noticed this and surprised that it had been flagged as a “bug”, given that most programmers know that floating point numbers are always imprecise at such small fractional numbers.

Even using the same numbers and mathematics as the example provided by @Pascal, I get a different result, being -0.0000000000000852651283 , which is probably a factor of CPU version.

Invariably, we use rounding to trim off this erroneous data, and OO will oblige, if the number format is set to two decimal places by yielding a result of 0.00. The expected result.

So, I am curious as to which the developer team come up with for this.

the problem is that I don’t use conditional formatting on these cells. I tested the file with excel and the result gives 0.

Screenshot with conditional formatting

… interesting, It sounded like MS must be doing some additional clean-up in their Excel code to deal with this issue.
So I looked it up.
Excel only supports 15 digit precision, so in your example, Excel is discarding all that small data which would leave only a precise zero.

So, I guess it could be a “bug”, in so much as OO is not discarding any data smaller than
Screenshot 2023-12-07 054849

As an application developer, I am obviously aware of the computed floating point issue, but I had not considered how spreadsheets may deal with this; I’ve always used a cell formatting to keep data under control.

Thanks for that, I have a new item to adds to my knowledge-base :+1:

I use a number format 0.00 but the test is always wrong. To get a true test, I use the rounding formula.

Hey @DavidRGreen
We are working to improve our product and strive to ensure that users transitioning from other editors do not experience issues with “floating point” precision.

That’s why we have identified such behavior as a bug.
I believe it should be fixed in the near future.

1 Like