Path: csiph.com!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: Terry Reedy <tjreedy@udel.edu>
Newsgroups: comp.lang.python
Subject: Re: Is it safe to assume floats always have a 53-bit mantissa?
Date: Wed, 30 Dec 2015 09:35:29 -0500
Lines: 67
Message-ID: <mailman.75.1451486141.11925.python-list@python.org>
References: <5683d9aa$0$1618$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <5683d9aa$0$1618$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:100998

On 12/30/2015 8:18 AM, Steven D'Aprano wrote:
> We know that Python floats are equivalent to C doubles,

Yes

> which are 64-bit IEEE-754 floating point numbers.

I believe that this was not true on all systems when Python was first 
released.  Not all 64-bit floats divided them the same way.  I believe 
there has been some discussion on pydev whether the python code itself 
should assume IEEE now.  I do not believe that there are currently any 
buildbots that are not IEEE.  Does the standard allow exposing the 80 
bit floats of FP processors?

> Well, actually, C doubles are not strictly defined. The only promise the C
> standard makes is that double is no smaller than float. (That's C float,
> not Python float.) And of course, not all Python implementations use C.
>
> Nevertheless, it's well known (in the sense that "everybody knows") that
> Python floats are equivalent to C 64-bit IEEE-754 doubles. How safe is that
> assumption?
>
> I have a function with two implementations: a fast implementation that
> converts an int to a float, does some processing, then converts it back to
> int. That works fine so long as the int can be represented exactly as a
> float.
>
> The other implementation uses integer maths only, and is much slower but
> exact.
>
> As an optimization, I want to write:
>
>
> def func(n):
>      if n <= 2**53:

The magic number 53 should be explained in the code.

>          # use the floating point fast implementation
>      else:
>          # fall back on the slower, but exact, int algorithm
>
>
> (The optimization makes a real difference: for large n, the float version is
> about 500 times faster.)
>
> But I wonder whether I need to write this instead?
>
> def func(n):
>      if n <= 2**sys.float_info.mant_dig:
>          # ...float
>      else:
>          # ...int

Pull the calculation of the constant out of the function.  Naming the 
constant documents it and allows easy change.  There is pretty standard 
in scientific computing (or was once).

finmax = 2 ** sys.float_info.mant_dig  # -1?

def func(n):
     if n <= finmax:
         ...

-- 
Terry Jan Reedy