Numerics, NaNs, IEEE 754 and C99

[Grant Edwards]

Re: Numerics, NaNs, IEEE 754 and C99

On 2006-06-15, Fredrik Lundh <fredrik@python ware.com> wrote:[color=blue]
> Grant Edwards wrote:
>[color=green][color=darkred]
>>> Firstly, a FAR more common assumption is that integers wrap in twos'
>>> complement - Python does not do that.[/color]
>>
>> It used to[/color]
>
> for integers ? what version was that ?[/color]

Am I remebering incorrectly? Didn't the old fixed-width
integers operate modulo-wordsize? I distinctly remember having
to rewrite a bunch of checksum code when fixed-width integers
went away.

--
Grant Edwards grante Yow! My uncle Murray
at conquered Egypt in 53
visi.com B.C. And I can prove
it too!!

[Tim Peters]

Re: Numerics, NaNs, IEEE 754 and C99

[Nick Maclaren][color=blue][color=green][color=darkred]
>>>> Firstly, a FAR more common assumption is that integers wrap in twos'
>>>> complement - Python does not do that.[/color][/color][/color]

[Grant Edwards][color=blue][color=green][color=darkred]
>>> It used to[/color][/color][/color]

[Fredrik Lundh][color=blue][color=green]
>> for integers ? what version was that ?[/color][/color]

[Grant][color=blue]
> Am I remebering incorrectly?[/color]

Mostly but not entirely.
[color=blue]
> Didn't the old fixed-width integers operate modulo-wordsize?[/color]

Not in Python.
[color=blue]
> I distinctly remember having to rewrite a bunch of checksum code when
> fixed-width integers went away.[/color]

Best guess is that you're working on a 32-bit box, and remember this
Python <= 2.2 behavior specific to the left shift operator:
[color=blue][color=green][color=darkred]
>>> 1 << 31[/color][/color][/color]
-2147483648[color=blue][color=green][color=darkred]
>>> 1 << 32[/color][/color][/color]
0

On a 64-bit box (except Win64, which didn't exist at the time ;-)),
those returned 2**31 and 2**32 instead, while "1 << 64" wrapped to 0
(etc).

Python 2.3 starting warning about that:
[color=blue][color=green][color=darkred]
>>> 1 << 31[/color][/color][/color]
__main__:1: FutureWarning: x<<y losing bits or changing sign will
return a long in Python 2.4 and up
-2147483648

and Python 2.4 started producing platform-independent results:
[color=blue][color=green][color=darkred]
>>> 1 << 31[/color][/color][/color]
2147483648L[color=blue][color=green][color=darkred]
>>> 1 << 32[/color][/color][/color]
4294967296L

+ - * / on short ints always complained about overflow before int-long
unification, although IIRC very early Pythons missed the overflow
error in (on a 32-bit box) int(-(2L**31))/-1.

[Nick Maclaren]

Re: Numerics, NaNs, IEEE 754 and C99


In article <129300g5np02c8 a@corp.supernew s.com>,
Grant Edwards <grante@visi.co m> writes:
|>
|> > which IEEE 754 assumes that the code will test and take
|> > appropriate action (which can be anything, including aborting
|> > the program and replacing it by a NaN). See
|> > http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
|>
|> IEEE Std 754-1985, subclause 7.2 - Division by Zero
|>
|> "If the divisor is zero and the dividend is a finite nonzero
|> number, then the division by zero shall be signaled. The
|> result, when no trap occurs, shall be a correctly signed
|> (infinity symbol)(6.3)."
|>
|> To me it looks like the spec specifically allows for a case
|> where "no trap occurrs" and the result is Inf.

That is correct. And it is a mandatory case. But it does NOT say what
the software should then do with the exception.


Regards,
Nick Maclaren.

[Grant Edwards]

Re: Numerics, NaNs, IEEE 754 and C99

On 2006-06-15, Tim Peters <tim.peters@gma il.com> wrote:
[color=blue]
> [Grant][color=green]
>> Am I remebering incorrectly?[/color]
>
> Mostly but not entirely.
>[color=green]
>> Didn't the old fixed-width integers operate modulo-wordsize?[/color]
>
> Not in Python.
>[color=green]
>> I distinctly remember having to rewrite a bunch of checksum code when
>> fixed-width integers went away.[/color]
>
> Best guess is that you're working on a 32-bit box, and remember this
> Python <= 2.2 behavior specific to the left shift operator:
>[color=green][color=darkred]
>>>> 1 << 31[/color][/color]
> -2147483648[color=green][color=darkred]
>>>> 1 << 32[/color][/color]
> 0[/color]

That's probably it.

I've also spent some time on/off fighting with 32-bit constants
that have the high-order bit set. You've got to jump through
hoops when you need to pass a value like 0xC0000000 to an
extension that demands a 32-bit value.
[color=blue]
> + - * / on short ints always complained about overflow before
> int-long unification,[/color]

I was definitely mis-remembering things. I had to have been
the left shift that caused the problems.

--
Grant Edwards grante Yow! I'm CONTROLLED by
at the CIA!! EVERYONE is
visi.com controlled by the CIA!!