RetroSearch Browse

Thu Jun 24 12:10:52 EDT 2004 · http://mail.python.org/pipermail/python-dev/2004-June/045559.html

[Resending -- I got a weird bounce about this]

> > (For other operations, I still want to see e.g. long+float to return a
> > float rather than a long -- you *have* to do it this way for obvious
> > reasons when the values are relatively small, e.g. consider 1 + 0.5.)
> 
> That is not unreasonable behavior.  However, I wonder if it might be
> possible to do better by yielding a long in those cases where the value is
> so large that the LSB of a float would be >=1.  By doing so, it might be
> possible to guarantee that no precision is needlessly lost--analogously to
> having the result of int addition yield a long when an int cannot contain
> the result exactly.
> 
> Please understand that I am not advocating this strategy for arithmetic the
> way I am for comparison, because I am not sure about its formal properties.
> I'm going to think about it for a while; depending on my conclusions, I may
> change my opinion later.

Well, even if for comparisons we treat floats as if they were exact,
for other purposes I want to keep the association of "float" with
"inexact" and "int/long" with "exact", and I'd rather not return an
"exact" result from an operation involvin an "inexact" operand.

(The alternative, introducing exactness as a separate concept from
representation, is better in theory but in practice just complicates
matters needlessly.)

--Guido van Rossum (home page: http://www.python.org/~guido/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-June/045559.html below:

[Python-Dev] Comparing heterogeneous types