Floating piont numbers come in two typical flavours. 32 bit, which has a range of 1e-36 to 1e36-ish, and 7/8-ish significant figures, and 64 bit, which has a range of 1e-306 to 1e306-ish and 15/16 significant figures. This means most numbers don't have a completely precise floating point representation, and that errors down at the 15th significant figure are extremely common. The epsilon function is part of the solution to this. - It returns the smallest possible error on a value, eg. abs(a-b)/eps(a) = an expression of the error as a multiple of the minimum possible error. This can then be compared to a suitable number.
This is why business languages provided a BCD representation that stored real numbers in the way that "business" expected them. Accounts really didn't care for the fuziness of real number. By definition a real number is one where between any two real numbers there is an infinite number of real numbers. Computers have never been good at infinity. So, this actually less a computer issue than a math issue. Computers just developed a convention for dealing with it.
Ran into the same issue few days ago, i was so upset because i couldnt find the bug in my code. After found the issue I used the round() function, that solved it for me. But this is also a very good idea. Thank you!
just a quick correction, please don't take this personal 8:40 actually the tolerance you implemented earlier is abs_tol not rel_tol. Relative tolerance is a percentage. The larger value will be divided by the smaller value. Your implementation calculated the absolute tolerance by subtracting and then calculating abs.
In science you don't need precision beyond 4 or 5 significant figures, so anything else is overkill....unless you are working in the ISO and you need an extremely precise value for updates on exact values...
Real numbers are infinite, floats aren't and are what we use to represent real numbers. This problem concerns all languages implementing floats. Designing algorithms that keep the error low is a big field of applied mathematics. Also you didn't implemented relative tolerence, you implemented absolute tolerence.
Wow this is a big Python flaw I didn't expect or know about. Is it happening only with the float type? It is like using a faulty calculator. I bet C or Java do not have this flaw
@@i_forgot1477 correct, I was also digging into it the other day, and it is a design constraint. It is left to the programmer to deal with this based on what he needs to achive.
It's not a language flaw. This is a limitation for the storage of floats, which has been around far longer than Python, and is acceptable. The only flaw is not understanding these limits and writing code that doesn't work within those limits.
No. Numbers are stored in binary. Imagine a number like 1/3 in decimal. That is 0.333333...... Well in binary, 0.1 has an infinite expansion. The cpu has a aritmetic logic unit (alu) to quickly add, subtact, multiply or divide any 2 numbers using a full adder logic gate, and full multiplier logic gate. (Those are compound logic gates). There are some classes such as Decimal in Python or BigDecimal that abstract this away for you and compute these more accurately, to take care of it, but the trade offs are that they take more memory, and are slower, as it have to compute 1 digit at a time, instead of just sending it all through the cpu's alu and calculating it all at once.
Or in other words, it is actually a lot more complicated to get a computer to do this in the simpler more expected way and a lot simpler to make it work in this more complicated unexpected way.
One way I have dealt with this is with the decimal library. I reccomend giving it a go if you've not come across it before.
What you implemented in the video was actually abs_tol and not rel_tol
Floating piont numbers come in two typical flavours. 32 bit, which has a range of 1e-36 to 1e36-ish, and 7/8-ish significant figures, and 64 bit, which has a range of 1e-306 to 1e306-ish and 15/16 significant figures. This means most numbers don't have a completely precise floating point representation, and that errors down at the 15th significant figure are extremely common.
The epsilon function is part of the solution to this. - It returns the smallest possible error on a value, eg. abs(a-b)/eps(a) = an expression of the error as a multiple of the minimum possible error. This can then be compared to a suitable number.
This is why business languages provided a BCD representation that stored real numbers in the way that "business" expected them. Accounts really didn't care for the fuziness of real number. By definition a real number is one where between any two real numbers there is an infinite number of real numbers. Computers have never been good at infinity. So, this actually less a computer issue than a math issue. Computers just developed a convention for dealing with it.
Python has a Decimal class.
Java has a BigDecimal class.
Ran into the same issue few days ago, i was so upset because i couldnt find the bug in my code. After found the issue I used the round() function, that solved it for me. But this is also a very good idea. Thank you!
round probably doesn't solve this for floating point numbers. Only if integer precision is enough
If you really want accuracy, you can use the Decimal classe from the decimal built-in module, with a string parameter for more accuracy.
just a quick correction, please don't take this personal
8:40 actually the tolerance you implemented earlier is abs_tol not rel_tol.
Relative tolerance is a percentage.
The larger value will be divided by the smaller value. Your implementation calculated the absolute tolerance by subtracting and then calculating abs.
In science you don't need precision beyond 4 or 5 significant figures, so anything else is overkill....unless you are working in the ISO and you need an extremely precise value for updates on exact values...
Thanks for posting this, I really need it for the project at hand to work
I learned that at school. I watched a few of your videos, then signed up. :)
Thank you for a great explanation!
You are awesome! I love your videos:)
I appreciate it mate!
Man, i'm addicted to Python so finding someone talks about it means i'm gonna subscribe right now
Excellent ❤
in fact we should make extend float class
Extend float class has numper and diver
thank you!
Real numbers are infinite, floats aren't and are what we use to represent real numbers.
This problem concerns all languages implementing floats.
Designing algorithms that keep the error low is a big field of applied mathematics.
Also you didn't implemented relative tolerence, you implemented absolute tolerence.
I don't even know this was an issue 😅
We need quantum computers...
Madoi se ti ho sentito arrabbiato dopo aver detto che la somma ti ritornava false 😂😂
Di la verità!
Sei Toscano anche te?
Ahahah, no ho solo vissuto a Milano per un po’, però sono cresciuto all’estero per la maggior parte de la mia vita :)
Wow this is a big Python flaw I didn't expect or know about. Is it happening only with the float type? It is like using a faulty calculator.
I bet C or Java do not have this flaw
I tried it with java, and guess what; java has the same flaw:)
output: 0.30000000000000004
im not sure if c has it too, though.
@@EpicNoobx must be a specific design for float and the "mantissa" due to precision left to the programmer
All languages conforming to the IEEE 754 standard for floats, which is the vast majority of languages, will have this problem
@@i_forgot1477 correct, I was also digging into it the other day, and it is a design constraint. It is left to the programmer to deal with this based on what he needs to achive.
It's not a language flaw. This is a limitation for the storage of floats, which has been around far longer than Python, and is acceptable. The only flaw is not understanding these limits and writing code that doesn't work within those limits.
.... overcomplicating stuff for the sake of it...
No. Numbers are stored in binary. Imagine a number like 1/3 in decimal. That is 0.333333...... Well in binary, 0.1 has an infinite expansion. The cpu has a aritmetic logic unit (alu) to quickly add, subtact, multiply or divide any 2 numbers using a full adder logic gate, and full multiplier logic gate. (Those are compound logic gates).
There are some classes such as Decimal in Python or BigDecimal that abstract this away for you and compute these more accurately, to take care of it, but the trade offs are that they take more memory, and are slower, as it have to compute 1 digit at a time, instead of just sending it all through the cpu's alu and calculating it all at once.
Or in other words, it is actually a lot more complicated to get a computer to do this in the simpler more expected way and a lot simpler to make it work in this more complicated unexpected way.
Commenting negatively on a video you don't even understand.
@@Gruuvin1 Maybe 1 or both of my previous replies helped them to understand better.
I Cee.....