See the notes section here. https://numpy.org/devdocs/reference/generated/numpy.around.html. This note was recently added in https://github.com/numpy/numpy/pull/14392 Eric On Fri, Sep 13, 2019 at 9:20 AM Andras Deak <deak.andris@gmail.com> wrote:
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