why couldn’t you compute p/q < r/s by checking ps < rq? if you follow the convention that denominators have to be strictly positive then you don’t even have to take signs into account. and you can check equality in the same way. no float conversion necessary. you do still need to eat a big multiplication though, which kind of sucks. the point you bring up of needing to reduce fractions after adding or multiplying also a massive problem. maybe we could solve this by prohibiting the end user from adding or multiplying numbers
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
why couldn’t you compute p/q < r/s by checking ps < rq? if you follow the convention that denominators have to be strictly positive then you don’t even have to take signs into account. and you can check equality in the same way. no float conversion necessary. you do still need to eat a big multiplication though, which kind of sucks. the point you bring up of needing to reduce fractions after adding or multiplying also a massive problem. 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 :).
It’s very easy to overflow