Why don't range and xrange threat floats as floats?
Why don't range and xrange threat floats as floats? Is there any good reason range and xrange don't threat floats as floats but as integers? When I enter float arguments in a range, the floats are treated as integers. (+ some warning) This is how I think it should work:
range(0, 1, 0.1) [0.0, 0.10000000000000001, 0.20000000000000001, 0.29999999999999999, 0.40000000000000002, 0.5, 0.59999999999999998, 0.69999999999999996, 0.80000000000000004, 0.90000000000000002]
I got these results by:
[x/10. for x in xrange(10)]
I'm not looking for alternatives, just for the reason that it works this way.
On Wed, Nov 5, 2008 at 1:26 PM, L V <somelauw@yahoo.com> wrote:
Why don't range and xrange threat floats as floats? Is there any good reason range and xrange don't threat floats as floats but as integers? When I enter float arguments in a range, the floats are treated as integers. (+ some warning)
This is how I think it should work:
range(0, 1, 0.1) [0.0, 0.10000000000000001, 0.20000000000000001, 0.29999999999999999, 0.40000000000000002, 0.5, 0.59999999999999998, 0.69999999999999996, 0.80000000000000004, 0.90000000000000002]
I got these results by:
[x/10. for x in xrange(10)]
I'm not looking for alternatives, just for the reason that it works this way.
This seems like a question to be asked on python-list, not python-dev. In any case, my best guess is that it's because of what you just showed, that the functionality you want is there already if you use a generator expression. There isn't much reason to make (x)range more complicated by letting it accept floats, when you can just scale the range you actually want up to some integral skip value, call range, and then scale it back down. -- Cheers, Leif
On Wed, Nov 5, 2008 at 10:26 AM, L V <somelauw@yahoo.com> wrote:
Why don't range and xrange threat floats as floats? Is there any good reason range and xrange don't threat floats as floats but as integers? When I enter float arguments in a range, the floats are treated as integers. (+ some warning)
This is how I think it should work:
range(0, 1, 0.1) [0.0, 0.10000000000000001, 0.20000000000000001, 0.29999999999999999, 0.40000000000000002, 0.5, 0.59999999999999998, 0.69999999999999996, 0.80000000000000004, 0.90000000000000002]
I got these results by:
[x/10. for x in xrange(10)]
I'm not looking for alternatives, just for the reason that it works this way.
The reason is that due to the rounding issues inherent to a binary representation of floating point, it is easy to give examples where it's ambiguous whether the end point was meant to be included or not. This could happen e.g. when the binary representation of the end point was rounded up a bit, while the step would be rounded down. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Thank you very much for your answer. I have wondered about this for a long time. ________________________________ From: Guido van Rossum <guido@python.org> To: L V <somelauw@yahoo.com> Cc: python-dev@python.org Sent: Wednesday, November 5, 2008 7:56:23 PM Subject: Re: [Python-Dev] Why don't range and xrange threat floats as floats? On Wed, Nov 5, 2008 at 10:26 AM, L V <somelauw@yahoo.com> wrote:
Why don't range and xrange threat floats as floats? Is there any good reason range and xrange don't threat floats as floats but as integers? When I enter float arguments in a range, the floats are treated as integers. (+ some warning)
This is how I think it should work:
range(0, 1, 0.1) [0.0, 0.10000000000000001, 0.20000000000000001, 0.29999999999999999, 0.40000000000000002, 0.5, 0.59999999999999998, 0.69999999999999996, 0.80000000000000004, 0.90000000000000002]
I got these results by:
[x/10. for x in xrange(10)]
I'm not looking for alternatives, just for the reason that it works this way.
The reason is that due to the rounding issues inherent to a binary representation of floating point, it is easy to give examples where it's ambiguous whether the end point was meant to be included or not. This could happen e.g. when the binary representation of the end point was rounded up a bit, while the step would be rounded down. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Guido van Rossum
-
L V
-
Leif Walsh