int/long unification hides bugs
Andrew Dalke
adalke at mindspring.com
Sat Oct 30 22:34:42 EDT 2004
More information about the Python-list mailing list
Sat Oct 30 22:34:42 EDT 2004
- Previous message (by thread): int/long unification hides bugs
- Next message (by thread): int/long unification hides bugs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeremy Fincher wrote: > How long with this take to run? > > >>>>a = RangedNumber(2**31, 0, 2**32) >>>>a ** a It wouldn't -- I didn't implement __pow__. ;) > I think our inability to write a RangedNumber that piggybacks on > Python's integers should be obvious. It sounds like you don't like that the simple __pow__ implementation will raise a MemoryError after a long time when you would rather have it raise a bounds violation error early. If you want that, you could have an implementation that uses a few logs to check for that possibility. Though I'm not sure how to do the bounds checking for the 3 arg form. Given a as above, I know that pow(a, a, 2**50) but without doing the computation my bounds checker can't (or at least shouldn't) be that clever. Should it require that the 3rd arg always be in the allowed range? What about a = RangedNumber(100, 100, 400) pow(a, 25424134, 321) ? It turns out the result is 321 which is in the right range, but I can't know that without basically doing the calculation. Andrew dalke at dalkescientific.com
- Previous message (by thread): int/long unification hides bugs
- Next message (by thread): int/long unification hides bugs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list