As explained in tdf#154792, this was intentional, introduced in tdf#124286, and was intended to compensate the normal floating-point inaccuracies, like the previous `=ROUNDDOWN(8.94-8;2)`

producing `0.93`

instead of the expected `0.94`

, because the negation `8.94-8`

produced `0.9399999999999995`

. So the rounding to 12 significant digits was introduced before rounding up/down in commit edcbe8c4e02a67c74ec6f85f28899431dbfa0765 (when the requested number of decimals was less than 12, indeed).

@erAck has improved this in this night’s commit 8186a01f2a26f05645a2a3c9c93b453bd35b796f. All the samples in the report (both OP’s, and my comment 1 there) now behave as expected.

However, it must be noted that the problem can’t be resolved cardinally, because the original problem of tdf#124286 still needs addressing. Despite OP’s claims, Excel also has the inaccuracies, like here:

It also rounds up in `ROUNDDOWN`

when appropriate. Spreadsheets, despite being not exact, are widely used in accounting and similar areas, for which they had been tailored extensively; and *in these areas*, a deviation after a dozen of decimals is usually a sign of FP inaccuracies, rather than a significant information, which has to be accounted for to provide expected value. What spreadsheet software is *not* designed to is *infinite accuracy*.

Note also that OP’s claim in the bug:

Microsoft figured it out long long time ago. You’re decades behind on something as fundamental as subtraction and rounding down.

is plain wrong. One can try other examples, where we calculate much more accurate. E.g., having `A1:A60`

with `0.1`

in each, `=SUM(A1:A60)`

would give the expected `6.0`

in Calc, but `5,99999999999999`

in Excel (one might need to increase shown decimals to see that); and the ROUNDDOWN to 1 decimal on this sum would produce `5.9`

. Thanks to Dante, who implemented Kahan summation algorithm (or, more precisely, Neumaier’s) in tdf#137679.

Or putting `100.01`

to `A1`

, `100`

to `A2`

, selecting `A1:A2`

, and dragging down to row 10002 (down to the expected `0`

) would result in `-5,09885E-11`

in `A10002`

in Excel, but 0 in Calc; summing absolute deviations from the correct values in all the cells `A1:A10002`

would produce `~4,40E-11`

in Calc, but `~2,56E-07`

in Excel (so total error is four orders of magnitude larger). And thanks to @erAck, this issue is also improved/fixed.