Hacker News Reader

Comment by kazinator | Hacker News Reader

The math is definitely not fine with turns, because your Euler formula e^ix = cos x + i sin x no longer holds. We can use a base other than e, namely B = e^2pi which around 535.4916. This doesn't have the nice e properties like d/dx e^x = e^x.

The elegant fact that the base of the natural logarithm, which produces an exponential function that is its own derivative, also shows up as the basis for the above Euler's formula, shows that radians are special: like what binary is to computers.

The natural logarithm being its own derivative is in fact directly linked to the derivative a radians-based sin(x) being cos(x) and so on. Make it any other unit, and you have a mess of conversion factors worse than 2pi.

Imagine complex chained derivatives, double and triple derivative, chain and product rules, all stuffed with trig functions and generating gratuitous piles of cascaded conversion constrants because radians were not used.

View on HN

The author's not talking about doing math, but about porting math into code. Counting turns is the same as counting cycles. People do that all the time. It works fine.

And this math is kind of a mess. exp(x) is its own derivative but the log is not. (d/dx)log(x) = 1/x

But, agreed, if you're going to do calculus, use radians.

> The author's not talking about doing math, but about porting math into code.

If your code doesn't look like the math it's "ported" from, the odds of it being bad code go up like 100x

I tried to make my code exactly match the math it came from, but I didn’t have enough memory to store sqrt(2)

If you look at the implementation of sqrt for a computer, it's usually implemented with Newton's algorithm, which is an iterative numerical method with high speed convergence. It is computationally efficient and looks approximately zero how √ looks.

Right. I was hoping to highlight that difference with a joke.

Sometimes a person will tell a story which is untrue, with the purpose of bringing levity to a conversation. This may be termed a joke. These stories may also be used to illustrate a point.

It's important to note that such cases are not always clearly signaled as being humor or untrue. It is a part of the joke's effect that the reader or listener will not at first know it is a joke, but will realize it after noticing an absurdity.

A related concept is "dry humor".

It is important that they not be clearly signaled.

What? "sqrt(2)" is literally 7 bytes. :)

I’ve been writing code for 46 years. Not once have I had to code a derivative.

And for all the people who are concerned about how sin' 2πx = 2π cos 2πx, in actual code, it doesn’t matter. Let’s say that I’m writing a basic graphing function and I want to be able to display the slope of the sin curve at any point.

I am not going to expose the turn-based units to the user. Caring about slopes implies that I’m doing calculus and thus assuming radians. So even though my internal values are [0,1], I will label them as [0, 2π] (and the actual numeric values on the display may actually be something like [50,450] which is yet another numeric value we don’t display). So to get the slope at π/4, I’ll calculate cos_t 0.125 and display that value.

We do all kinds of unit translations in computing without worrying about it. This is just another case of that which observes that numerically speaking, using turns is better aligned with the underlying numerical algorithm for calculating trig values.

> I’ve been writing code for 46 years. Not once have I had to code a derivative.

Haha !

I have been coding for much shorter time but having done some ML on orientations and on spheres in my time, I have had to take their derivatives all the time.

It will be interesting to consider folks who do machine learning on robot trajectories or analysing dynamics of robotic arms.

> Caring about slopes implies that I’m doing calculus

You could be using the results of calculus, which became frazzled with gratuitous constants because of poor angle units before anyone wrote any code.

You want to keep all the math in radians until you code the calculations; then figure out how to optimize it with turns where possible.

> I’ve been writing code for 46 years. Not once have I had to code a derivative.

It sounds like discussions about "porting from math" do not pertain to you then?

The derivative of log x being 1/x is "clean", free of arbitrary constants. If we change away from e being the base, we lose that.

The derivative of log_b x is 1/(x ln b), where ln b is 1 if b is e.

The computational aspect of it is totally compelling. The library routines are already using turns internally, so it is wasteful to go from/to radians when the caller doesn't require it, and many callers can be rewritten not to. Plus the part argument about common angles like multiples of the right angle having to be irrational numbers under radians is also compelling.

Assume people have read the article and understood it.

I can only imagine what a ridiculous problem it would be to try to re-do, for example, the Vincenty formula for distance between two latitude/longitude points on an oblate spheroid (the earth) if it couldn't use radians.

https://en.wikipedia.org/wiki/Vincenty%27s_formulae

https://www.johndcook.com/blog/2018/11/24/spheroid-distance/

Further, inverse vincenty is pretty much an essential in anything that needs to find the azimuth between two points on a map. Such as for microwave radio link planning purposes.

Karney (2013) is also radian dependent.

https://github.com/pbrod/karney

