[Numpy-discussion] Numpy float precision vs Python list float issue

David Cournapeau david@ar.media.kyoto-u.ac...
Mon Apr 20 08:50:04 CDT 2009


David Cournapeau wrote:
> Hi Ruben,
>
> Ruben Salvador wrote:
>   
>> Hi everybody!
>>
>> First of all I should say I am a newbie with Python/Scipy. Have been
>> searching a little bit (google and lists) and haven't found a helpful
>> answer...so I'm posting.
>>
>> I'm using Scipy/Numpy to do image wavelet transforms via the lifting
>> scheme. I grabbed some code implementing the transforms with Python
>> lists (float type). This code works perfectly, but slow for my needs
>> (I'll be doing some genetic algorithms to evolve coefficients of the
>> filters and the forward and inverse transform will be done many
>> times). It's just implemented by looping in the lists and making
>> computations this way. Reconstructed image after doing a forward and
>> inverse transform is perfect, this is, original and reconstructed
>> images difference is 0.
>>
>> With Scipy/Numpy float arrays slicing this code is much faster as you
>> know. But the reconstructed image is not perfect. The image difference
>> maximum and minimum values returns:
>> maximum difference => 3.5527136788e-15
>> minimum difference => -3.5527136788e-15
>>
>> Is this behavior expected?
>>     
>
> Yes, it is expected, it is inherent to how floating point works. By
> default, the precision for floating point array is double precision, for
> which, in normal settings, a = a + 1e-17.
>
>   
>> Because it seems sooo weird to me.
>>     
>
> It shouldn't :) The usual answer is that you should read this:
>
> http://docs.sun.com/app/docs/doc/800-7895
>
> Floating point is a useful abstraction, but has some strange properties,
> which do not matter much in most cases, but can catch you off guard.
>
>   
>> If expected, anyway to override it?
>>     
>
> The only way to mitigate it is to use higher precision (depending on
> your OS/CPU combination, the long double type can help), or using a type
> with arbitrary precision.
^^^ this is inexact, I should have written the only way to avoid the
problem it so use arbitrary precision, and you can mitigate with higher
precision and/or better implementation. If double precision (the
default) is not enough, it is often because there is something wrong in
your implementation (compute exponential of big numbers instead of
working in the log domain, etc...)

David


More information about the Numpy-discussion mailing list