On 2006-06-15, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Grant]
>> Am I remebering incorrectly?
>
> Mostly but not entirely.
>
>> Didn't the old fixed-width integers operate modulo-wordsize?
>
> Not in Python.
>
>> I distinctly remember having to rewrite a bunch of checksum code when
>> fixed-width
In article <[EMAIL PROTECTED]>,
Grant Edwards <[EMAIL PROTECTED]> 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/JAV
[Nick Maclaren]
Firstly, a FAR more common assumption is that integers wrap in twos'
complement - Python does not do that.
[Grant Edwards]
>>> It used to
[Fredrik Lundh]
>> for integers ? what version was that ?
[Grant]
> Am I remebering incorrectly?
Mostly but not entirely.
> Didn'
On 2006-06-15, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>
>>> Firstly, a FAR more common assumption is that integers wrap in twos'
>>> complement - Python does not do that.
>>
>> It used to
>
> for integers ? what version was that ?
Am I remebering incorrectly? Didn't the
On 2006-06-15, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>|>> Firstly, a FAR more common assumption is that integers wrap in twos'
>|>> complement - Python does not do that.
>|>
>|> It used to, and I sure wish there was still a way to get that
>|> behavior back. Now I have to do all sorts of bitw
Grant Edwards wrote:
>> Firstly, a FAR more common assumption is that integers wrap in twos'
>> complement - Python does not do that.
>
> It used to
for integers ? what version was that ?
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Grant Edwards <[EMAIL PROTECTED]> writes:
|> >
|> > Firstly, a FAR more common assumption is that integers wrap in twos'
|> > complement - Python does not do that.
|>
|> It used to, and I sure wish there was still a way to get that
|> behavior back. Now I have to
On 2006-06-15, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>|> Making Python incompatible with IEEE |> 754 is a bad idea.
>
> No, that is wrong, on many counts.
>
> Firstly, a FAR more common assumption is that integers wrap in twos'
> complement - Python does not do that.
It used to, and I sure wis
In article <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
|>
|> As one of the few people on this group who will admit to programming
|> before 1980, let alone doing numerical programming then (I presume
|> writing code to process gigabytes of seismic data via Fast Fourier
|
In article <[EMAIL PROTECTED]>,
Grant Edwards <[EMAIL PROTECTED]> writes:
|> On 2006-06-15, Nick Maclaren <[EMAIL PROTECTED]> wrote:
|>
|> > Hence, the SAFE approach is to make the inverse of all zeros a
|> > NaN.
|>
|> OK. You're right. I'm wrong about what my Python programs
|> should do.
|>
Nick Maclaren wrote:
> ...
> Now, I should like to improve this, but there are two problems. The
> first is political, and is whether it would be acceptable in Python to
> restore the semantics that were standard up until about 1980 in the
> numerical programming area. I.e. one where anything tha
On 2006-06-15, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> Hence, the SAFE approach is to make the inverse of all zeros a
> NaN.
OK. You're right. I'm wrong about what my Python programs
should do.
In any case, that ship sailed.
Maybe you can argue convincingly that theoretically your
approa
On 2006-06-15, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>
> In article <[EMAIL PROTECTED]>,
> Grant Edwards <[EMAIL PROTECTED]> writes:
>|>
>|> I assume the "you" in that sentence refers to the IEEE FP
>|> standards group. I just try to follow the standard, but I have
>|> found that the behavior
In article <[EMAIL PROTECTED]>,
Christophe <[EMAIL PROTECTED]> writes:
|>
|> > Now, can you explain why 1/0 => -Inf wouldn't work as well? I.e. why
|> > are ALL of your zeroes, INCLUDING those that arise from subtractions,
|> > are known to be positive?
|>
|> I would say that the most common rea
Nick Maclaren a écrit :
> Now, can you explain why 1/0 => -Inf wouldn't work as well? I.e. why
> are ALL of your zeroes, INCLUDING those that arise from subtractions,
> are known to be positive?
I would say that the most common reason people assume 1/0 = Inf is
probably because they do not make
In article <[EMAIL PROTECTED]>,
Grant Edwards <[EMAIL PROTECTED]> writes:
|>
|> I assume the "you" in that sentence refers to the IEEE FP
|> standards group. I just try to follow the standard, but I have
|> found that the behavior required by the IEEE standard is
|> generally what works best for
On 2006-06-14, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>
> In article <[EMAIL PROTECTED]>,
> Gary Herron <[EMAIL PROTECTED]> writes:
>|>
>|> The IEEE standard specifies (plus or minus) infinity as the result of
>|> division by zero. This makes sense since such is the limit of division
>|> by a q
On 2006-06-14, Sébastien Boisgérault <[EMAIL PROTECTED]> wrote:
> Jeez, 12 posts in this IEEE 754 thread, and still no message
> from uncle timmy ? ;)
>
> Please, we need enlightenment here and *now* :)
What we need is fewer people like me who do nothing but
complain about it...
--
Grant Edward
On 14 Jun 2006 10:33:21 -0700, Sébastien Boisgérault
<[EMAIL PROTECTED]> wrote:
> Jeez, 12 posts in this IEEE 754 thread, and still
> no message from uncle timmy ? ;)
Somebody reboot the timbot, please. Seems to have hung.
--
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simo
In article <[EMAIL PROTECTED]>,
Gary Herron <[EMAIL PROTECTED]> writes:
|>
|> The IEEE standard specifies (plus or minus) infinity as the result of
|> division by zero. This makes sense since such is the limit of division
|> by a quantity that goes to zero. The IEEE standard then goes on to
|>
Jeez, 12 posts in this IEEE 754 thread, and still
no message from uncle timmy ? ;)
Please, we need enlightenment here and *now* :)
platform-dependent accident'ly yours,
SB
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-06-14, Christophe <[EMAIL PROTECTED]> wrote:
The division by zero trap is really annoying. In my world the
right thing to do is to return Inf.
>>>
>>>Your world is flawed then, this is a big mistake. NaN is the
>>>only aceptable return value for a division by zero.
>>
>> You're p
In article <[EMAIL PROTECTED]>,
Scott David Daniels <[EMAIL PROTECTED]> writes:
|> Grant Edwards wrote:
|>
|> > While you're at it, the pickle modules need to be fixed so they
|> > support NaN and Inf. ;)
|>
|> The NaN problem is portability -- NaN values are not standard, and
|> pretending they
In article <[EMAIL PROTECTED]>,
Gary Herron <[EMAIL PROTECTED]> writes:
|> Christophe wrote:
|> > Grant Edwards a =E9crit :
|> >
|> >> The division by zero trap is really annoying. In my world the
|> >> right thing to do is to return Inf.
|> >
|> > Your world is flawed then, this is a big mistake
Grant Edwards a écrit :
> On 2006-06-14, Christophe <[EMAIL PROTECTED]> wrote:
>
>>Grant Edwards a écrit :
>>
>>>The division by zero trap is really annoying. In my world the
>>>right thing to do is to return Inf.
>>
>>Your world is flawed then, this is a big mistake. NaN is the
>>only aceptable
Christophe wrote:
> Grant Edwards a écrit :
>
>> The division by zero trap is really annoying. In my world the
>> right thing to do is to return Inf.
>>
>
> Your world is flawed then, this is a big mistake. NaN is the only
> aceptable return value for a division by zero.
>
Sorry, but t
On 2006-06-14, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>
>> While you're at it, the pickle modules need to be fixed so they
>> support NaN and Inf. ;)
> The NaN problem is portability -- NaN values are not standard,
My copy of IEEE 754 defines them quite precisely. :
On 2006-06-14, Christophe <[EMAIL PROTECTED]> wrote:
> Grant Edwards a écrit :
>> The division by zero trap is really annoying. In my world the
>> right thing to do is to return Inf.
>
> Your world is flawed then, this is a big mistake. NaN is the
> only aceptable return value for a division by ze
Grant Edwards wrote:
> While you're at it, the pickle modules need to be fixed so they
> support NaN and Inf. ;)
The NaN problem is portability -- NaN values are not standard, and
pretending they are won't help. There are many possible NaNs, several
of which have desirable behaviors, and differen
Grant Edwards a écrit :
> The division by zero trap is really annoying. In my world the
> right thing to do is to return Inf.
Your world is flawed then, this is a big mistake. NaN is the only
aceptable return value for a division by zero.
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-06-14, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>|>> Now, I should like to improve this, but there are two problems. The
>|>> first is political, and is whether it would be acceptable in Python to
>|>> restore the semantics that were standard up until about 1980 in the
>|>> numerical prog
In article <[EMAIL PROTECTED]>,
Grant Edwards <[EMAIL PROTECTED]> writes:
|> >
|> > Now, I should like to improve this, but there are two problems. The
|> > first is political, and is whether it would be acceptable in Python to
|> > restore the semantics that were standard up until about 1980 in
On 2006-06-14, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>
> The numerical robustness of Python is very poor - this is not its fault,
> but that of IEEE 754 and (even more) C99. In particular, erroneous
> numerical operations often create apparently valid numbers, and the
> NaN state can be lost wi
33 matches
Mail list logo
