On Fri, 14 May 2021 at 16:29, David Mertz <mertz@gnosis.cx> wrote:
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.
+1 on this. My experience has been that fraction classes are a lot less useful in (general) practical situations than people instinctively assume.
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.
Agreed, it is appealing. The problem (and this is not a new suggestion, it's come up a number of times) is that of having language syntax depend on non-builtin classes. So either you have to *also* propose making the fractions module a builtin, or you very quickly get sucked into "why not make this mechanism more general, so that libraries can define their own literals?" Scope creep is nearly always what kills these proposals. Or the base proposal is too specialised to gain enough support. Personally, I can see value in fraction, decimal and regex literals. But I can live without them. Paul