> The danger I see here is that Scheme's "numeric tower" is almost obviously a > reasonable numeric model, but in practice is so vague that you can't really > count on anything beyond simple small-int arithmetic working the same way > across Scheme implementations. I certainly expect that we'll be able to do better than Scheme in our cross-implementation semantics -- Scheme is infamous for this. > Guido appears to have come to an > appreciation of that model in the abstract, but hoping that there's not much > difference between floats and rationals in practice "because they represent > the same mathematical values" just isn't going to pan out (IMO). 1/49*49 > equals 1 or it doesn't; it doesn't using IEEE doubles, it does using > rationals, and the difference will be significant to programs. Certainly > better to switch from floats to rationals someday than to move in the other > direction, though. Indeed, my only assumption is that switching from floats to rationals shouldn't be very disruptive. In my ideal numeric model, rationals auto-convert to floats but not the other way around, and str() and repr() of rationals would yield a decimal floating point representation similar to that of floats. (This is more or less what ABC did, except that for floats it added an annoying "~" as inexactness indicator.) To get a rational to print as x/y, you'd have to extract the numerator and denominator explicitly, or use some standard method. > I've come to suspect the issues *may& be complicated <wink>. Sure. --Guido van Rossum (home page: http://www.python.org/~guido/)
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