809
IEEE 754 (cdn.fosstodon.org)

~~Stolen~~ Cross-posted from here: https://fosstodon.org/@foo/113731569632505985

you are viewing a single comment's thread
view the rest of the comments
[-] needanke@feddit.org 4 points 4 days ago

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

I genuently chuckled, thanks :).

this post was submitted on 02 Jan 2025
809 points (99.3% liked)

Programmer Humor

32706 readers
132 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS