I have to admit: If you (semi-)regularly use floating point comparisons in programming, I don’t know why you would ever expect 0.1 + 0.2 == 0.3 to return true. It’s common practice to check abs(a - b) < tol, where tol is some small number, to the point that common unit-testing libraries have built-in methods like assertEqual(a, b, tol) specifically for checking whether floats are “equal”.
Yeah, a lot of editors throw warnings for using the equals operator with floats by default, as far as I know it’s considered bad practice to do it that way.
The issue is a lot of people use floating point numbers, but don’t even know it.
How many programmers right now are using JS, the most popular language in the world? How many of them do you think understand floating point numbers and their theoretical levels of accuracy? How many of them are unknowingly using floating points to store currency values?
How many of them could accurately predict the result of the following?
2.99+1.52==4.51
2.99+1.53==4.52
2.99+1.54==4.53
Now imagine that as code to make sure you’ve paid the right amount in an online store. I guarantee you there is code out there right now that won’t let you finish a sale if the total of the basket adds up a certain way.
Then most people shouldn’t be writing code, I don’t know what else to tell you, this is probably one of the first thing you learn about FP arithmetic, and any decent compiler/linter should warn you about that.
But how far should that be taken should 8 == 8 return false because one is an unsigned int and the other is signed? Or 0.0 == 0.0 where they are floats and doubles? You can make a case for those due to a strong type system but it would go against most peoples idea of what equality is.
If bits aren’t same then i dont want it to tell me they are the same. And python just has one implementation for int and float.
I like python cos everything’s an object i dont want different types of objects to evaluate the same they are fundamentally different objects is that not what u would expect?
Even in python you can have control of what types of numbers are used under the hood with numpy arrays (and chances are if you are using floats in any quantity you want to be using numpy). I would be very surprised if array([1,2,3], dtype=uint8) == array([1,2,3], dtype=int16) gave [False, False, False]. In general I think == for numbers should give mathematical equivalence, with the understanding that comparing floats is highly likely to give false negatives unless you are extremely careful with what you are comparing.
Meh. Imo anyone comparing an integer to a float and not expecting one of them to be implicitly casted to the other’s type will create that issue for themselves when doing the same thing with an explicit cast.
I dont think comparisons should be doing type conversion if i compare a float to an int i want it to say false cos types are different.
I don’t think that’s how most programmers expect it to work at all.
However most people would also expect 0.1+0.2==0.3 to return true, so what do I know.
Floating point is something most of us ignore until it bites us in the ass. And then we never trust it again.
I have to admit: If you (semi-)regularly use floating point comparisons in programming, I don’t know why you would ever expect 0.1 + 0.2 == 0.3 to return true. It’s common practice to check
abs(a - b) < tol, wheretolis some small number, to the point that common unit-testing libraries have built-in methods likeassertEqual(a, b, tol)specifically for checking whether floats are “equal”.Yeah, a lot of editors throw warnings for using the equals operator with floats by default, as far as I know it’s considered bad practice to do it that way.
The issue is a lot of people use floating point numbers, but don’t even know it.
How many programmers right now are using JS, the most popular language in the world? How many of them do you think understand floating point numbers and their theoretical levels of accuracy? How many of them are unknowingly using floating points to store currency values?
How many of them could accurately predict the result of the following?
Now imagine that as code to make sure you’ve paid the right amount in an online store. I guarantee you there is code out there right now that won’t let you finish a sale if the total of the basket adds up a certain way.
Thats why i recon its good to keep u aware of it. Mind u i find its often fine as long as my ide and chagpt know what type it is im usually fine.
I do kinda like the rigidity of types tho. Proper Python type hints are a godsend.
Then most people shouldn’t be writing code, I don’t know what else to tell you, this is probably one of the first thing you learn about FP arithmetic, and any decent compiler/linter should warn you about that.
But how far should that be taken should 8 == 8 return false because one is an unsigned int and the other is signed? Or 0.0 == 0.0 where they are floats and doubles? You can make a case for those due to a strong type system but it would go against most peoples idea of what equality is.
If bits aren’t same then i dont want it to tell me they are the same. And python just has one implementation for int and float.
I like python cos everything’s an object i dont want different types of objects to evaluate the same they are fundamentally different objects is that not what u would expect?
Even in python you can have control of what types of numbers are used under the hood with numpy arrays (and chances are if you are using floats in any quantity you want to be using numpy). I would be very surprised if
array([1,2,3], dtype=uint8) == array([1,2,3], dtype=int16)gave[False, False, False]. In general I think==for numbers should give mathematical equivalence, with the understanding that comparing floats is highly likely to give false negatives unless you are extremely careful with what you are comparing.Numpys more or less a math wrapper for c isnt it?
Way too late for that. Every language I know makes some kind of auto conversion for numeric comparisons… and sometimes for strings as well.
That makes sense, but then you’d just have people converting the int to a float manually and run into the exact same issues.
I mean honestly its expected u should check floats similarity not equivalence.
Agreed. But the less experienced programmers I know are surprisingly naive about this.
Yeah its gonna be one of those problems chatgpt ain’t gonna help
They wouldn’t be running into an issue, but creating one, that’s different
Meh. Imo anyone comparing an integer to a float and not expecting one of them to be implicitly casted to the other’s type will create that issue for themselves when doing the same thing with an explicit cast.
What I meant is, the former can be a genuine mistake, the latter is a conscious (probably uneducated) decision
Idiots downvoting you (c/technology…) but this how e.g. Haskell and rust handle that, and probably most strongly typed languages
Yeah i think python needs stronger type enforcement i do like how they have been improving type hinting tho really helps with preventing bugs