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 <martin.teichm...@gmail.com>
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 -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UPHKJPGK4BGG4DRYLZFKKAJNRPIH6LVP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ODXXRDDFPSTOBZWX72PU5JO56QH7S2EM/
Code of Conduct: http://python.org/psf/codeofconduct/
