Incorrect compute for rounding function round(x)

General Usage
1

I’m a Julia learner, and now i have a confuse question about the rounding function round(x), i’m not sure if it is bug, my compute system is window 64-bit, the version of Julia is 1.0, i have a problem while test the function round(x), post quoted code:
julia> round(6.5)
6.0
julia> round(7.5)
8.0
julia> round(17.5)
18.0
julia> round(127.5)
128.0
julia> round(8.5)
8.0
As you can see, the parameter is 7.5 or xx7.5, function round(x) is shrink, this different from the other parameters, i’m not sure what happen, just post it to ask for a help, thanks
please forgive my unmature english presentation,

2

This is specified in the IEEE 754 (the floating point standard) rounding rules (Wikipedia), in particular by default there is the following rule

  • Round to nearest, ties to even – rounds to the nearest value; if the number falls midway it is rounded to the nearest value with an even (zero) least significant bit; this is the default for binary floating-point and the recommended default for decimal.
4 Likes
3

Thanks for your reply,
Function round(x) really obey the rule IEEE 754, i just can’t understand the compute value of round(6.5) is 6.0, but the compute value of round(7.5) is 8.0, it seems they obey two rule, i think the value of round(6.5) should be 7.0. do you think so?

4

Yes, it’s not what you’re taught in school, but this is exactly what the standard says the default behavior for rounding should be.

2 Likes
5

Note that you can specify a RoundingMode to alter this behavior:

  Currently supported rounding modes are:

    •    RoundNearest (default)
    •    RoundNearestTiesAway
    •    RoundNearestTiesUp
    •    RoundToZero
    •    RoundFromZero (BigFloat only)
    •    RoundUp
    •    RoundDown

I think RoundNearestTiesUp is what most people learn in primary school (edit: n = 1, ca. 1976, United States).

1 Like
6

It is actually one rule and the two cases you’ve noted is the rule.

In the US, maybe. Definitely not in China (at least not ~ 20yrs ago).

7

Fair point. Edited.

8

Good thing we didn’t copy AppleScript’s naming conventions then.

2 Likes
9

Thanks for above all analyze, this behave … broke down my previous idea, its really reasonable even if its different from my learned, by the way, im a python user, so i never run into this problem until using Julia, however, thanks Juila, thanks a ton for yous.

10

BTW: it is the same behaviour as Python

Python 3.6.3 |Anaconda custom (64-bit)| (default, Oct 15 2017, 03:27:45) [MSC v.1900 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 6.1.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: round(6.5)
Out[1]: 6

In [2]: round(7.5)
Out[2]: 8

But I note that Matlab thinks differently…

1 Like
11

The default rounding mode in a programming language is often as much a topic of debate as the famous tabs vs. spaces. Hence there are differences. I think there are even some that skirt around that debate by forcing the user to explicitly specify a rounding mode.

12

I think this is a bit different. In the tabs vs spaces debate (or the other similar ones), users are usually aware of the alternatives and have a preferred one.

OTOH, when it comes to rounding (and other features of floating point), the issue usually comes up because the user is surprised at the result, then becomes informed about different rounding modes etc. At this point, arguing for the “unsurpising” solution is natural, but after people think about it, they usually realize the technical reasons for one choice or another and their preferences become more reasoned.

1 Like
13

This was one of the Python 3 changes, Python 2 used C’s “half away” behaviour.