(In reply to comment #3)
> The Wikipedia reference is to be appreciated because the relevant IEEE-754
> standard (1985 original or 2008 revision) is behind a subscription barrier.
> I will refer to the standard nevertheless, and for present purposes Std
> 754-1985 suffices. Section 5, Operations, is the relevant part. I quote:
> 
> "All conforming implementations of this standard shall provide operations to
> add, subtract, multiply, divide, extract the square root, find the
> remainder, round to integer in floating-point format, convert between
> different floating-point formats, convert between floating-point and integer
> formats, convert binary <---> decimal, and compare."
> 
> Subsection 5.5 expands on the specification of rounding to integer. For my
> posted example the situation is simple: the input value is an exactly
> representable integer, y=power(2,50)+1. Following Microsoft Excel,
> LibreOffice Calc offers a bunch of functions to perform rounding to integer;
> they include round(.,0), roundup(.,0), rounddown(.,0), trunc(.,0),
> ceiling(.,1), floor(.,1) and int(.), where I use the "." symbol to denote
> the free argument.
> 
> For integer argument, as in the present case, there can be no ambiguity
> about what is the result of rounding to integer; the mathematical result
> value is the same as the input value. Moreover, given that the input value
> is a representable IEEE-754 number likewise this result value is exactly
> representable; it is the same value. It is an error in Microsoft Excel and
> in LibreOffice Calc that a different result is returned. (The present
> situation is very different from the familiar situation of adding and
> subtracting decimal numbers with two digits behind the decimal point and
> finding a result that differs from the correct mathematical result by some
> value much less than 0.01.)
> 
> I note that the tests of this kind of arithmetic can be confusing, because
> in fact Microsoft Excel 1997 (and later) and LibreOffice Calc deliberately
> violate IEEE Std 754-1985 for arithmetic very close to a cancellation
> threshold [1]. I quote:
> 
> "Excel 97, however, introduced an optimization that attempts to correct for
> this problem. Should an addition or subtraction operation result in a value
> at or very close to zero, Excel 97 and later will compensate for any error
> introduced as a result of converting an operand to and from binary."
> 
> It is not very clearly expressed, and "Optimization" would not be my choice
> of words. Anyway, this concerns plain arithmetic and it muddles the tests,
> but it does not affect the present issue with the rounding functions.
> 
> I note that my report received the lowest ranking in both columns for
> importance; that is not my assessment. The numerical error is tiny, sure,
> but it may break logic in a code if the result of rounddown(.,0) applied to
> a positive number can actually return a larger number, and I think that the
> reputational cost is not to be trivialized. One may recall the Pentium
> division bug.
> 
> [1] Floating-point arithmetic may give inaccurate results in Excel - Example
> When a Value Reaches Zero
> http://support.microsoft.com/kb/78113

We implement exactly the same optimization technique to work around some of the floating point accuracy problems. This is part of our core code and will not be changed.

I'm sorry there is nothing to discuss. This is a technical decision that you have to live with if you want to use Libreoffice Calc. Please don't reopen this bug as I explained already that this will never be changed.