I did not mean to imply that no one cares about rounding rules, or that they are unimportant -- sorry if I was not clear. I only said that in my (necessarily limited) experience, when IEEE rounding rules start to matter then I am facing a different, usually more fundamental, problem.
However, these discussions are necessarily very abstract. Having a concrete issue or use case where you find one rounding mode preferable to another would help focus the discussion. IMO functions like round are usually for displaying numbers, not for computation, so am fine with rounding away from 0. Especially since for decimal displays converted from an underlying binary (float), it may not matter for practical purposes. Eg julia> round(1.0000000005, 9) 1.000000001 may look like rounding away from 0, but because of inexact representation, rounding is clearcut anyway: julia> rationalize(1.0000000005)-1 1//1999999834 Best, Tamas On Sat, Dec 27 2014, Hans W Borchers <[email protected]> wrote: > Just a remark: "round-towards-+Inf" is not the same as > "round-away-from-zero" and > does not fulfill "round(-x) = -round(x)". > > gp> round([1.5, 2.5]) > %1 = [2, 3] > > gp> round([-1.5, -2.5]) > %2 = [-1, -2] > > I am astonished that PARI/GP is rarely mentioned when comparing Julia to > other > scientific computing systems -- not even in the long list of issue #8750 or > on > the 'Gang of Forty' slide of the Vision talk at MIT. > > But PARI/GP is, besides Mathematica, the most competent mathematical > computing > system and has set the standard in number theory computations for over 30 > years. > > BTW: > @Tamas Some mathematicians and statisticians **do** care about rounding > rules. > > > On Saturday, December 27, 2014 1:08:24 AM UTC+1, Stefan Karpinski wrote: >> >> On Fri, Dec 26, 2014 at 6:00 PM, Hans W Borchers <[email protected] >> <javascript:>> wrote: >> >>> What irritates me a bit are these back-and-forth decisions. I accepted >>> ".+" for scalar plus vector operations (with a bit of teeth grinding, but >>> listening to a good mathematical analogy), used it in some programs, only >>> learning a few weeks later that a change agent had struck again. >>> >> >> I agree it's annoying, but I think it's important to try things and >> recognize when an experiment was a mistake. Fortunately, we haven't done >> this very often. >> >> >>> I know about (some of) the problems with rounding. The perhaps >>> mathematically most complete and correct arithmetic computing system, >>> PARI/GP, still uses "round-to-+Inf" and 'generations' of mathematicians >>> have lived well with that. And the "problems with the digit argument" >>> mentioned are perhaps a reason why many systems like Octave, Matlab (up to >>> 2014a), Mathematica, PARI/GP do not allow for a second parameter in their >>> 'round' functions. Maybe there is really no satisfying solution here for >>> this problem. >>> >> >> I would also be ok with round-to-Inf behavior since to me that's what the >> mathematical round function does. Of course, it's also nice that round(-x) >> == -round(x) for all x. Also, we've traditionally tried to keep things >> close to C when there aren't other languages (Matlab, Python) that serve as >> better models. >>
