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

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.

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.

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 —

— 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’.