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