I absolutely love how full Wikipedia is of completely useless pages like the Vincenty's Formulae one, where someone has just gone "look this is what it says in my maths textbook" without any explanation.

No discussion of why you'd use this over for example the Haversine function, of course, just a straight out copypasta and a demonstration of how clever someone is at the mathematical notation markup.

Incidentally you'd use this instead of Haversine if you wanted to be really really accurate down to millimetres across a long baseline, as opposed to lots and lots of "it's ten miles that way in a straight line" very quickly and simply.

It would sure be better if it had some concrete explanations and examples why vincenty is preferred. It's also barely any more computational load on modern computers so very little reason not to use it.

Haversine is strongly deprecated in even short distance applications like planning a 35 km point to point licensed band radio microwave link, because you risk having both slightly the wrong distance and the azimuth figure being off by a tenth of a degree.

Vincenty in python form is quite compact. Karney by comparison is something like 1000 lines of code. And the difference is going between like a few mm precision to nanometers.

I've actually implemented Haversine in a SQL query to find what can be summed up as "which of these moving things is closest to this thing right now". It's not the tidiest, and I had to ask someone better at SQL than I am to make it entirely work, but it looks like it is easier than doing Vincenty.

I should try it, right?

Edit: I also wonder what's to be gained by being accurate to nanometres over the surface of a fairly inaccurate planet.

My application was to locate movable things to identify which was nearest to a moorland wildfire, where you need to be accurate to within about 1km at best - you don't need to drop the pin right on it, you'll know where you're going when you see it ;-)

For that application you needn't have bothered. On a sphere arc-length and Euclidean distance are monotonically related, so the minimizer would not have changed.

Writing full articles takes time and effort. But the effort is cumulative, so these stub articles are really just the start. Some of the comment you made here would definitely improve the article. You are always welcome to edit and improve Wikipedia. I mean this literally and sincerely, it is one of the few places on the internet where you might benefit from posting.

it is quite telling that wikipedia has pages upon pages documenting pokemon, but relatively limited context about maths or science, beyond what's in textbooks.

Telling what? STEM academics are busier than Pokémon fans to contribute to Wikipedia? Or they care less about the cause of Wikipedia? That as a society we produce more of the latter than the former? There’s no definitive rationale to be told simply by that observation.

It's not a "stub article" though, it's just a paragraph and then a bunch of stuff plagiarised from a maths textbook.

I already edit quite a bit on Wikipedia. I stay away from the maths bits, because it's a little outside my area of expertise - and because it's just things like "it's a function to calculate distance, and here's ten pages of algebra with no explanation" I can't really improve that on Wikipedia.

You might enjoy the much longer and more detailed article https://en.wikipedia.org/wiki/Geodesics_on_an_ellipsoid which discusses the context.

I've read that, quite some time ago, which is how I understand how the Haversine function works. Kind of. A bit. Enough to make it work, anyway.

Latitude and Longitude? By definition it’s not starting in radians. After that, pi is involved but that doesn’t mean you have to use radians, unless you define “anything that uses pi is radians”. The discussion TFA started was about programming computers optimally. If you want the code to be readable by humans with a math background, or Wikipedia background, sure, use the algorithms as written down. TFA was not targeting that audience. It was targeting folks who care about two pointless multiplies in their (checks notes) game engine.

The radians provide absolute no help for your problem.

There are alternative trigonometric functions with the argument measured in cycles that can be used instead of those with argument measured in radians. All formulae written with sin, cos and atan can be rewritten with sin2pi, cos2pi and atan2pi, or whatever names you want for those functions.

Moreover, before the electronic computers, nobody in the entire history of mankind had used trigonometric functions with arguments measured in radians for any practical problem, like astronomical or geodesy problems.

The radians became popular in the 19th century, only for symbolic computations, because they simplify the formulae for derivatives and primitives.

For all numeric computations, even in the 19th century, nobody used trigonometric functions with arguments measured in radians, but only trigonometric functions with arguments measured in sexagesimal degrees, which behave much more similarly to the functions with arguments measured in cycles, than to the functions with arguments measured in radians, which cannot be computed exactly for any rational argument, and where the argument can never be reduced exactly to a value in the first quadrant.

While the trigonometric functions with arguments in radians are harmful, the constant 2Pi remains an essential constant, which must be used to convert between the length and the central angle that correspond to a circular arc, and also to compute the derivatives and primitives of the exponential 1^x and of the trigonometric functions.

Some anecdotes to support and color your point.

The sin function has Indian and Greek roots. Part of that history is in the name 'sin' itself. I will let you all look that up. It's quite a funny story especially the jya to jayb bit.

