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
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 without an exception being raised. For example,
try int(float("nan
34 matches
Mail list logo
