Round to nearest, ties to even (or round half to even)

[mikekaganski]

regarding the errors that are introduced when multiplying and dividing by 10, probably the only real solution would be to wait that the bug report you opened gets fixed in a later version

No, these errors will not be fixed completely. You can’t avoid floating-point operations introducing errors. Sometimes they may be made a bit smaller, but not removed completely.

These errors are what the spammer @newbie-02 is obsessed about. They spam every topic dealing with floating-point calculations, no matter if it is even related. Like here, where they didn’t start a new topic, but just started to pollute a clean discussion with unrelated stuff.

[Echo]

Mike Kaganski, again, thank you for you very informative comments. I’m learning a lot from them.

of course, ROUND(<PRECISION>) would not use “half-to-even”

[Sarcasm]I can substitute <PRECISION> with

SIGN(<PRECISION>)*((ABS(<PRECISION>)+2^52)-2^52)

in the relevant formula[/Sarcasm], however ROUNDSIG doesn’t round the second argument to the nearest integer, but it directly rounds it down (e.g. ROUNDSIG(1.11;1.99) returns 1 instead of 1.1). If <PRECISION> is manually inserted, then I think INT is better (e.g. -1.01 decimal digits are less precise than -1 decimal digits, so it should round to -2 decimal digits), however if <PRECISION> is the result of another formula and the user expects it to be an integer, then I think ROUND would be the better option.

[newbie-02]

after a short joy that the Ross Cottrell algorithm works for some values also for rounding to 16 digits (absolute) I came across limits, e.g. the ‘4925’ which should be cut off from ‘0,1656105402301851 | 4925’ for rounding to 16 digits are revalued to ‘~,5’ when multiplying with 1E+16, which of course has a different and undesired effect than ‘~,4~’ when rounding.
So this procedure is not usable for correct roundings ‘in the border area’.
Rounding there makes sense though, besides ‘~851,0’ - ‘~851,2’, ‘~851,5’ and ‘~851,8’ are still binary representable, can occur both meaningful and as a result of fp errors, and it would be good to be able to round them away.
— continued —

[newbie-02]

— continued —
doe’s anybody know an algorithm to correctly round values (IEEE doubles) to the limit of digits they can safely represent? preferably using ‘ties to even’.