tw*********@hot mail.com (Jeremy Fincher) wrote:
Cliff Wells <cl************ @comcast.net> wrote in message news:<ma******* *************** *************** *@python.org>.. . Color me ignorant (I still maintain that numbers were a bad idea to
start with), but can you give an example of something that would
*require* this?
Accepting integer equations from untrusted users and evaluating them.
That's my exact use case, in fact.
So seemingly you have a problem with:
val = RangedInteger(i nt(user_provide d), mylow, myhigh)
Ok, so you've got a problem with that. *shrug*
It seems to me that whether an OverflowError occurs is
only one way of determining whether a computation is bounded,
It's not really a way of *determining* whether a computation is
bounded, but *guaranteeing* that it is bounded. What I eventually did
was simply convert all numbers to floats, and do my calculations with
those; but this results in some ugliness, for instance, when a user
asks for the value of "10**24".
Or any one of the other infinite values that binary floating point does
not represent exactly. What you have done is to take your problem of
limiting range, and attempt to fold it into a type with a larger dynamic
range, but with limited precision. Replacing an "OverflowError" , with a
possible future infinite value returned by float and known precision
issues with non-integer math.
What gets me is that you seem to be saying that BEFORE 2.4 has
officially come out, you have switched to using floats because 2.4 will
remove the OverflowError when integers overflow.
I suppose my position is this: if I have a computer that can perform a
calculation in a reasonable time without exhausting the resources of the
machine then I would think that Python shouldn't try to stop me from
doing it, at least not based on some arbitrary number of bits.
That's exactly it. With bounded integers, I know for sure that my
program can perform a calculation in a reasonable time without
exhausting the resources of the machine. Without them, I have to go
to great lengths to receive that assurance.
Ah, but you, or anyone else, only needs to implement it once for some
class of things, and it is done. People who want more or different
functionality are free to derive. With a little bit of futzing, you
could take the base code given by Andrew Dalke, add in custom handlers
for binary exponentiation with __pow__, and you're basically done.
Is there anything stopping you from doing this other than laziness and a
desire to complain "Python 2.4 doesn't have functionality X that it
choose_one_or_m ore(used_to_hav e, that_i_want)"?
- Josiah