[Python-Dev] Caching float(0.0)

[Alastair Houghton]

On 4 Oct 2006, at 06:34, Martin v. Löwis wrote:

> Alastair Houghton schrieb:
>> On 3 Oct 2006, at 17:47, James Y Knight wrote:
>>
>>> On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote:
>>>> As Michael Hudson observed, this is difficult to implement, though:
>>>> You can't distinguish between -0.0 and +0.0 easily, yet you should.
>>>
>>> Of course you can. It's absolutely trivial. The only part that's  
>>> even
>>> *the least bit* sketchy in this is assuming that a double is 64  
>>> bits.
>>> Practically speaking, that is true on all architectures I know of,
>>
>> How about doing 1.0 / x, where x is the number you want to test?
>
> This is a bad idea. It may cause a trap, leading to program  
> termination.

AFAIK few systems have floating point traps enabled by default (in  
fact, isn't that what IEEE 754 specifies?), because they often aren't  
very useful.  And in the specific case of the Python interpreter, why  
would you ever want them turned on?  Surely in order to get  
consistent floating point semantics, they need to be *off* and Python  
needs to handle any exceptional cases itself; even if they're on, by  
your argument Python must do that to avoid being terminated.  (Not to  
mention the problem that floating point traps are typically delivered  
by a signal, the problems with which were discussed extensively in a  
recent thread on this list.)

And it does have two advantages over the other methods proposed:

1. You don't have to write the value to memory; this test will work  
entirely in the machine's floating point registers.

2. It doesn't rely on the machine using IEEE floating point.  (Of  
course, neither does the binary comparison method, but it still  
involves a trip to memory, and assumes that the machine doesn't have  
multiple representations for +0.0 or -0.0.)

Even if you're saying that there's a significant chance of a trap  
(which I don't believe, not on common platforms anyway), the  
configure script could test to see if this will happen and fall back  
to one of the other approaches, or see if it can't turn them off  
using the C99 <fenv.h> APIs.  (I think I'd agree with you that  
handling SIGFPE is undesirable, which is perhaps what you were  
driving at.)

Anyway, it's only an idea, and I thought I'd point it out as nobody  
else had yet.  If 0.0 is going to be cached, then I certainly think  
-0.0 and +0.0 should be two separate values if they exist on a given  
machine.  I'm less concerned about exactly how that comes about.

Kind regards,

Alastair.

--
http://alastairs-place.net