[Eric S. Raymond] >> 1) Should future division return rationals rather than floats. > +1 for returning rationals. It's the right thing -- and if it fails, > it will fail noisily, right? 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. On the other hand, I would love if Python was not loosing precision on non-truncating integer division, so let me try a bit to destroy my own fears. On average, most programs will not use matrices of rational numbers, nor play with series. Moreover, most programs do not use so many different numeric variables anyway, nor perform long computations involving them. Many programs do not go beyond adding or subtracting one, once in a while! So, I would guess that _on the average_, using rational numbers might be acceptable and go almost unnoticed by most people. So it might be more worth accepting as a community to warn programmers who are more prone to numerical algorithms of the intrinsic dangers of integer division in Python. But those feelings are no proof of anything. How do we get the confirmation that using rationals in Python would be easy going and innocuous in practice, beforehand? It would surely be nice relying in such a feature! -- François Pinard http://www.iro.umontreal.ca/~pinard
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