Distinguish "raw" fractions and irreducible fractions

[Gouvernathor]

Reducing a franction to an irreducible form can be a relatively expensive operation compared to basic math operations (addition, subtraction, multiplication, division).
In another library, which is Fraction.ts (github version), I found that it could be handy to have two distinct types, a "raw" fraction type that does the fastest math available for basic operations, at the cost of the end fraction not being in an irreducible form, and implement a toIrreducible method that converts it to irreducible. And a derived IrreducibleFraction type that returns a RawFraction for most methods but overrides some of them such as toIrreducible.
That would allow, if I have a complex expression using a lot of math operations, to call the reduction to irreducible only at the end of the calculation − or not at all in fact, if not necessary.

As that can be a breaking change, there could be the following solution:

• the RawFraction, that offers no guarantees of being in irreducible form
  • it could be chosen, or not, to keep the denominator positive, as that is relatively costless compared to the rest
  • its methods return RawFraction objects
  • it has toIrreducible()
• the IrreducibleFraction, that guarantees being always in irreducible form
  • its methods return RawFraction objects
  • it has a trivial toIrreducible() method (returning self or a clone of self)
• the Fraction, that guarantees being always in irreducible form, and meant too be used on its own
  • it could derive from IrreducibleFraction for implementation's sake
  • each of its methods and operators basically calls toIrreducible at the end and returns a Fraction
  • it doesn't need to have a public toIrreducible() method, though if it's derived it will be inevitable

[dnsl48]

Hi @Gouvernathor, thanks for opening the ticket and for the great detailed explanation.

The current logic of normalizing the ratios lives inside the Ratio type constructor.
Our GenericFraction type is a wrapper around the Ratio type. We may need to think in terms of substituting Ratio with RawRatio (an example is our GenericFraction::new_raw constructor).

However, the hard part here is to guarantee the calculation correctness for non-normalized numbers. I don't have any examples at the top of my mind, but there might be some edge-cases. E.g. some float functions implementation may expect reduced denoms and might give incorrect results for Raw values as an outcome. I think some of our "formatting" functionality is currently assuming that the fraction is reduced (normalized), the PoC feels relatively easy, while the stabilization of this feature would be more substantial amount of work.

[Gouvernathor]

I understand now that the Ratio type comes from another lib, num (according to the dependencies) or num_rational (according to the docs). I have trouble understanding which are standard and which are not, but that's probably besides the point.

So, the num_rational lib is about representing ratios of (mostly) integers, generating them from float values, ordering them, and reducing them to irreducible form.
If this lib's job is to add the math operators and saveability in various database formats, I don't understand why the ordering goes in the other lib. The separation of responsibilities feels very strange to me.

In the end, I don't really see what "float functions implementations" would require a ratio in irreducible form. If it's just a division, why would it change anything to the result ?
About the formatting, yes, I suppose it would change the resulting string or what gets sent to a database, but only for the RawFractions as I put it, which doesn't necessarily need to have all the database support Fraction has. The two other kinds would behave as-is.

One last thought though, is that since your fractions are generic, and in the case BigUint is not used as the members' types (say u16 instead), there could be a long succession of operations that would avoid overflow if regularly trimmed, and risk overflowing if trimmed only at the end.
That could be circumvented by trying the operation (using CheckedStuff, right ?), and if it fails, trimming the input and trying again.
But it would certainly add complexity to the system.