round digits issues

[simonbyrne]

How should the digits argument of round (and floor, ceil and trunc) behave? Decimal fractions are typically not representable by floating point numbers, and so the "decimal representation" may round in a different direction than the true number. This has been mentioned before in #8728, and on julia-users.

For example:

julia> @printf "%.60f" 8.315
8.314999999999999502620084967929869890213012695312500000000000

julia> round(8.315,2)
8.32

julia> @printf "%.2f" 8.315
8.31

For reference:

• Python (both 2 and 3) round(8.315,2) returns 8.31 (i.e. it gives the "correct rounding").
• Ruby 8.315.round(2) returns 8.32
• Matlab 2014b seems to offer a digits option: unfortunately I only have 2014a installed (which doesn't offer it), could someone let me know what it does?

Some options:
a. correct rounding (as done by Python).
b. "round the representation" (as we do at the moment)
c. get rid of the digits argument (or just make it base-2).

If we go for correct rounding, this could give unexpected results for ceil, floor and trunc, e.g. floor(8.2, 1) == 8.1.

[tomasaschan]

In this case, I have to vote for the "least surprising" behavior. To me, round(8.315,2) == 8.31 is just confusing, and would probably have me waste hours on a scavenger hunt for other bugs in my code before I realized that round doesn't do what I think it does.

Rounding (especially literals) based on binary representation also makes round and friends very unpredictable, if you're not so good at doing decimal-to-binary conversion in your head - suddenly, you can't tell just by looking which way a number will be rounded.

tl;dr: I think most users, especially new ones, would consider round and friends broken if round(x,3) == 8.315 and round(x,2) == 8.31 while at the same time e.g. round(y,3) == 9.315 and round(y,2) == 9.32 (if now 9.315 happens to be a number that rounds the other way in binary...).

[simonbyrne]

@tlycken, I agree: it does seem odd to insist upon exact rounding to an inexact number. As no one has spoken up to defend Python-style rounding, I've noted the current behaviour in the docs (#10018).

[simonbyrne]

As this seems to have been more-or-less settled, I'm going to close it. If there are any objections, please re-open.