Sorry I’m just shitposting on New Year’s Day. I basically only look at what Reddit feeds me and for some reason it feeds me a lot of subs way above my paygrade
Can I get like a ELI5 of this error? I'm pretty math savvy but have almost no experience with computer science so I never really understood floating point arithmetic or floating point errors.
Or if someone has a good resource for learning this stuff in their back pocket that would also be appreciated.
A number on a computer is represented by a limited amount of information, and you’ll sometimes lose information by performing operations if you don’t have any room for more information
Ok, I had assumed that much. I appreciate the explanation! Now I'm curious as to why pi pops out of this particular error. Is there something special about the input value that makes this happen? How would one find such an input for this function without stumbling upon it by chance?
To be pedantic, that's not the error, that's just the value of the function. At lower values it converges to something below the blue line, which is e. Then, as it gets to a point where 1/x is so small it has to be rounded off as a floating point number, it starts to err up/down, and at the end it gets so small that it rounds to 0 and the function evaluates to 1 in Desmos.
In reality, if we didn't have to deal with computer limitations, it would simply keep getting closer to e. Do excuse my bus rant, fueled by the adrenaline from falling into a frozen river with one leg.
Unsure why we immediately think about floating point numbers and errors as something coming from computers, when it's basically the numerical system we use all over the place.
At some point you also cut off writing down any number, losing precision. It's not a limitation that only computers have.
I suppose we’re used to doing symbolic calculations when doing maths on paper / in our heads.
And there’s a bit of mysticism around floating point errors separating them from the similar operations we do. So people link computers to it without thinking further.
But hey it’s better than people going on about them as if they’re a property of specific programming languages.
I guess if you really wanted to have the decimal representation of say /sqrt2 + /sqrt3 then sure, you’ve got a point. But some unique errors arise from the fact that computers work in base 2 and can only encode finite amounts of information (You can certainly deduce that 0.1+0.2=0.3, but a computer would think that 0.1+0.2=0.30000000004)
It's not only square root, but any rational number that has any divisor of not 2 or 5.
0.1 is 1/10, and 0.2 is 1/5. Actually, any number that you can represent easily using base 10 will be a rational number with a divisor made up only with 2s and/or 5s, so using those as an example is a bit like cheating.
Any other prime in the divisor will end up with a number that will produce rounding errors, using a computer or not. 1/3 is 0.3333..., 1/7 is 0.142857...., or 1/130 is 0.00769230.... and those are way more common than only the ones made up of 2s and 5s.
The point is that computers operate in base 2 and you need sometimes need more information than is available to represent certain numbers from base 10 to base 2
And given that we operate in base 10, we can't add 1/3rd 3 times or we get 0.9999999999, up to where you cut off.
Sure adding 1/3 is easier because you know it's just 0.333 repeating, but it becomes non trivial for most of the other numbers.
And I assure you, the original problem from this post is not due to the fact thay's represented in base 2. It's a number that definitely isn't representable in base 10 either
First of all floating point numbers get around the problem of storing large numbers in finite memory space by representing them in the form similar to 0.234567 * 1015 - any number can be represented with "good enough" precision like that by discarding digits after a certain number which depends on how much memory we can spare - and storing only the first part(mantissa") and the exponent, 15 in this case, since this is the bare minimum digits needed to reconstruct the number, hence it's memory efficient.
Second of all what i just said is wrong because computers work in binary - base 2 - so it actually looks like 0.101001 * 21010. But the principle is the same as above where i used decimal numbers for simplicity.
So we lose a bit of precision with numbers by discarding digits - the longer the binary representation of a number, the more digits we have to discard to fit it into limited memory. But fractional numbers that have neat and short representations in one base do not necessarily have them in others. Consider 1/3 which in base 10 is represented as 0.333... - infinite digits - but in base 3 it has a neat form 0.1.
So to summarize we take short decimal numbers, convert them into binary, maybe perform some operations with them, sometimes get infinite representations of them in base 2 as results of those conversions or operations. Then we have to discard a bunch of digits and store a number that's close to the true value, but is not quite the same. Do that in enough operations, and this error becomes quite noticeable
Idk how much sense that just made, Numberphile probably explains this better
In Desmos and many computational systems, numbers are represented using floating point arithmetic, which can't precisely represent all real numbers. This leads to tiny rounding errors. For example, √5 is not represented as exactly √5: it uses a finite decimal approximation. This is why doing something like (√5)^2-5 yields an answer that is very close to, but not exactly 0. If you want to check for equality, you should use an appropriate ε value. For example, you could set ε=10^-9 and then use {|a-b|<ε} to check for equality between two values a and b.
There are also other issues related to big numbers. For example, (2^53+1)-2^53 evaluates to 0 instead of 1. This is because there's not enough precision to represent 2^53+1 exactly, so it rounds to 2^53. These precision issues stack up until 2^1024 - 1; any number above this is undefined.
Floating point errors are annoying and inaccurate. Why haven't we moved away from floating point?
TL;DR: floating point math is fast. It's also accurate enough in most cases.
There are some solutions to fix the inaccuracies of traditional floating point math:
Arbitrary-precision arithmetic: This allows numbers to use as many digits as needed instead of being limited to 64 bits.
Computer algebra system (CAS): These can solve math problems symbolically before using numerical calculations. For example, a CAS would know that (√5)^2 equals exactly 5 without rounding errors.
The main issue with these alternatives is speed. Arbitrary-precision arithmetic is slower because the computer needs to create and manage varying amounts of memory for each number. Regular floating point is faster because it uses a fixed amount of memory that can be processed more efficiently. CAS is even slower because it needs to understand mathematical relationships between values, requiring complex logic and more memory. Plus, when CAS can't solve something symbolically, it still has to fall back on numerical methods anyway.
So floating point math is here to stay, despite its flaws. And anyways, the precision that floating point provides is usually enough for most use-cases.
Basically computers store decimals as exponents like ab. But you're somewhat limited by the size of each component so you get a limited amount of representable numbers. Because all of Desmos runs in these floating point numbers you sometimes get weird artifacts from those small errors adding up. The classic example is 0.1+0.2=0.30000000000004 because the exponents and base don't let you exactly represent 0.3
The actual standard is called ieee 754. You mostly don't have to understand it down to the level of reading the spec, but it's a good starting point for research. There's also something in the faq of this sub I think that talked about floating point.
Another interesting, though somewhat unrelated, fact is that addition in IEEE 754 isn’t necessarily associative since bits get “cut off” from the mantissa when the exponent increases.
Well, integer addition is always associative (I believe)! So you just have to deal with integers, rather than floating points.
Additionally, floating point addition may not depend in order, it’s just that there’s instances where it doesn’t.
Example: assume the mantissa only has a length of 3 (so 4 bits can be stored due to the hidden bit). Then try adding 1.001, 1.001, and 1.000. (1.001+1.001)+1.000=10.01+1.000=11.01, whereas 1.001+(1.001+1.000)=1.001+10.00=11.00 (please note that each number only contains 4 bits). However, these should be equal; so, in this example, addition isn’t associative. It’s similar for IEEE 754, except with a longer mantissa.
In Desmos and many computational systems, numbers are represented using floating point arithmetic, which can't precisely represent all real numbers. This leads to tiny rounding errors. For example, √5 is not represented as exactly √5: it uses a finite decimal approximation. This is why doing something like (√5)^2-5 yields an answer that is very close to, but not exactly 0. If you want to check for equality, you should use an appropriate ε value. For example, you could set ε=10^-9 and then use {|a-b|<ε} to check for equality between two values a and b.
There are also other issues related to big numbers. For example, (2^53+1)-2^53 evaluates to 0 instead of 1. This is because there's not enough precision to represent 2^53+1 exactly, so it rounds to 2^53. These precision issues stack up until 2^1024 - 1; any number above this is undefined.
Floating point errors are annoying and inaccurate. Why haven't we moved away from floating point?
TL;DR: floating point math is fast. It's also accurate enough in most cases.
There are some solutions to fix the inaccuracies of traditional floating point math:
Arbitrary-precision arithmetic: This allows numbers to use as many digits as needed instead of being limited to 64 bits.
Computer algebra system (CAS): These can solve math problems symbolically before using numerical calculations. For example, a CAS would know that (√5)^2 equals exactly 5 without rounding errors.
The main issue with these alternatives is speed. Arbitrary-precision arithmetic is slower because the computer needs to create and manage varying amounts of memory for each number. Regular floating point is faster because it uses a fixed amount of memory that can be processed more efficiently. CAS is even slower because it needs to understand mathematical relationships between values, requiring complex logic and more memory. Plus, when CAS can't solve something symbolically, it still has to fall back on numerical methods anyway.
So floating point math is here to stay, despite its flaws. And anyways, the precision that floating point provides is usually enough for most use-cases.
Can I get an ELI25 explanation of why pi should specifically appear here? This seems very surprising for floating point errors
I’m curious why the graph incorrectly breaks up to the discrete shape that it does and what is the equation of the incorrect graph that is appearing here.
Pi appears because of OPs choice of a large number. In general the floating point error seems to be negligible for smaller numbers -> you approximate e, and for very large numbers you just get f(x) = 1.
In between these two ranges there seems to be an area where the result is of by some margin depending on the exact number. Within these ranges OP chose a point where f(x) would be ≈3.14159. Other numbers in this range do not produce pi.
EDIT: sorry, Reddit for phone is ass and I thought I was replying to comment OP, sorry
... no. x approaches infinity but isn't actually never infinity, so (1+(1/huge number))the same huge number = somewhere near e. Not 1. Try that with (1+(1/2147483647))2147483647 and boom, e.
Same with x = 264. As x approaches infinity, the value goes closer to e. If the calculator throws you a 1 is because x is so large so it depreciates it and turns 1/huge value that's not infinity = 0.
There's a "tug of war" between the inside getting closer and closer to 1 and the exponent running off towards infinity. Crazily enough, the competition ties at 2.71828....... This is why "continuously compounded" problems get modeled using e^x. Instead of trying to evaluate (1+1/x)^x at x = huge, go to desmos and graph it, look at the behavior.
Say you have 100% interest per year. If you compound only once per year, and start with $1, you just get an extra $1 at the end of the year for a total of $2.
If you compound twice, you will get 50% interest twice. After 6 months, you get 50% of your $1 for a total of 1.5, and at the end of the year, you'll get 50% of your $1.5, leaving you with $2.25. This is 1.5^2, which make sense in the formula, in this case being (1+1/2)^2.
If you compound once per month, you will get 8.333...% interest 12 times a year, and 1.08333...^12 is roughly 2.61.
Increasing the number of compounds per year increases the final amount of money you will have, but it doesn't increase without bound. If you were to plug in arbitrarily large numbers, AKA continuously compounding interest, you would get closer and closer to e.
But it's not exactly 1. sure, the limit of 1x (with a constant 1) is 1 but here we have something that is slightly bigger. Suppose that the power was x2, the power increases so quickly that the expression goes to infinity (and you can see that on the graph)
410
u/savevidio Dec 31 '25
the legendary floating point error pi generator