[Python-Dev] More int/long integration issues

[Chad Netzer]

On Thu, 2003-03-13 at 18:53, Guido van Rossum wrote:

> > a = 1/1e-5
> > range( a-20, a)
> 
> This should be a TypeError.  I'm sorry it isn't.

Yeah.  I can easily make it do this, BTW.  (ie. keep it backwards
compatible for smaller floats, but disallow it when dealing with PyLong
size floats).  With large floats, the implicit conversion to PyLong gets
even less sensible, due to granularity issues.

> > a = 1/1e-6
> > b = 1/1e-5
> > c = 1/1e-4
> > range(a, b, c)
> 
> Ditto.
> 
> (BTW why don't you write this as 1e6, 1e5, 1e4???)

Just emphasizing that the coders may not have even expected to be
dealing with such "large" values, but they got them anyway because they
were plotting very "small" values (and the plotting operation did the
inversion).  A bad choice of example, I guess.

Okay, I decided to go look at the specific code I was talking about.  It
essentially did stuff like:

large_float = 1e20
a = long( math.ceil( large_float ) )
b = a + 10
range( a, b )

So, it actually wasn't submitting floats to range(), but was expecting
it to work on long values (within the limits of memory).  Again, it is
also easy to fix these uses, but we agree that in principle that it
should work...

I've heard others doing number theory work, who hoped or expected it to
work, as well.  (Typically, they wanted to use HUGE step sizes, for
example)

In any case, I'll get the patch submitted fairly soon, for range(). 
Need to update the tests.

> But 1/1e-21 is not a long.  It's a float.  You're flirting with
> disaster here.

Yep. I agree.

> > And if range() is fixed, then sadly,
> > xrange() should be fixed as well (IMO).
> 
> No.

Alright.  That makes things (fairly) easy. :)

> > BTW, I'm all for deprecating xrange() with all deliberate speed.  Doing
> > so would only make updating range behavior easier.
> 
> It can't be deprecated until we have an alternative.  That will have
> to wait until Python 2.4.

I'm also coding an irange() for consideration in the itertools module.
At least an (explicit) replacement for the iteration usage (although,
maybe not necessary if you actually do the lazy-list in "for" loop
change.)  If people need the indexing and length operations, too, I can
only suggest a pure python implementation (which could return an
irange() iterator when needed).  Is that a dead-end idea, or a starter?


Chad Netzer