Why Do Rotating Labels in Desmos Behave Weirdly with Large Numbers?

[CallMeDirac]

TL;DR

When you go into the setting of a label in desmos it does weird things

In desmos you can rotate a label by going into the settings. BUT the rotations get weird with large numbers:

if you rotate by 360 nothing happens same for 3600 and 360000 but when you get to 360000000000000000 it starts changing from just being flat.
It changes from a 0 degree tilt to a 332 or -28 degree angle

then again at every consecutive multiple after that seemingly at random angles.

is this some glitch with the code or a computing issue with how large it is. Or is there some mathematical answer.

 

[Mark44]

if you rotate by 360 nothing happens same for 3600 and 360000 but when you get to 360000000000000000 it starts changing from just being flat.

Rotation by 360 degrees rotates the label through one complete revolution, and rotation by 3600 degrees does 10 revolutions.
With the larger number you wrote, what happens depends on how the code was written. If the rotation angle in degrees is stored as a 32-bit unsigned integer, the maximum value is 4,294,967,295, which is way smaller than the number you wrote (360 quadrillion or $3.6 \times 10^{17}$). Most likely the people who wrote the code for Desmos thought that no one would need to rotate a label by more than 4,294,967,295 degrees. It's also likely that you would get similar weird behavior for numbers half the size of the one I wrote, if they wanted to account for rotations by a negative number of degrees.

is this some glitch with the code or a computing issue with how large it is. Or is there some mathematical answer.

My guess is that it's due to how they're storing the number of degrees for a rotation. If this number is stored as an integer (no fractional part), no one would really need a value outside the interval [-359, 359].

 

[CallMeDirac]

With the larger number you wrote, what happens depends on how the code was written. If the rotation angle in degrees is stored as a 32-bit unsigned integer, the maximum value is 4,294,967,295, which is way smaller than the number you wrote (360 quadrillion or 3.6×1017). Most likely the people who wrote the code for Desmos thought that no one would need to rotate a label by more than 4,294,967,295 degrees. It's also likely that you would get similar weird behavior for numbers half the size of the one I wrote, if they wanted to account for rotations by a negative number of degrees.

That explains the reason but why only at 360 quadrillion did that start, and could you explain the odd rotating.

 

[pbuk]

Deleted.

 

[Mark44]

That explains the reason but why only at 360 quadrillion did that start

Well, you didn't say what you did, only that you had tried 360, 360, and 360,000. Did you try any other values before trying 360,000,000,000,000,000? If not, your testing is pretty haphazard.

and could you explain the odd rotating.

If you enter a much larger number than the program can handle, it is likely to take as much of the number as it can manage. I don't have Desmos, so I can't tell you any more than I already have. Even if I had it, I wouldn't have the source code, which is what you would need to answer your question, although if their documentation is any good, they might list a range of possible values for rotation angles.

 

[Baluncore]

is this some glitch with the code or a computing issue with how large it is. Or is there some mathematical answer.

If the angle was stored as double precision floating point, (16 digits), then rotation will involve dy/dx = Sin/Cos, and the trigonometric functions in radians. The first thing done to evaluate the trig functions is to remove multiples of 2π. For angles with more than about 13 digits, that will cause round-off errors greater than 1 degree. I believe that is what you are seeing, based on your 18 digit example of 360000000000000000.

 

[Baluncore]

Here is an example of why when using trigonometry you should restrict angles to a sensible range.
Just why for i = 19 or 20, we get a Sin() with a value outside ± 1, I do not know.

Dim As Double deg45 = Atn( 1 ), twoPi = 8 * Atn( 1 ), a = TwoPi
Print "   i           a = TwoPi * 10^i           Sin( a + 45° )"
For i As Longint = 0 To 20
    Print i, a, Sin( a + deg45 )
    a *= 10
Next i

'   i           a = TwoPi * 10^i             Sin( a + 45° )
' 0             6.283185307179586           0.7071067811865474
' 1             62.83185307179586           0.7071067811865439
' 2             628.3185307179587           0.7071067811865283
' 3             6283.185307179587           0.7071067811864730
' 4             62831.85307179586           0.7071067811849544
' 5             628318.5307179587           0.7071067811993528
' 6             6283185.307179587           0.7071067818372442
' 7             62831853.07179587           0.7071067816307133
' 8             628318530.7179587           0.7071067835166711
' 9             6283185307.179586           0.7071069604269089
' 10            62831853071.79587           0.7071105839806455
' 11            628318530717.9587           0.7071737904378344
' 12            6283185307179.588           0.7079348793018947
' 13            62831853071795.88           0.7168635687142767
' 14            628318530717958.8           0.7528018283658082
' 15            6283185307179588            0.5798217159482524
' 16            6.283185307179588e+016      0.4592362609773827
' 17            6.283185307179588e+017     -0.9390292761920875
' 18            6.283185307179588e+018      0.946492465042508
' 19            6.283185307179588e+019      6.283185307179588e+019
' 20            6.283185307179588e+020      6.283185307179588e+020

 

