On 5/14/21 12:16 PM, Ricky Teachey wrote:
On Fri, May 14, 2021 at 12:02 PM Chris Angelico <rosuav@gmail.com <mailto:rosuav@gmail.com>> wrote:
On Sat, May 15, 2021 at 1:47 AM Martin Teichmann <martin.teichmann@gmail.com <mailto:martin.teichmann@gmail.com>> wrote: > > Hi David, > > > 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. > > I do not propose to do that, and I agree that it would be stupid. Usually, the fraction gets very quickly converted into a float, and your millions of operations will be done with floats. >
But if integer division gave a Fraction, then at what point would it be converted into a float? As long as all the literals are integers, it would remain forever a rational, and adding fractions does get pretty costly.
ChrisA
I think most of the time, people just want to do an accurate enough division operation and don't really have an opinion what the output type is (so long as it works), but for the situations where the type really really does matter, you can choose the type by using Fraction(1,2) or 1/2. If precision is critical, you can already have it with the Fraction choice.
But I would also assume there are probably some fraction (tee hee) of situations where people specifically want/need a float from an integer division operation and NOT a fraction, and would either have to take the extra step to convert it. If you're in a loop doing millions of conversions, seems like that could get slow.
A way around this would be to add a new integer division operation that returns float:
>>> 1/2 Fraction(1, 2) >>> 1//2 0 >>> 1///2 # new float division operator 0.5
But that doesn't seem like a very optimal solution to me.
So +1 for fraction literal PEP (not sure I would want it approved or not, but it should get a full hearing), -1 for changing the output type of integer division.
--- Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
If anything like this was done, the NEW operator needs to be the fraction and the original / the float, for backwards compatibility. I would say that I have enough code that does division of numbers that might be integers that expect it to be relatively efficient as floats, and I suspect so do others, that the backwards breaks would be significant. The cases where you really need the fraction are much smaller, and if you do, having a convenient way to ask for it could be useful, but not so useful that it is worth breaking all the code that expects floats. It wouldn't be quite as bad as the python2 -> python3 string/bytes changes, but the comparison isn't totally out of line. -- Richard Damon