[Python-3000] could range be smarter?
Owolabi Abdulkareem
I'm not really a programmer but I am working to be one
I just thought may be this is worth considering for future enhancement
with python's range
I've you considered trying out something of these nature with range:
/>>> 9000000 in range(20**30)/
you'll have to wait for sometime to get a response but if you try
something like this
/>>> 900000.7 in range(20**30)
/or even
/>>> 0.1 in range(20**30)/
range iterates through till the end before it gives you a response. It
is clear that a float could not be in the above range and /0.1/ is less
than a unit integer, why do the function /range /*have to iterate
through till the end* wasting CPU resource when it is clear that it is
not in the range.
To avoid this ,I have to /type check /and test if the number is an
integer and not a float .
Failure to do this would lead to my program to freeze until the
iteration is done. This makes range inefficient and one would have to
remember this for it does not do the job of checking for you or/ and if
a step is included in the range I have to test it with % operator:
Putting this in a function:
/
def Inrange(begin,end,step,number):
index=0 # Here is where the index of the number is placed if is in range
for i in begin,end,step,number:
if type(i) == type(int(i)): #Check to see all that parameters
are all integers
pass
else:
return 'All parameters must be integers'
try: #check
to see if parameters are appropriate to produce a true range
if (begin < end and step>0):
assert(begin <= number < end)
elif begin > end and step < 0:
assert(begin >= number > end)
else:
raise AssertionError
except AssertionError:
return 'Check your parameters ;range between them is not
executable'
if (number - begin)%step != 0:
return 'Your number is not in range'
else:
index=(number - begin) // step
return (True,index)
/
(I'm sorry about my code; any correction will be educating)
Ruby's range does the comparing check but gives an erroneous 'True' with
/(0 .. 20*30) include? 7.7482/
Where 7.7482 is a float ( and should not be found in a range of integers)
I think it would be nice (and more efficient for there won't be a need
to iterate through for this) if we could do this:
/
>>> 7.7483 in range(20**30)
Traceback (most recent call last):
File "<pyshell#145>", line 1, in <module>
7.7483 range(20**30)
TypeError: 'float' object cannot be in a range of integers
>>> 622168 in range(20**30,8)
(True, 77770)
>>> 1219 in range(-181,20**30,8)
(True, 175)
>>> range(-181,20**30,8)[175]
1219
>>> list(range(-181,20**30,8)).index[1219] # as in index = (number -
begin) // step
175/
In python 3.0 range(-181,20**30,8) gives:
/
Traceback (most recent call last):
File "<pyshell#175>", line 1, in <module>
list(range(20**20)).index(20)
OverflowError: Python int too large to convert to C ssize_t/
I believe this simple mathematical expression in the function above
could be used to avoid iteration for this and
go past this OverflowError (with some initial test similar to that in
the function 'Inrange' above):
/
number = index*step + begin
index = (number - begin) // step #making index the subject of formul/a
I don't know if something could be done about this now ( or if it is
really a good idea) especially when python 3000 is in its rc2 but I
thought I should say something on this.
Yours
Abdulkareem Owolabi
_______________________________________________
Python-3000 mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: http://mail.python.org/mailman/options/python-3000/python-3000-garchive-63646%40googlegroups.com
Vitor Bosshard
You're using range objects in ways that were hardly intended. If range objects had to be magically smart about everything, the language would be slower overall just to enable a questionable use case.
Plain comparison operators and isinstance or type checks against int will make your life a lot easier in this case:
>>> a = .1
>>> type(a) is int and 0 <= a < 20**30
False
Vitor
----- Mensaje original ----
> De: Owolabi Abdulkareem <adigu...@gmail.com>
> Para: pytho...@python.org
> Enviado: martes, 18 de noviembre, 2008 12:01:35
> Asunto: [Python-3000] could range be smarter?
> File "", line 1, in
> 7.7483 range(20**30)
> TypeError: 'float' object cannot be in a range of integers
>
> >>> 622168 in range(20**30,8)
> (True, 77770)
>
> >>> 1219 in range(-181,20**30,8)
> (True, 175)
>
> >>> range(-181,20**30,8)[175]
> 1219
>
> >>> list(range(-181,20**30,8)).index[1219] # as in index = (number -
> begin) // step
> 175/
>
> In python 3.0 range(-181,20**30,8) gives:
> /
> Traceback (most recent call last):
> File "", line 1, in
> list(range(20**20)).index(20)
> OverflowError: Python int too large to convert to C ssize_t/
>
> I believe this simple mathematical expression in the function above
> could be used to avoid iteration for this and
> go past this OverflowError (with some initial test similar to that in
> the function 'Inrange' above):
> /
> number = index*step + begin
> index = (number - begin) // step #making index the subject of formul/a
>
> I don't know if something could be done about this now ( or if it is
> really a good idea) especially when python 3000 is in its rc2 but I
> thought I should say something on this.
>
>
> Yours
>
> Abdulkareem Owolabi
> _______________________________________________
> Python-3000 mailing list
> Pytho...@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/algorias%40yahoo.com
____________________________________________________________________________________
¡Todo sobre Amor y Sexo!
La guía completa para tu vida en Mujer de Hoy.
http://mujerdehoy.telemundo.yahoo.com/
Robert Lehmann
> I just thought may be this is worth considering for future enhancement
> with python's range
>
> I've you considered trying out something of these nature with range:
>
> />>> 9000000 in range(20**30)/
>
> you'll have to wait for sometime to get a response
See http://bugs.python.org/issue1766304 for additional discussion on this
topic. Optimizations for this would have to be implemented on the C level.
> I don't know if something could be done about this now ( or if it is
> really a good idea) especially when python 3000 is in its rc2 but I
> thought I should say something on this.
I think optimizations can always be applied (though the core developers
might be busy with caring for release blockers rather than optimizations
right now).
--
Robert "Stargaming" Lehmann