[François Pinard] > While I agree with the theoretical arguments, I have the practical fear that > rationals could grow very big, rather quickly, in the course of a long > computation involving them in various ways. By big, I mean the numerator > and denominator of the fraction taken in isolation, not the number itself. > Consider inversions of an integer matrices, approximations with truncated > series, or worse things like, maybe, discrete Fourier transforms. > > Bigger rationals are, slower they become, and more memory they take. The > danger is that programmers may get surprised or hurt by Python performance > degradation, raising frequent and recurrent questions here and elsewhere. There should be a builtin variable (overriddable within some inner scope) for a maximum denominator magnitude. It should default to some value where performance tanks. If set to None, then no limit would apply. The HP32SII calculator implements a useful rational model using flags and a maximum denominator register. If the first flag is clear, fractions are have denominators upto the maximum value. If only the first flag is set, fractions always use the maximum denominator as the denominator and are then reduced (i.e. if the max is 8, then .5 is represented as 1/2 and .1 is represented as 1/8). [Christopher A. Craig] > > 3) Should rationals try to hash the same as floats? My leaning on > > this is that it will be decided by (2). If they compare equal when > > 'close enough' then they should hash the same, if not then they should > > only hash the same when both are integral. I would rather not see .5 > > hash with rational(1, 2) but not .2 with rational(1, 5). [Eric Raymond] > APL faced this problem twenty-five years ago. I like its solution; > a `fuzz' variable defining the close-enough-for-equality range. Instead of a global fuzz variable, I would prefer a fuzzy compare function with a specifiable fuzz factor and a reasonable default setting. This approach is more explicit in leaving == as an exact compare, specifying nearlyequal(a,b) when that is what is meant, and providing a locally specifiable factor on each compare, for example, nearlyequal(a,b, absolute=1e-7). Also, a fuzzy compare function could be set to use absolute or relative differences when needed. For example: if nearlyequal(a,b, relative=.01): # are a and b within 1% Raymond Hettinger
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4