I’ve got the impression (without having hard numbers), that new/revised languages are shifting from “round up on ties” to “round to even.” At the moment, I have only one concrete data point. :wink: … Python 2 used to round up on ties whereas Python 3 rounds to even.
In that light, I wouldn’t say that “round up on ties” is a “standard” round function.
I think it’s fine to have “round to even” as default behavior for round, but I’m not opposed to an extra function that rounds up on ties. :slightly_smiling_face:
Why do you want the “round up on ties” behavior rather than “round to even”?
For numerical computations the “round ties to even” seems better. I am working on a version of Processing for Racket, where the main focus is producing images and animations. They (or should I say Java) uses the “round ties up” rule. Now I haven’t looked for programs that rely on the rule, but I can imagine that some images will have odd patterns if ties are broken to the same side every time.
I looked at C “round” and Java “round”. I didn’t know Python switched.
Turns out Python 2 uses “round a way from 0” (which for positive numbers is the same as round up).
You’re right. Interesting detail. That’s actually what I had in mind when I wrote that Python 2 rounded up, but that’s indeed not precise. :-D
I checked the docs of P5.js (the JavaScript version of Processing) - and they don’t mention what happens on ties (but mentions Math.round is used). However Math.round happens to use the “round towards +infinity” rule.
I am beginning to think, it is better to stick to the standard Racket function - and maybe include a separate round-up.
Could/would you use a parameter to control rounding behavior while otherwise keeping the code the same (so you can easily switch the rounding behavior)? Or is this unnecessary complexity?
I guess it may be practical to just live with small rounding differences between the implementations, especially if there isn’t an “obvious”/"ideal" approach.
> Description > > *round* returns a value equal to the nearest integer to _x_. The fraction 0.5 will round in a direction chosen by the implementation, presumably the direction that is fastest. This includes the possibility that *round*(_x_) returns the same value as roundEven(_x_) for all values of _x_.
Just found this from the OpenGL specs. Seems there is nothing to worry about :slightly_smiling_face:
A possible advantage of returning the old value is that the new value can be obtained from a, but the old value will be lost.
which can be useful for backup/restore stuff for set! in general (but not really so useful for ++)
One time I got bored and wrote a little micro library for dealing with different rounding modes