The memory simply blows up too fast for this to be practical (at least as a default) a float is always 64 bits, a fraction is unboundedly large if numerator and denominator are coprime.
A toy example with a half dozen operations won't make huge fractions. A loop over a million operations will often be a gigantic memory hog. That said, Chris's idea for a literal spelling of "Fraction" is very appealing. One extra letter or symbol could indicate that you want to work in the Fraction domain rather than floating point. That's a perfectly reasonable decision for a user to make. On Fri, May 14, 2021, 11:18 AM Martin Teichmann <[email protected]> wrote: > Hi Jonathan, > > I would agree with you if what I was asking was arbitrary precision math. > But this is not what I am asking for, what I am asking for is that integer > true division should result in a Fraction. The difference is huge: > arbitrary precision math is costly, and while arbitrarily precise, that > "arbitrary" does not include "exact". Fractions, on the other hand, are > exact. > > The speed argument also does not hold: whenever you do actual math on the > fractions, they will be seemlessly converted to floats. Anybody doing > anything speed will use something like numpy anyways, and there is no > discussion there, numpy uses floats, and I am not proposing to change that. > > To illustrate what I am talking about, see how it looks like in reality > (yes, this is the actual Python interpreter with my changes, not > artificially generated stuff): > > >>> from math import sin, sqrt > >>> sin(1/2) > 0.479425538604203 > >>> sqrt(1/4) > 0.5 > >>> (1/2)**2 > 1/4 > >>> (1/4)**(1/2) > 0.5 > >>> (1/2)**-2 > 4 > > Now you can ask, if everything is converted to floats anyways, where is > the benefit? The benefit is when you use symbolic math (or, indeed, > arbitrary precision math like the Decimal example I already mentioned): > > >>> from sympy import symbols, sqrt, sin > >>> x = symbols("x") > >>> sin(1/2) > sin(1/2) > >>> 1/2 + x > x + 1/2 > >>> 2/3 * x > 2*x/3 > >>> sqrt(1/4) > 1/2 > > So, my argument is, this change will benefit many people, and be of only a > small disadvantage to others. That disadvantage is that yes, there will be > places where it does not work, so libraries need to get fixed. But this is > the case with every Python update. Once it will be working, there will be > no disadvantage anymore. > > Cheers > > Martin > _______________________________________________ > Python-ideas mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/UPHKJPGK4BGG4DRYLZFKKAJNRPIH6LVP/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ODXXRDDFPSTOBZWX72PU5JO56QH7S2EM/ Code of Conduct: http://python.org/psf/codeofconduct/
