134
How Python Compares Floats and Ints: When Equals Isn’t Really Equal
(blog.codingconfessions.com)
this post was submitted on 27 May 2024
134 points (94.1% liked)
Technology
57418 readers
4308 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Unfortunately, that's not what it's about.
With Rust's language design¹, one could easily forbid ever comparing two floats via the normal operators (not just for literals), but they decided to allow that nonetheless. I'm guessing, because it would just be too annoying for generic implementations, if you'd always need special treatment for floats.
Rather, what I was referring to, is that they've split partial ordering and partial equality from their total variants. And integers are marked that they can do total equality and total ordering, whereas floats are not.
Honestly, it doesn't come up a lot, but I know for example, if you want to use something as a key in a HashMap, it needs to have total equality.
And in a BTreeMap (basically a binary tree, i.e. keys are inserted in a sorted manner), total ordering is required for the keys.
¹) Basically, comparison is typed and each type needs to opt into comparison with any type it wants to be compared to. So, if you define a new data type, then by default you cannot ask it whether it's equal to or less/more than anything else.