Comments on: IEEE floating point arithmetic in Python http://www.johndcook.com/blog/2009/07/21/ieee-arithmetic-python/ The blog of John D. Cook Sat, 11 Feb 2012 01:10:06 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: John http://www.johndcook.com/blog/2009/07/21/ieee-arithmetic-python/comment-page-1/#comment-21529 John Wed, 22 Jul 2009 12:48:55 +0000 http://www.johndcook.com/blog/?p=2704#comment-21529 Thanks Mike. I left out a "not." I corrected the post. Thanks Mike. I left out a “not.” I corrected the post.

]]> By: Mike Swaim http://www.johndcook.com/blog/2009/07/21/ieee-arithmetic-python/comment-page-1/#comment-21527 Mike Swaim Wed, 22 Jul 2009 12:45:59 +0000 http://www.johndcook.com/blog/?p=2704#comment-21527 Did you mean to say that Python integers are the same as C ints, or that they aren't? It looks like you said that they are. Did you mean to say that Python integers are the same as C ints, or that they aren’t? It looks like you said that they are.

]]> By: Paddy3118 http://www.johndcook.com/blog/2009/07/21/ieee-arithmetic-python/comment-page-1/#comment-21496 Paddy3118 Tue, 21 Jul 2009 20:45:00 +0000 http://www.johndcook.com/blog/?p=2704#comment-21496 @David, I think they have further blurred things in Python 3: ints are arbitrary precision, but, when possible, fixed precision calculations are done. They are trying to have a seemless transition between what were ints and what were longs in Python 2.x days. - Paddy. @David,
I think they have further blurred things in Python 3: ints are arbitrary precision, but, when possible, fixed precision calculations are done. They are trying to have a seemless transition between what were ints and what were longs in Python 2.x days.

- Paddy.

]]> By: David Warde-Farley http://www.johndcook.com/blog/2009/07/21/ieee-arithmetic-python/comment-page-1/#comment-21493 David Warde-Farley Tue, 21 Jul 2009 18:38:03 +0000 http://www.johndcook.com/blog/?p=2704#comment-21493 The situation is a little bit more complex: Python integers are not actually arbitrary precision in Python 2.x (unsure about 3.x), what <em>are</em> arbitrary precision are longs, which sometimes result from integer operations (i.e. 2**400). You can tell the difference either by looking at what's returned by type() or by seeing an 'L' at the end of its textual representation. Replacing all integer arithmetic with arbitrary precision arithmetic in software would likely make a lot of things unbearably slow. The Python 'int' type corresponds to C 'long', and Python 'long' is the arbitrary precision type. NumPy also contains integer types that have a specific bit-width: int8, int16, int32, int64, which correspond to the C type. This can be pretty important if you're working with large files and don't want 4 or 8 bytes for every element when 1 or 2 would do. Also, a neat feature of NumPy is that, with NumPy arrays and floating point scalar types (float32, float64, float128 as well as complex64, complex128 and complex256) is that you can control the effect of hitting division by zero, overflow, underflow or invalid ops (things that produce NaN); each of these errors can either be ignored, produce a warning, raise an exception, or call a user-specified function. Have a look at the documentation for numpy.seterr for the specifics. The situation is a little bit more complex: Python integers are not actually arbitrary precision in Python 2.x (unsure about 3.x), what are arbitrary precision are longs, which sometimes result from integer operations (i.e. 2**400). You can tell the difference either by looking at what’s returned by type() or by seeing an ‘L’ at the end of its textual representation. Replacing all integer arithmetic with arbitrary precision arithmetic in software would likely make a lot of things unbearably slow. The Python ‘int’ type corresponds to C ‘long’, and Python ‘long’ is the arbitrary precision type. NumPy also contains integer types that have a specific bit-width: int8, int16, int32, int64, which correspond to the C type. This can be pretty important if you’re working with large files and don’t want 4 or 8 bytes for every element when 1 or 2 would do.

Also, a neat feature of NumPy is that, with NumPy arrays and floating point scalar types (float32, float64, float128 as well as complex64, complex128 and complex256) is that you can control the effect of hitting division by zero, overflow, underflow or invalid ops (things that produce NaN); each of these errors can either be ignored, produce a warning, raise an exception, or call a user-specified function. Have a look at the documentation for numpy.seterr for the specifics.

]]> By: Paddy3118 http://www.johndcook.com/blog/2009/07/21/ieee-arithmetic-python/comment-page-1/#comment-21491 Paddy3118 Tue, 21 Jul 2009 18:10:19 +0000 http://www.johndcook.com/blog/?p=2704#comment-21491 "There are two kinds of exceptional floating point values: infinities and NaNs." There is also the quirky plus and minus zero. (In Python 2.6) <code> >>> -0. -0.0 >>> +0. 0.0 >>> +0. == -0. True >>> +0. is -0. False >>> +0. is +0. True >>> -0. is -0. True >>> -0. is +0. False >>> </code> “There are two kinds of exceptional floating point values: infinities and NaNs.”
There is also the quirky plus and minus zero.

(In Python 2.6)

>>> -0.
-0.0
>>> +0.
0.0
>>> +0. == -0.
True
>>> +0. is -0.
False
>>> +0. is +0.
True
>>> -0. is -0.
True
>>> -0. is +0.
False
>>>

]]>