On 28 Apr 2014 20:22, "Robert Kern" <robert.k...@gmail.com> wrote: > C's rint() does not: > > http://linux.die.net/man/3/rint > > This is because there are many integers that are representable as > floats/doubles/long doubles that are well outside of the range of any > C integer type, e.g. 1e20.
By the time you have a double integer that isn't representable as an int64, you're well into the range where all doubles are integers but not all integers are floats. "Round to the nearest integer" is already a pretty semantically weird operation for such values. I'm not sure what the consequences of this are for the discussion but it seems worth pointing out. > Python 3's round() can return a Python int because Python ints are > unbounded. Ours aren't. > > That said, typically the first thing anyone does with the result of > rounding is to coerce it to a native int dtype without any checking. > It would not be terrible to have a function that rounds, then coerces > to int but checks for overflow and passes that through the numpy error > mechanism to be controlled. It would help here if we had a consistent mechanism for handling integer representability errors :-). -n
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