This comment is about computation of sin in Indian mathematics and its definition.

The analogue of the sin function in Indian mathematics was a function from length to length. It was defined as the length of the half chord that corresponds to the angle, not of a unit radius circle but of a circle of radius 3438 units.

But why 3438 ?

That requires understanding the Indian system of measuring angles by length.

They wanted to have a numeric precision of 1 arc minute but weren't very fond of manipulating fractions. So they incorporated their requirement in how they standardized their circle -- Not by radius or diameter but by arc length. They chose that circle to be the standard for which the arc length of one arc minute is unit length.

If one does the math, it is 360 * 60 / 2π. Plugin the accuracy of π that was known to Indian mathematicians of that time you get a radius of 3438 units.

If you are curious about their numeric calculation of sin look up Aryabhatta and Bhaskara. Wikipedia is quite informative.

https://en.wikipedia.org/wiki/%C4%80ryabha%E1%B9%ADa's_sine_...

https://en.wikipedia.org/wiki/Bh%C4%81skara_I%27s_sine_appro...

> The radians became popular in the 19th century

Something akin to radians was widely used in ancient India. That is, sine tables constructed for a circle with circumference 360·60 (angular minutes) and radius 3438 ≈ 360·60/2π.

In Europe, radians per se developed in the early 18th century. What is true is that the name radian came about in the late 19th century.

> trigonometric functions with arguments in radians are harmful

Trigonometric functions are not inherently "harmful", but they are sometimes cumbersome. Changing the units doesn't make all that much practical difference.

Avoiding transcendental functions in favor of vector methods is often a good strategy though, especially in code.

For graphics rendering Euler equation doesnt matter. Colours are 0.0-1.0 and have no relation to reality, but it works. Same with rotations (if we’re not using Quaternikns)

> For graphics rendering Euler equation doesnt matter.

Huh?? "Euler angles" are one of the most popular representations in computer graphics! The only other good alternative is quaternions, where as you say this also matters!

Yes, but do you really need to scale all your values to make the rotation amount fit into a sin() call, only to have to scale them back again when you're done?

I think what they're getting at is "why are we scaling everything so one full turn is sin(6.28ish) when we can just say sin(1)?"

You could easily try it out by defining a function that replaces sin(), cos(), and tan() with their "turn" equivalents, and seeing how you get on.

Euler angles have nothing to do with e^ix = cos x + i sin x. They are a completely different concept.

Yes and no. The x in e^ix is to SO(2) what Euler angles are to SO(3).

This really only says that the connection between Euler's formula and Euler angles is that they're both angles. I would agree with that.

One represents rotation in 2D space, the other in 3D. So I think it's a bit more than that.

I am very familiar :) using euler angles involves using trig functions, which is what this thread is about

