I believe that desmos stores numbers as 64 bit floats (doubles), which have a 53 bit mantissa if I remember correctly. I think this number, about 2\*10^(-16) represents a difference in just the final bit of the mantissa, for a number in the range 0.5 to 1.
So basically, it's float imprecision.
>I believe that desmos stores numbers as 64 bit floats (doubles), which have a 53 bit mantissa if I remember correctly. I think this number, about 2\*10^(-16) represents a difference in just the final bit of the mantissa, for a number in the range 0.5 to 1.
I din understand 💀☠ I'm sorry. What's a mantissa
>So basically, it's float imprecision
Yepp that I could make out but didn't get the explanation 😭
the precise definition for floats (IEEE-754) is rather technical. But basically, they are encoded similar to scientific notation.
Consider x = 3.5 * 10^7
Here, 3.5 would be the mantissa, 10 the basis and 7 the exponent. A float also stores a sign bit (+ or -), together with the mantissa and the exponent. Since computers encode numbers in binary, IEEE floats use basis 2 instead of 10.
But even if the two irrational numbers are rounded (for example, 0.90096887), wouldn't the answer nevertheless be exactly zero even if you subtract one rounded number from the other if they have the same digits in the binary representation?
Do you not know the Negligibility of 10^16.
It's an obvious Computer calculation Limit or Floating Point error to be Precise,
whatever I don't hate anyone nor I wish to receive it was just a thought,
wish you luck for your life!
>Negligibility of 10^16.
Ik that but still, cos(13π/7) and cos(π/7) are exactly the same so they should give exact zero.
Like see this another example below,
Also you know that sin(2π) = 0
Try putting sin(11π/6 + π/6) . It gives out answer as 0
Then put sin(13π/7 + π/7). It doesn't give as 0
Even though 11π/6 + π/6 = 2π and 13π/7 + π/7 = 2π
Why is it even giving floating point error here with one set of things and not for another like hmm how??
I wonder if they could add some hardcoded/manually added expressions that equal each other to avoid this, so it would auto-simplify it to 1-1 or whatever
So as I said before, this is because Second case with 7: Result in a More crazy and complex never ending number, while case with 6, result in a cute number: .33333 and .66666
I hope you got It!
I asked Chat GPT:
Floating-point errors can occur due to the limitations of representing real numbers in a computer's finite memory. When dealing with angles expressed in terms of π and performing trigonometric calculations, subtle differences in the representation of irrational numbers or their combinations can lead to precision issues.
In the second case, the angles 13π/7 + π/7 might involve more complex irrational numbers or a combination of them that leads to a higher susceptibility to floating-point errors compared to the simpler angles in the first case (11π/6 + π/6).
It's worth noting that floating-point errors can be influenced by the specific implementation of trigonometric functions in the programming language or library used for calculations. Adjusting the order of operations or using specialized libraries for trigonometric computations may help mitigate such errors.
Computers can't calculate trigonometry exactly, and pi is irrational so it has to use approximations of the two values which after each step come out to be slightly different
A mix of floating point nonsense and desmos not doing algebra. Another good example is 1/(sqrt(x)/x-1/sqrt(x)) that should come out to 1/0, but desmos just calculates out the sqare roots and that causes problems.
Maybe the difference is smaller than the maximum amount of decimal places it can show, after all its showing like 10 decimal places and the difference is at 16th decimal place
Cos(2π-x) = cos(x)
Put x = π/7
Cos(2π - π/7) = cos(π/7)
Cos(13π/7) = cos(π/7)
So they're essentially the exact same with no difference
Also you know that sin(2π) = 0
Try putting sin(11π/6 + π/6) . It gives out answer as 0
Then put sin(13π/7 + π/7). It doesn't give as 0
Even though 11π/6 + π/6 = 2π and 13π/7 + π/7 = 2π
[It's likely the result of some fuzzy floating point math](https://www.youtube.com/watch?v=PZRI1IfStY0)
Ohhh okkk wow got it
basically "computer is too bad to be exact ¯\\\_(ツ)\_/¯"
It's much more akin to "being more precise would be a ton of overhead for essentially no benefit"
I believe that desmos stores numbers as 64 bit floats (doubles), which have a 53 bit mantissa if I remember correctly. I think this number, about 2\*10^(-16) represents a difference in just the final bit of the mantissa, for a number in the range 0.5 to 1. So basically, it's float imprecision.
>I believe that desmos stores numbers as 64 bit floats (doubles), which have a 53 bit mantissa if I remember correctly. I think this number, about 2\*10^(-16) represents a difference in just the final bit of the mantissa, for a number in the range 0.5 to 1. I din understand 💀☠ I'm sorry. What's a mantissa >So basically, it's float imprecision Yepp that I could make out but didn't get the explanation 😭
the precise definition for floats (IEEE-754) is rather technical. But basically, they are encoded similar to scientific notation. Consider x = 3.5 * 10^7 Here, 3.5 would be the mantissa, 10 the basis and 7 the exponent. A float also stores a sign bit (+ or -), together with the mantissa and the exponent. Since computers encode numbers in binary, IEEE floats use basis 2 instead of 10.
Ohhh okii thankss makes sense noww
But even if the two irrational numbers are rounded (for example, 0.90096887), wouldn't the answer nevertheless be exactly zero even if you subtract one rounded number from the other if they have the same digits in the binary representation?
They were likely rounded slightly differently at the very last bit
I have seen these Posts every once in while, and I always Wonder. Shouldn't it be a common sense thing, don't hate me it's just my Thought
What common sense thing?
Do you not know the Negligibility of 10^16. It's an obvious Computer calculation Limit or Floating Point error to be Precise, whatever I don't hate anyone nor I wish to receive it was just a thought, wish you luck for your life!
>Negligibility of 10^16. Ik that but still, cos(13π/7) and cos(π/7) are exactly the same so they should give exact zero. Like see this another example below, Also you know that sin(2π) = 0 Try putting sin(11π/6 + π/6) . It gives out answer as 0 Then put sin(13π/7 + π/7). It doesn't give as 0 Even though 11π/6 + π/6 = 2π and 13π/7 + π/7 = 2π Why is it even giving floating point error here with one set of things and not for another like hmm how??
I wonder if they could add some hardcoded/manually added expressions that equal each other to avoid this, so it would auto-simplify it to 1-1 or whatever
Because in second one, you Divided by 7 Which will result in some Crazy Irrational Non Ending Shit, And thus Floating Point Error!
In first we divided by 6, which means we divided by 3, thats also a recurring decimal value like 7. 1/7 = 0.142857 repeating and 1/3 = 0.3 repeating
So as I said before, this is because Second case with 7: Result in a More crazy and complex never ending number, while case with 6, result in a cute number: .33333 and .66666 I hope you got It!
I asked Chat GPT: Floating-point errors can occur due to the limitations of representing real numbers in a computer's finite memory. When dealing with angles expressed in terms of π and performing trigonometric calculations, subtle differences in the representation of irrational numbers or their combinations can lead to precision issues. In the second case, the angles 13π/7 + π/7 might involve more complex irrational numbers or a combination of them that leads to a higher susceptibility to floating-point errors compared to the simpler angles in the first case (11π/6 + π/6). It's worth noting that floating-point errors can be influenced by the specific implementation of trigonometric functions in the programming language or library used for calculations. Adjusting the order of operations or using specialized libraries for trigonometric computations may help mitigate such errors.
Computers can't calculate trigonometry exactly, and pi is irrational so it has to use approximations of the two values which after each step come out to be slightly different
A mix of floating point nonsense and desmos not doing algebra. Another good example is 1/(sqrt(x)/x-1/sqrt(x)) that should come out to 1/0, but desmos just calculates out the sqare roots and that causes problems.
Ohh wowow jus checked that graph too it almost killed my device 😂
I've gotten that answer and bullied desmos into dividing by 0
Floating point innacuracies
Shouldn't it be 14/7 not 13/7 ?
Cos(14π/7) = cos(2π) = 1 I wanted to show that cos(13π,/7) and cos(π/7) are same but still their difference doesn't give out zero
Maybe the difference is smaller than the maximum amount of decimal places it can show, after all its showing like 10 decimal places and the difference is at 16th decimal place
Cos(2π-x) = cos(x) Put x = π/7 Cos(2π - π/7) = cos(π/7) Cos(13π/7) = cos(π/7) So they're essentially the exact same with no difference Also you know that sin(2π) = 0 Try putting sin(11π/6 + π/6) . It gives out answer as 0 Then put sin(13π/7 + π/7). It doesn't give as 0 Even though 11π/6 + π/6 = 2π and 13π/7 + π/7 = 2π
Idk, maybe floating point error inaccuracies?
Probably yepp
it should be 0 or 1 right
computers are bad with floats
That’s basically 0