3:16 Which is a bit of an over-generalization. This is why IEEE754 defines the “inexact” condition; when you see this raised, that is when you know that exact equality comparisons aren’t going to work. People assume that “inexact” is always going to be the case. But there are situations where exact floating-point computations can be done. Does Python give you access to the “inexact” state? Not with built-in functionality, but I have a module (pyfenv) which does.
The other common way to deal with this is to not use floats, and instead use a type that basically avoids the base translation (accepting that it uses a bit more memory). Imagine using four bits per decimal digit (16 possible values, but only 10 used in practice). The actual implementation is no doubt more efficient, but this shows that it's at least possible.
Many languages have a currency type. Python has libraries to support it. Basically, it stores values as an integer (or 64-bit integer) in the currencies smallest form (i.e. cents) but displays as a floating point. $5.24 is just stored as a "524". Given that int64s can reach 9,223,372,036,854,775,807, that means you can still total, sum, multiply, etc. values equal to all the money on the planet, in cents.
You've really hit your stride David! I've been watching the videos on your channel over the past few months, and this one, I have to say is very well done, and you've managed to explain things in such a nice way. Kudos!
i find that i've actually never had to check equality of floats, except 0.f or 1.f when i know i just assigned it i try to keep as few floats in my code as possible for consistency
The expression adds a condition that returns false if the compared numbers isclose. So it returns false if the original condition is false or the numbers compared is close. And it returns true only when the original condition is true and the numbers compared is not close.
Try comparing 0.1 + 0.2 == 0.3 in C -> it returns true. :O So why C, which uses the very same IEEE 754 standard for floating point numbers, returns the correct answer, where Python, Javascript and other interpreted programming languages gossip?
this could be due to compiler optimization. it might even the case that the compiler gets rid of the calculation completely and just writes the result into the executable. edit: compiler shenanigans aside, it also depends on the data type: C floats are 32 bit long, C doubles are 64 bit long (Python uses also 64bit floats). Using the 32bit version, it just happens that 0.1+0.2 is rounded to the same bit representation as 0.3, yielding true. Just because floating point equalities can fail, doesn't mean that they must fail. 0.1+0.2==0.3 is just an easy way to raise awareness for that issue (for doubles). A float version that fails is for example 0.1+0.6==0.7.
An integer is just stored as base 2 or 2's complement if the first number is a 1 making it negative if it is signed. A float stores a smaller integer and then another number that give the power to multiply that number by.
It's like how you would in decimal, especially if you love scientific notation. Integers are stored like this but in binary: 314,159 Floats are stored like this but in binary: (-1)^0 * 3.14159 * 10^5
Say you want the number 5, it is simply 2^2 + 2^0, If you want decimal 0.5, it is simply 2^(-1) so decimals are sums of 2 to the power of some negatives. and integers are sums of 2 to the power of some positives. That's at least what I have been taught :)
If I found this on my own I would have indeed smashed my keyboard into my computer last time I compared something that I used .lower() on to something with a capital letter, took me an hour to find ='D
Actually comparison of floating point defaults linguistically to exact comparisons without tolerance. Comparing those is also interesting as NaN and even +/-zero must be checked first. Not to mention inequalities. What you are showing is inexact comparison which practically useful, it's way too misleading to say this is how to compare floats. In some contexts this method would cause a system failure. NASA won't be hiring you if you disregard exact comparison, needless to say
This is a problem with how floating point numbers work regardless of language. No matter which language you use, you’ll need to be aware of how that particular language deals with this quirk. So stop gatekeeping you absolute dork
3:16 Which is a bit of an over-generalization. This is why IEEE754 defines the “inexact” condition; when you see this raised, that is when you know that exact equality comparisons aren’t going to work.
People assume that “inexact” is always going to be the case. But there are situations where exact floating-point computations can be done.
Does Python give you access to the “inexact” state? Not with built-in functionality, but I have a module (pyfenv) which does.
Very nice package, Lawrence. Thanks for sharing.
The more I watch your videos, the more it dawns on me that I don't know anything. Brilliant!
Ha! I’m so happy you’re learning new things! I know this feeling well, myself. I keep learning new things and will keep sharing them with you, too!
Just got it recommended, great content! Shame that you stopped making it
It is a shame... and I will be changing that soon!
really well explained and lots of new information for me, thanks a lot and keep up the good work! :)
The other common way to deal with this is to not use floats, and instead use a type that basically avoids the base translation (accepting that it uses a bit more memory).
Imagine using four bits per decimal digit (16 possible values, but only 10 used in practice). The actual implementation is no doubt more efficient, but this shows that it's at least possible.
Many languages have a currency type. Python has libraries to support it. Basically, it stores values as an integer (or 64-bit integer) in the currencies smallest form (i.e. cents) but displays as a floating point. $5.24 is just stored as a "524". Given that int64s can reach 9,223,372,036,854,775,807, that means you can still total, sum, multiply, etc. values equal to all the money on the planet, in cents.
Haven’t even watched the video but I like where this is going
You've really hit your stride David! I've been watching the videos on your channel over the past few months, and this one, I have to say is very well done, and you've managed to explain things in such a nice way.
Kudos!
Thank you so much, Nafiul! That really means a lot to me.
Nice video David, thanks for producing such a good content
Thanks so much, Gabriel! Glad you enjoyed it.
Nice video! Instantly subscribed
Awesome, thank you!
i find that i've actually never had to check equality of floats, except 0.f or 1.f when i know i just assigned it
i try to keep as few floats in my code as possible for consistency
Another great video!
Thanks, Eric! I appreciate it.
I understand all except example, not math.isclose(num1, num2) and num1> num2.
Please could you explain, please?
this syntax really high level that my small brain can't understand it
The expression adds a condition that returns false if the compared numbers isclose. So it returns false if the original condition is false or the numbers compared is close. And it returns true only when the original condition is true and the numbers compared is not close.
Imagine replacing "X >= Y" with "X == Y or X > Y", then replacing the "X == Y" part with "math.isclose(X, Y)"
@@emurphy42 thanks, finally understand it.
Try comparing 0.1 + 0.2 == 0.3 in C -> it returns true. :O So why C, which uses the very same IEEE 754 standard for floating point numbers, returns the correct answer, where Python, Javascript and other interpreted programming languages gossip?
Because they suck!!
this could be due to compiler optimization. it might even the case that the compiler gets rid of the calculation completely and just writes the result into the executable.
edit: compiler shenanigans aside, it also depends on the data type: C floats are 32 bit long, C doubles are 64 bit long (Python uses also 64bit floats). Using the 32bit version, it just happens that 0.1+0.2 is rounded to the same bit representation as 0.3, yielding true.
Just because floating point equalities can fail, doesn't mean that they must fail. 0.1+0.2==0.3 is just an easy way to raise awareness for that issue (for doubles). A float version that fails is for example 0.1+0.6==0.7.
How are ints and floats stored differently?
Both are stored as binaries, but integers don't run into the same problem described in the video.
An integer is just stored as base 2 or 2's complement if the first number is a 1 making it negative if it is signed.
A float stores a smaller integer and then another number that give the power to multiply that number by.
It's like how you would in decimal, especially if you love scientific notation.
Integers are stored like this but in binary: 314,159
Floats are stored like this but in binary: (-1)^0 * 3.14159 * 10^5
Say you want the number 5, it is simply 2^2 + 2^0,
If you want decimal 0.5, it is simply 2^(-1)
so decimals are sums of 2 to the power of some negatives.
and integers are sums of 2 to the power of some positives.
That's at least what I have been taught :)
If I found this on my own I would have indeed smashed my keyboard into my computer
last time I compared something that I used .lower() on to something with a capital letter, took me an hour to find ='D
I've better for you: use the decimal standard module, with the Decimal class.
I really can't believe that there's such a function and it is standard.
Actually comparison of floating point defaults linguistically to exact comparisons without tolerance. Comparing those is also interesting as NaN and even +/-zero must be checked first. Not to mention inequalities. What you are showing is inexact comparison which practically useful, it's way too misleading to say this is how to compare floats. In some contexts this method would cause a system failure. NASA won't be hiring you if you disregard exact comparison, needless to say
Why don't we get this error on calculators? Is it because calculators don't store numbers?
im literally too stupid to understand any of what you just said
Hello. In case you're wondering, your face looks a lot like mine)
Such a mess!!
What about just using a real language ?
This is a problem with how floating point numbers work regardless of language. No matter which language you use, you’ll need to be aware of how that particular language deals with this quirk. So stop gatekeeping you absolute dork