Hacker News Reader

Comment by panda-giddiness | Hacker News Reader

As already mentioned by others, radians are not arbitrary units for angles; in fact, they are the "natural" "units", so to speak.

By definition, an angle is just the ratio of a circular arc (s) to its radius (r), θ = s/r (as an exercise, imagine how to apply this definition to the angle between two intersecting lines). When the length of the circular arc equals its radius (s = r), the angle subtended is exactly 1 radian; of course, since this is just a ratio, 1 radian is exactly the same as 1 numerically, which is why I put "unit" in quotes earlier -- a radian is not really a unit at all!

A degree, in contrast, equals pi / 180 radians. Of course, since 1 radian = 1, that really just means that 1 deg = pi / 180, similar to how 1%=0.01. Putting this all together, it is perfectly parsable (although not recommended) to say that a $5 burger costs roughly $29000% deg.

View on HN

The fact that it is natural doesn't make it performant and straightforward for all applications.

For example linear algebra is the natural and general way to handle vectors. However game developers still find quaternions faster and more performant.

>The fact that it is natural doesn't make it performant and straightforward for all applications.

How does changing the scale make anything more or less performant?

If anything, it makes things less performant since to use any hardware supported trig functions you now have to convert your weird angle representation into radians. For simple addition or fractions of your angle, it is just as performant as using angles in any scaling.

> For example linear algebra is the natural and general way to handle vectors. However game developers still find quaternions faster and more performant.

They only use quaternions for a few things, like slerp, and mostly because of gimbal lock.

For everything else they still use linear algebra, and linear algebra is used much, much more than quaternions for nearly any 3d program.

> How does changing the scale make anything more or less performant?

As the article shows, in application code we are multiplying by 2 pi, and the very first step in the optimized assembly is to divide by 2 pi. Therefore changing the scale to what both sides want saves 2 operations.

And why would the optimized version want that division? It is because the next step is to reduce down to a fixed range, then use a lookup table.

> They only use quaternions for a few things, like slerp, and mostly because of gimbal lock.

And yet they still do use them.

> For everything else they still use linear algebra, and linear algebra is used much, much more than quaternions for nearly any 3d program.

>As the article shows, in application code we are multiplying...

The article is wildly misleading.

I just checked out the godot code (git version c2f6664, today), and checked to see if what the author wrote and you believe actually happens in the code. It does not. Not even once. Didn't you find it odd that the author took two different codebases to make an argument between them instead of simply using one codebase?

Here is what I find:

First, avx_mathfun is not in Godot, nor is sin256_ps, nor is anything like it I can find. Feel free to find it and post where it is in godot.

The function sin is called 347 times in c, cpp, and h files. The function sinf is called 25 times. Of these, only 50 are scaled by tau in some direction. So right there it's terrible to optimize the other way.

And here is the kicker. Not a single one, zero, nada, called a function like the contrived sin func the author wrote about. Every single one called std::sin.

std::sin resolves on different architectures to (often) a hardware instruction or code like this from glibc (used on most x86 machines). Note this implementation, likely far more widely used than any other (since it's the code in GCC), does not use the method in the code the author posted.

For cos and cosf the result is the same (with a little changes in the counts since some audio filters use more sin or cos than the other): cos occurred 370 times, cosf occurred 41 times, only 52 of these involved tau (again the majority has no tau on the front side), and of all these, again zero get passed to anything other than hardware std::cos.

So this pretty clearly demonstrates for this codebase that changing scale as the author wants would make the code less, not more performant.

Didn't you wonder why the author searched on tau alone and didn't compare to the tau cases? Or why he then jumped to a sin/cos approximation not in the original code? And why he didn't mention how prevalent hardware sin/cos is?

So, do you now believe that changing scaling is going to make code perform worse, not better?

[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/iee...

Radians are a natural unit to measurements that are based on the radius. Radians are notably not natural to measurements that are based on the circumference, or to any equally divisible arcs of a circle.

A radian is 1turn/2pi.

It is not dimensionless.

A radian, or a turn, has a dimension: angle.

Saying 1radian=1 is just as senseless as saying 1m=1=$1.

It's true that abstract math often drops units because some things (like Taylor series) work nicely in certain units. That doesn't make the unit meaningless.

Street-Fighting Mathematics, thesis/book by Sanjoy Mahajan, shows what amazing things you can die in abstract math if you don't forget units.

It is de juro dimensionless, SI said so, and your government most likely made it official.

https://en.wikipedia.org/wiki/Radian#Dimensional_analysis

https://en.wikipedia.org/wiki/Radian#As_a_SI_unit

I am not sure that the current definitions are consistent or useful, but I myself don't know better.

Sorry, but this is incorrect. An angle is defined through the ratio of two objects with common units; it is dimensionless for the same reason that 5m / 5m is dimensionless. You could argue that radians should only refer specifically to angles, but your own example demonstrates how impracticable that would be: you can't sensibly Taylor expand a trigonometric function (eg, sin(x) ~ x) if the left-hand side and right-hand side have incompatible units.

why radius and not diameter?

It's a good question since "radius" seems somewhat arbitrary, but the reason for defaulting to radius is that the unit circle (radius 1) produces convenient numbers in general in a way that a circle of diameter 1 doesn't. However, that doesn't mean that it's the most parsimonious choice for your particular application.

Reply on news.ycombinator.com