why couldn’t you compute p/q < r/s by checking ps < rq?
That’s what I meant by scaling the fractions. Tbh I kind of forgot that was an option and when I remembered I had allready written the part about comparing floats so I just left it in. But yeah, encoding lengh might be a killer there.
You could also avoid reducing fractions the same way. Like I don’t neecessairly need my fractions to be reduced, if I am just doing a few equality comparisons per fraction. Of course I would have to reduce them at some point to avoid exceding the encoding lentgh in the enumerator and denominator when there is a representation with a short enough encoding available.
I think the bigger problem might be the missing usecases. As another user mentioned, this would still only encode rationals perfectly (assuming no limit on encoding lengh). But I cannot see many usecases where having rationals encoded percisely, but irrationals still with an error is that usefull. Especially considering the cost.
maybe we could solve this by prohibiting the end user from adding or multiplying numbers
That’s what I meant by scaling the fractions. Tbh I kind of forgot that was an option and when I remembered I had allready written the part about comparing floats so I just left it in. But yeah, encoding lengh might be a killer there.
You could also avoid reducing fractions the same way. Like I don’t neecessairly need my fractions to be reduced, if I am just doing a few equality comparisons per fraction. Of course I would have to reduce them at some point to avoid exceding the encoding lentgh in the enumerator and denominator when there is a representation with a short enough encoding available.
I think the bigger problem might be the missing usecases. As another user mentioned, this would still only encode rationals perfectly (assuming no limit on encoding lengh). But I cannot see many usecases where having rationals encoded percisely, but irrationals still with an error is that usefull. Especially considering the cost.
I genuently chuckled, thanks :).