Thought about radians VS degrees

[evg-zhabotinsky]

I suppose it is no more than my (and maybe someone else's) thought.

Documentation explicitly says that you try to use degrees everywhere, and that any radians are bugs.

However, radians are widely used in physics, mathematics and even to compute trigonometric functions in hardware. Why so? Because they are natural measure of angles! (I don't mean human perception there.)

---

Let's take a look at angular velocity. What is it? Angle the body rotates in unit time. So it should be measured in degrees/second, right? Maybe. And maybe not.

Let's take some random point on the body. We know angular velocity. How to compute linear velocity of that point? Let R be its distance from rotation axis, and W will be angular velocity. In T seconds, body rotates W * T degrees. It is W * T / 360's part of full circle. Circle length is 2 * Pi * R. So, in T seconds, this point will pass distance of W * T / 360 * 2 * Pi * R. Divide it by T to get linear velocity: V = W * T / 360 * 2 * Pi * R / T = R * (W / 180 * Pi).

Oops! We've just converted degrees to radians!

Let now W be measured in radians/s (or 1/s, since radians are (arc length) / (arc radius), that is, meter / meter, or 1 -- unitless quantity, and, unlike degrees, with no extra multiplier).

Now we get just V = R * W. It looks better, IMHO.

---

Another example: torque.

In what units torque is usually measured? In what units KSP measures it? Well, *Newton meter* is good enough. Or kiloNewton * meter in case of KSP (usually written kNm).

Why? Well, you apply force F orthogonally to the end of lever of length R. You produce torque of F * R. Force is measured in Newtons, length is measured in meters, so that's it!

Should kOS use these units? Well, no. At least documentation says so. Problem is, torque is really (kind of) "angular force". And, if we treat it as cause of angular acceleration, it's units should be Newton meter radian! So, according to documentation, kOS should use Newton meter degree!

So, what about that lever mentioned above? Well, now applied torque will be F * R * 180 / Pi. Does it make sense? Not at all!!! At least to me.

---

Let's come from another side. What's so good about degrees for kOS to use them?

Well...

More people know what degree is than what radian is. Enough? Surely! But... Suppose someone does not know what radians are. If (s)he just downloads or copies someone else's code and uses it, radians or degrees will not make any difference. If (s)he is really ready to write his/her own autopilot (even not really complex, maybe like pre-1.0 "gravity turn" plus simple orbital maneuvers), will radians stop him/her? I bet no. There are much more things to learn so radians will not really be a problem.

Maybe any technical reasons to use degrees? Well...

Most of interesting angles are expressed with well known whole number of degrees. It might be a bit more convenient to write 45 than Pi / 4. And even more convenient than constant():pi / 4, as it is now in kOS. But really! Adding functions radians(degrees) and degrees(radians) should really be enough! And these functions should also solve the "what the hell radians are?" problem.

And if anyone has anything to say about precision:

---

Disclaimer I have written this just for discussion.

And anyway, it's all just about extra semi-meaningless coefficients in formulas. CGS measure system is more convenient than SI in this sense and that's the sole reason for its popularuty. It's not too problematic to add degrees <-> radians conversion everywhere. But if degrees will only be used for input / output, it will have to be done less often, and that will also improve precision, because hardware uses radians anyway.

For example, if angular velocity is measured in radians/s, you can get point's linear velocity (as vector) as a cross product of angular velocity (as vector) and vector from any point on axis to that point. But when angular velocity is measured in degrees/s, you have to multiply angular velocity vector by Pi / 180 before performing the above computation, to convert from degrees to radians. Not only it's inconvenient, but you, in fact, convert radians (as KSP returns them) to degrees (as per kOS principle) and then back to radians, and thus loose some precision due to rounding.

Backward compatibility is yet another problem with moving to radians, and even on its own is enough to prevent that transition.

Suggestion (really low priority, I think): Add standard conversion functions: radians(degrees) and degrees(radians). Allow to @USEDEGREES OFF. (like @LAZYGLOBALS OFF.) to make all standard functions and variables use radians, on per-program basis. Functions should be really easy, but @USEDEGREES OFF. might be really painful.

[abenkovskii]

1. Some functions from KSP API return degrees while other return radians.
2. I don't like the idea of adding @USEDEGREES OFF. because a function defined in one script can be imported (using run) to the other script.
3. Degrees are more beginner friendly.
4. Kerboscript has functions now. If someone wants to use radians he can write his own radians(degrees) and degrees(radians).
5. kOS uses double everywhere so we aren't loosing that much precision.

[evg-zhabotinsky]

Well then, It's all just about extra semi-meaningless coefficients in formulas. Using degrees instead of radians almost always introduces them, with radians there usually are none. SI also introduces a lot of these extra coefficients, compared to CGS, but many think that SI is the way to go anyway.

About beginner friendly... These things were always easy for me, so I really might overestimate average level of kOS beginners a lot. So I can't say anything on that.

[hvacengi]

If your goal is the more elegant mathematical solution, you can always use vector math to calculate the same values. (torque being the vector cross product of position and force vectors for example). But using that example of torque, the equation I have always been taught is t = F * r * sin(theta). In the case of a perpendicular force (as you used) you would not multiply by a radian conversion factor as a the result of the sin function is the same regardless of which units are used to calculate it. That's probably the biggest reason I don't think it's a real big deal to use degrees. Most of the time, you don't actually multiply by a raw angle (with a few notable exceptions like angular momentum). I have a library of scripts which launches a ship, circularizes, transfers to an intercept orbit, matches inclination, and docks with a space station. In all of that, I only ran into the issue of radian conversion factors once. But I do rely heavily on vectors.

As for the reasons that support the choice of degrees: degrees are generally more recognized. At the very least its a little easier for most people to debug a script when you look at the degree values and compare it to the map as opposed to trying to visualize the decimal values that go with fractions of pi. And the strongest support is consistency with KSP's own user interface (when they display angles, they show them in degrees).

I agree with @abenkovskii, I think that adding a user flag to toggle between degrees and radians would severely limit the ability to share scripts and code with other users and know that it will work the same way. Since this has been a major focus in some of our other feature discussions, I think you pick a single method and you stay as consistent as possible.

But it's always healthy to have these kinds of conversations. Some times "because it's how we've always done it" is a legitimate reason, but it should never be taken for granted.

[evg-zhabotinsky]

Note: * sin(theta) accounts for the fact that only orthogonal component counts for torque. And in general case, in 3D, you just use cross product instead.

The thing is, in case of immobile lever, there is seemingly no angle involved at all! But if you start rotating that lever, then torque is momentum of inertia multiplied by angular acceleration! (Much like F = ma) And from here angular units come.

Fact is, angles are really unitless, same way as ratios are. When you just divide meters by meters, you can't really say if you get angle, ratio or just number. Without considering actual meaning of your calculations, that is.

You can even say that degree symbol is a constant equal to Pi / 180, same way as % is equal to 0.01. And you will be correct if you say that sphere volume is 240°·R³ or that this comment consists of 400% paragraphs. How meaningful is that is another question. Radians are better in this sense because they are equal to 1.

[abenkovskii]

angles are really unitless

Yes they are. But still there are more reasons not to change it. In fact even if we were designing a new API I would vote for degrees because as @hvacengi said in a KSP autopilot degrees simplify more things than they complicate.

[ondono]

Just wanted to add something, while KOS has precision enough, the issue is, do YOU have it?

if I were to print angles, I'd rather do it in degrees, rad are only easy to get around if pi gets explicitly introduced:

PI/2, PI/3, PI/4,.. that's fast to get but, try to guess what angle is 1.34rad of the top of your head, and see what precision you have, because my (fast) guess is between 60-90º, so about 30º precision. But I bet you can draw a pretty close to 76º angle just by hand.

[evg-zhabotinsky]

Yes, I agree about human perception of degrees and radians, but IMHO it is better to use degrees only for user interaction (both printing and reading) and for nothing else.

As I said in the beginning, even backward compatibility alone is more than sufficient reason not to change anything in this case. So I don't really insist on moving kOS to radians.