Also with radians the differential equation x''''(t)=x(t) has {exp(t), exp(-t), sin(t), cos(t)} as the (real) canonical base for its solution space. And x''(t)=-x(t) gets {sin(t), cos(t)} where they even result from the simplest possible (non-trivial) initial conditions (x(0)=0,x'(0)=1 and x(0)=1,x'(0)=0).

If you look at all the simplest differential equations you can think of, the sin(t)/cos(t) functions in radians are almost inevitable independent from their geometric usage.

Why not e^{2 pi i x} = cos x + i sin x then? We already handle e^{2 pi/360 i x} = cos x + i sin x for x in degrees just fine. It's not that euler no longer holds, it's that you just have to be clear about what units[0] you use when comparing the explicitly angular/geometric cos and sin with the numeric exponential, and then deciding on a default numeric cos and sin/a default "unit" for angles.

If we want to get real interesting with it, this could also motivate an explicitly geometric "unit" aware exp operation, and depending on the defaults we use for the angular scale and the linear scale, 2 pi could be the conversion factor, making exp(2 pi i x) = cos x + i sin x actually interesting and useful and clarifying.

[0] pedantically, they're not units, or at least not dimensional units, so whatever the word for dimensionless units are, as in degrees vs radians vs turns.

The problem is that angles in the complex plane are related to multiplication, which is related to exponentiation.

When you multiply two complex numbers z1 and z2, their angles add: Arg(z1 z2) = Arg(z1) + Arg(z2).

That carries into exponentiation: Arg(z^2) = 2 Arg(z). The exponent 2 has an interpretation as doubling the angle.

In other words, e^2πix has an interpretation as working with angles.

When you have that 2π in there, but not in the sin and cos expressions, you're using different angles for multiplication/exponentiation and for sin/cos.

Your left side shows that you are sticking with Arg(z) being in radians!

But on your right side, you have turns: the expression cos x + i sin x is literally saying that the point whose angle is x on the unit circle in the complex plane is the complex number <cos x, sin x>.

But your left side essentially says that the Arg of this point: Arg(cos x + i sin x) is not x, but 2πx!

When we have a point on a unit circle whose Arg is x, then if we raise e to the power of ix, we get that point. That's what the original left hand says, without the pi.

You have a "trigonometric angle" and "Arg" that are separate, right in a fundamental equation.

If we add types or a geometric abstract manifold or something, the issue is that we do want cos and sin to take numbers with a scale (e.g. cos(90 degrees) vs cos pi/2 rads), but we generally don't give the same thing to e or exponentiation (no e^i(pi/2 radians) vs e^i(90 degrees).

> But on your right side, you have turns: the expression cos x + i sin x is literally saying that the point whose angle is x on the unit circle in the complex plane is the complex number <cos x, sin x>.

I totally agree here, and that's purely geometric, regardless of what we express x in. We can talk in terms of abstract points without specific coordinates/embeddings in R.

> When you have that 2π in there, but not in the sin and cos expressions, you're using different angles for multiplication/exponentiation and for sin/cos.

This part I'm not following. When we talk about a scale, any purely universal identity like Arg(z^2) = 2 Arg(z) is going to hold regardless of the scale. I agree that the Arg stuff nicely motivates interpreting it as an angle, but don't see how it says anything at all about the scale in question. Like, we get an interpretation of e^2πix as working in angles from the Arg reasoning, but we don't get a scale for those angles from it, do we? We'd only get Arg if we impose a scale on Arg itself, right?

So if we take e^2πix at x=1/2 turn=1/2, we get e^πi=-1, which gets us Arg(-1)=1/2 turn=pi rads=180 degrees, and we can work from there, but I still don't see how it imposes a unique scale that we can say is still radians and thus incompatible with the RHS's scale of turns.

The author didn't argue that you should never use radians, or tau. Just that for some use cases there is an alternative that is simpler using turns. Your argument can be true and his proposal can also be true, it just depends what your use case looks like.

That formula as such has no importance at all, it is just a correspondence between different notations.

What you really mean is that there are certain mathematical problems where the complex exponential function is useful and for the complex exponential it is more convenient to measure the real part in nepers and the imaginary part in radians (in order to have a simple formula for computing its derivative and its primitive).

However, the problems where the complex exponential is truly useful are at least an order of magnitude less numerous than it appears from the manner in which mathematics is taught in schools, following a tradition from the 19th century, when symbolic computations done with pen and paper were more important than numeric computations.

For the vast majority of practical problems, the complex exponential is not useful at all (i.e. using it introduces unnecessary complications, without providing any advantage), but a pair of other exponential functions is much more useful, because they ensure computations that are both faster and more accurate: the binary exponential 2^x, with real argument and value, and the exponential 1^x, with argument measured in cycles and a value that is a complex number of unit norm (unit modulus).

Using the pair of exponentials from above, removes computations that are slow and inaccurate (for the reduction of the arguments) from each function evaluation, by moving them to the computation of derivatives or primitives, which are operations that happen much more seldom and which also can frequently be done at compile time, instead of at run time.

Any algorithm that is described by using complex exponentials can be rewritten to use only 2^x and 1^x, and this normally allows various simplifications in the numeric computations. Even the formulae for Fourier transforms are simpler.

The author of the TFA is perfectly right and the use of nepers and radians is a very bad habit, which is a handicap with which most people remain after being taught mathematics in schools, with antiquated methods.

While in TFA the author uses the term "turn" for the unit of plane angle, the traditional name, which was used until some time after WWII, was "cycle", from which various other unit names where derived, e.g. "cycles per meter" or "cycles per second".

It’s good to know you don’t want your house powered by AC power anymore. It’s a weird take, but you do you.

As I have already said, and I am an electronics engineer, the design of any electrical or electronic system, including anything that uses AC power, can be done faster and with less numerical errors, if instead of using complex exponentials one uses 2 other exponential functions: "2^x" and "1^x", with arguments and value domains as I have written above.

Unfortunately, this requires the use of a custom library of transcedental functions, because the standard libraries of most programming languages provide only the functions with arguments in nepers and radians.

The standard C library has attempted to add the missing functions, but for a completely impossible to understand reason the standard has defined wrongly the trigonometric functions, requiring arguments measured in half cycles, instead of cycles.

This is an extraordinarily stupid mistake, but at least if a standard C library implementation has all the functions, it is easy to modify the sources of the trigonometric functions with arguments in half cycles, to take arguments in cycles instead.

A similar thought (about 1^x) had occurred to me, but I wasn't aware that it was common practice (in some field, at least).

Do you have a reference?

1^x = 1 for any complex x. So that library can be very simple and fast!

Wrong.

1^x is multi-valued, and like with all other multi-valued complex functions it is possible to select a branch of the function that is a proper function.

Defined correctly, the value of 1^x for any rational x is the corresponding smallest root of unity, and for irrational arguments it is defined by continuity.

Therefore 1^x rotates on the unit circle for increasing x.

The standard complex exponential and complex logarithm functions are defined exactly in the same way, because they are also multi-valued, so the same kind of equalities like yours would also be true for them.

With the correct definition, 1^x = 1 only for integer x, not for any x. As I have written above, the useful 1^x is defined only for real arguments, not for complex arguments. Only its values are complex numbers of unit modulus.

>The standard complex exponential and complex logarithm functions are defined exactly in the same way, because they are also multi-valued, so the same kind of equalities like yours would also be true for them.

Example values of e^z and 1^z:

e^2 ~= 7.389

1^2 = 1

e^(i\pi) =-1

1^(i\pi) = 1

e^-7 ~= 0.000912

1^(-7) = 1

e^(1+i) ~= 1.46869394 + 2.28735529 i

1^(1+i) = 1

In another comment, I asked why people chose to use the symbol τ over just writing turn or "rev(olution)" (defined to be the constant ≈ 6.28318530718) given how unambiguous the latter is as a name for 2π. And why not just write sinrev() or sinturn(), and leave the symbols sin() and rev (defined to be ≈ 6.28318530718) alone?

The naming is irrelevant here. The point is that sin(x) ~ x for small x, whereas sinrev(x) ~ rev * x for small x, which is much uglier. And similar things happen to the derivative of sinrev() vs regular sin() and so on. So switching to preferring to express angles in revs instead actually complicates most formulas, at least in some domans.

I think it's Tau[0].

[0] https://en.wikipedia.org/wiki/Tau_(mathematics)

You either (i) don't know the Greek alphabet, or (ii) can't read people's short posts. I literally mentioned tau and why it might be a silly name (it clashes with other mathematical uses of the symbol tau).

First sentence of the Wikipedia link:

> The number τ (spelled as tau)

Your short post in full:

> In another comment, I asked why people chose to use the symbol τ over just writing turn or "rev(olution)" (defined to be the constant ≈ 6.28318530718) given how unambiguous the latter is as a name for 2π. And why not just write sinrev() or sinturn(), and leave the symbols sin() and rev (defined to be ≈ 6.28318530718) alone?

You were asking why they used the symbol τ rather than the words "rev" or "turn". You didn't give a clue that you knew any of the rest, including what the symbol meant.

> The natural logarithm being its own derivative

the derivative of ln(x) is 1/x

> the derivative a radians-based sin(x) being cos(x) and so on. Make it any other unit, and you have a mess of conversion factors worse than 2pi.

the derivative (with respect to x) of sin(x) is cos(x), regardless of units for x. Otherwise the chain rule wouldn't work

> the derivative (with respect to x) of sin(x) is cos(x), regardless of units for x.

Not if you use "turn"-trigonometric functions, as the author suggests.

turn-sin `t sin(x) = sin(2pi * x)` has `d/dx tsin(x) = 2pi * tcos(x)`.

such a weird thread because everyone seems to know what they are talking about but definitely seem to miss something.

but basically one would be differentiating to 2pi x rather than x. and things will work out

Your argument is correct and I'm sure you're really smart and all that.

However,

Proportion of code where radians are used to represent rotation in 2D (i.e. turns): 99.9999%

Proportion of code where radians are used to perform higher degree derivatives, symbolic computation, etc: 00.0001%

That is true, but only due to a historical accident, which has been preserved by the inertia of the mathematical education system.

The use of the trigonometric functions with arguments in radians, which are unfortunately standard in most programming languages, wastes time and introduces unnecessary rounding errors at each function evaluation.

The functions with arguments in cycles perform exact argument reduction instead of approximate argument reduction, and which is also faster (omitting a multiplication with an approximate value).

Thanks for agreeing with me, GPT.

It doesn't really change Euler's formula. It just adds a factor for x to it (or an additional term to hide inside sin and cos as functions). That's less convenient, not less true.

However, I don't really see a benefit gained out of doing this to keep your theta between -1 and 1 instead of between -2pi and 2pi. Like it's not a difficult thing to estimate or convert in your head to get a close enough estimation.

Reply on news.ycombinator.com