[pbuk]

Here is an example of why when using trigonometry you should restrict angles to a sensible range.
Just why for i = 19 or 20, we get a Sin() with a value outside ± 1, I do not know.

That's not very good - I guess this is Visual Basic? I would expect a language to implement trig. and other functions so that they never return a value outside the range of the function. JavaScript for instance doesn't have this problem (at least not on my browser - see https://codepen.io/pbuk/pen/KKNzNqY to run it on yours).

 

[Baluncore]

It was written in FreeBASIC, which is VB compatible. FB translates to C, then uses the C trig functions. I agree it is not a good implementation.
For small angles, the sine of the angle can be approximated by the angle. But for very large angles, Modulo TwoPi cannot be done without massive errors.
But here, for arguments greater than 9.223372036854775d18 the double precision Sin() function returns the angle.
Hopefully the silly result will be trapped somewhere.
But why only at 10^18 cycles of 2π when all angular resolution has been long lost?

Here is the transition.

Print Sin( 9.223372036854775d+018 ) ' = 0.9873418913143515
Print Sin( 9.223372036854776d+018 ) ' = 9.223372036854776e+018

Print Cos( 9.223372036854775d+018 ) ' = -0.1586063985336008
Print Cos( 9.223372036854776d+018 ) ' = 9.223372036854776e+018

Print Tan( 9.223372036854775d+018 ) ' = -6.22510756465593
Print Tan( 9.223372036854776d+018 ) ' = -1.#IND

 

[CallMeDirac]

For angles with more than about 13 digits

I retried it with radians and at 2π(10^13) it rotated. So you're right about the 16 points.

 

[pbuk]

It was written in FreeBASIC, which is VB compatible. FB translates to C, then uses the C trig functions. I agree it is not a good implementation.

I don't see the same problem in C either - at least not in what I believe is 64 bit clang-7: see this repl.it.

> clang-7 -pthread -lm -o main main.c
> ./main
The sine of 9223372036854774784.000000 is 0.989156 degrees
The sine of 9223372036854775808.000000 is 0.999930 degrees
>

Possibly there is some issue within FreeBASIC converting between its 64bit double and whatever implementation of C it is using? It doesn't really matter:
1. Such large angles should have been rejected by a validation stage.
2. Surely no one would use FreeBASIC for any serious computations?

 

[Baluncore]

2. Surely no one would use FreeBASIC for any serious computations?

Surely no one would compute the Double Sin() of an angle so far beyond reason.

I believe I have shown that the OP observed behaviour was due to double precision roundoff.

The Sin(angle argument >= 9.223372036854776d+018) bug is off-topic here.
I will report and trace it elsewhere.

 

[robphy]

Clearly, it's not really a desmos [-only] problem.

It's a javascript problem involving precision... but it's not an unreasonable numerical error.

https://www.desmos.com/calculator/a13hqtgmpy

Here's google for sin(360000000000000000 degrees)
https://www.google.com/search?q=sin(360000000000000000+degrees)
giving -0.45904974201Of course, WolframAlpha is doing something fancier
https://www.wolframalpha.com/input/?i=sin(360000000000000000+degrees)

 

[Baluncore]

The Sin( large arguments ) problem is due to Intel code (FSIN in the CPU). Intel specify that the source operand must be given in radians and must be within the range -2^63 to +2^63.
Note that the transition I determined was identical;
2^63 = 9.223372036854776e+018

http://www.softeng.rl.ac.uk/st/arch...Projects/instructions/instruct32_hh/vc115.htm

https://software.intel.com/content/...ntel-64-and-ia-32-architectures-software.html

 

[pbuk]

Clearly, it's not really a desmos [-only] problem.

It's a javascript problem

I don't think it is either of those, it is a user problem. JavaScript is operating according to its documented behavior: integer literals greater than Number.MAX_SAFE_INTEGER are converted to IEEE754 64 bit floats.