Re: [Numpy-discussion] should rint return int?
On Mon, Apr 28, 2014 at 10:36 AM, Neal Becker ndbeck...@gmail.com wrote: I notice rint returns float. Shouldn't it return int? AFAICT, rint() is the same as round(), except with slightly different rules for the halfway case. So returning a float makes sense, as round() and ceil() and floor() all do. ( though I've always thought those should return inegers, too... ) By the way, what IS the difference between rint and round? In [37]: for val in [-2.5, -3.5, 2.5, 3.5]: : assert np.rint(val) == np.round(val) : In [38]: -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.go chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] should rint return int?
On Mon, Apr 28, 2014 at 6:36 PM, Neal Becker ndbeck...@gmail.com wrote: I notice rint returns float. Shouldn't it return int? Would be useful when float is no longer acceptable as an index. I think conversion to an index using rint is a common idiom. 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. 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. But it shouldn't be called rint(), which is intended to be as thin a wrapper over the C function as possible. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] should rint return int?
Robert Kern wrote: On Mon, Apr 28, 2014 at 6:36 PM, Neal Becker ndbeck...@gmail.com wrote: I notice rint returns float. Shouldn't it return int? Would be useful when float is no longer acceptable as an index. I think conversion to an index using rint is a common idiom. 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. 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. But it shouldn't be called rint(), which is intended to be as thin a wrapper over the C function as possible. Well I'd spell it nint, and it works like: def nint (x): return int (x + 0.5) if x = 0 else int (x - 0.5) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] should rint return int?
On 4/28/2014 3:29 PM, Neal Becker wrote: Well I'd spell it nint, and it works like: Wouldn't it be simpler to add a dtype argument to `rint`? Or does that violate the simple wrapper intent? Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] should rint return int?
On Mon, Apr 28, 2014 at 8:36 PM, Alan G Isaac alan.is...@gmail.com wrote: On 4/28/2014 3:29 PM, Neal Becker wrote: Well I'd spell it nint, and it works like: Wouldn't it be simpler to add a dtype argument to `rint`? Or does that violate the simple wrapper intent? `np.rint()` is a ufunc. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] should rint return int?
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
