On Fri, Sep 13, 2019 at 2:59 PM Philip Hodge <hodge@stsci.edu> wrote:
>
> On 9/13/19 8:45 AM, Irvin Probst wrote:
> > On 13/09/2019 14:05, Philip Hodge wrote:
> >>
> >> Isn't that just for consistency with Python 3 round()?  I agree that
> >> the discrepancy with np.set_printoptions is not necessarily expected,
> >> except possibly for backwards compatibility.
> >>
> >>
> >
> > I've just checked and np.set_printoptions behaves as python's round:
> >
> > >>> round(16.055,2)
> > 16.05
> > >>> np.round(16.055,2)
> > 16.06
> >
> > I don't know why round and np.round do not behave the same, actually I
> > would even dare to say that I don't care :-)
> > However np.round and np.set_printoptions should provide the same
> > output, shouldn't they ? This discrepancy is really disturbing whereas
> > consistency with python's round looks like the icing on the cake but
> > in no way a required feature.
> >
>
> Python round() is supposed to round to the nearest even value, if the
> two closest values are equally close.  So round(16.055, 2) returning
> 16.05 was a surprise to me.  I checked the documentation and found a
> note that explained that this was because "most decimal fractions can't
> be represented exactly as a float."  round(16.55) returns 16.6.
>
> Phil
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

Ah, of course, endless double-precision shenanigans...
>>> format(16.055, '.30f')
'16.054999999999999715782905695960'

>>> format(16.55, '.30f')
'16.550000000000000710542735760100'

András
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion