Live data from Hacker News

Turns are better than radians

computerenhance.com

361–370 of 494 posts

Re: Turns are better than radians

#361

Earlier quoted context omitted.

>> The writer don’t seem to realise that radian is not an arbitrary unit but a dimensionless one which is defined so that 1rad is actually just 1. It's been a while, but I used to have an argument that rad should be a unit. This even plays well in physics where it allows torque to not have the same units as a joule.

I don't see how radians come into the discussion of torque and energy, both of which are N*m in SI. That discussion has to do with the failure of SI to notate the directions of vectors. When it's torque, the N and the m are at a right angle. When it's work, they are both in the same direction.

>> That discussion has to do with the failure of SI to notate the directions of vectors.

Well if radian is a unit then torque become Nm/r and is no longer Nm like energy. Then when multiplied by an angle in radians you get energy. It was *something like that*.

Re: Turns are better than radians

#362

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 exact…

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.

Re: Turns are better than radians

#363
post #353

Earlier quoted context omitted.

Ouch. Less than 1 degree of accuracy? Well, I guess if it’s good enough for Asteroid, it’s good enough for me

Pico8 is 128x18 res, so I think the maximum number of visibly unique lines you could draw from one point is 512. You can't even express sub-one-degree (sub-1.422222 really) rotations on Pico8 visually without subsampling etc.

Interesting. I couldn't imagine asteroids without at least 1 degree accuracy feeling right, but I just fired up a pico8 emulation of asteroids and it had what seemed like about 24 steps of rotation, and played beautifully. Funny how my memory gave it way higher resolution.

https://sazazel.itch.io/pico-8-asteroids

Re: Turns are better than radians

#364

Earlier quoted context omitted.

Ouch. Less than 1 degree of accuracy? Well, I guess if it’s good enough for Asteroid, it’s good enough for me

You can always do one cycle of newton-raphson to get nearly double the accuracy with only one extra lookup-multiply-add.

Great, now I'm banging my brain against newton-raphson trying to understand it

Re: Turns are better than radians

#365
>which means the calling code is multiplying by a factor of pi just so the library code can immediately divide it back out again.

Mathematical philosophy aside, that's a pretty compelling argument from a practical perspective. You're doing two unnecessary relatively expensive (multiply/divide) operations in a process that's supposed to be fast.

Re: Turns are better than radians

#366

> which means the calling code is multiplying by a factor of pi just so the library code can immediately divide it back out again. Mathematical philosophy aside, that's a pretty compelling argument from a practical perspective. You're doing two unnecessary relatively expensive (multiply/divide) operations in a process that's supposed to be fast.

In practice how likely is it the compiler will optimize away the redundant operations? Is the library boundary typically a barrier to optimization?

Re: Turns are better than radians

#367

> which means the calling code is multiplying by a factor of pi just so the library code can immediately divide it back out again. Mathematical philosophy aside, that's a pretty compelling argument from a practical perspective. You're doing two unnecessary relatively expensive (multiply/divide) operations in a process that's supposed to be fast.

In practice how likely is it the compiler will optimize away the redundant operations? Is the library boundary typically a barrier to optimization?

If the compiler isn't compiling the library too, I would assume yes.

Re: Turns are better than radians

#368
post #357

> But math never decreed that sine and cosine have to take radian arguments! That is not entirely true. It comes from the relationship between those functions and the complex numbers via the Euler formula. ix e = cos x + i sin x There may be arithmetic/numerical inconveniences, but that's not all there is to "math". Let's define ncos and nsin ("nice cos, nice sin") as follows: nsin x = sin 2πx ncos x = cos 2πx So the…

I see where you're coming from, if the formulas end up having weird numbers like 535.4916 or numbers like 2.718 or 6.28318 then obviously there's something suspicious about the equation. But small correction though. You got the number wrong, it's actually much more weird than any of those mentioned. The actual equation you come to for ncos an nsin is: (-1)^(2x) = ncos(x) + i nsin(x) And yes, -1 is a very weird number…

This is a very good point, but it took me a minute to get what you were saying beneath the snark. Translating without the snark:

There's a famous equation relating sin and cos to complex exponentiation. It also helps explain the Taylor expansions of sin and cos, which is one way to compute them and to find properties about them. It's a very important equation. It is:

     ix
    e    = cos x   +   i sin x
kazinator's point was that this equation relies on cos and sin taking radians as arguments. If they take turns instead, then you need to insert messy extra constants to state this equation!

jVinc's counter-point, made with lots of snark, is that there's an equation that's even nicer if you just instead measure angles in turns with ncos and nsin:

    (-1)^(2x) = ncos(x) + i nsin(x)
It's similar, but doesn't require the magic constant e.

A proof sketch that these are equivalent:

    (-1)^(2x) = e^ln((-1)^(2x)) = -e^(2x) = e^(i * (2 pi x)) using e^(pi i) = -1

Re: Turns are better than radians

#369

Earlier quoted context omitted.

While it is a fake unit, it was made to make the math easy. You could call the origin of everything the place where I'm standing - but good luck calculating a path for the mars rovers to travel if I happen to walk to the bathroom.

I drive a mars rover and this cracked me up. Understanding reference frames is indeed a big part of the job. We do have to deal with "site frame updates" based on rover observations of the sun -- important but annoying. I will bring your person-centered frame suggestion to the team :-)

Speaking of reference frames, I deal with quite a few for Earth-bound things, and the primary ones we use are ECEF (Earth-Centered, Earth-Fixed) and ECI (Earth-Centered, Inertial), which then we will often move to a relative local frame for whatever object matters.

Is the equivalent set available for Martian Nav (MCMF/MCI, I guess), or do you have different/specialized/etc. frames based on something unique to Mars.

Re: Turns are better than radians

#370
post #359

> But math never decreed that sine and cosine have to take radian arguments! That is not entirely true. It comes from the relationship between those functions and the complex numbers via the Euler formula. ix e = cos x + i sin x There may be arithmetic/numerical inconveniences, but that's not all there is to "math". Let's define ncos and nsin ("nice cos, nice sin") as follows: nsin x = sin 2πx ncos x = cos 2πx So the…

This makes a lot of sense when you are expecting to take derivatives, integrals, or use complex numbers. In cases outside of that, radians lose their advantage over turns.

If you're not using derivatives, integrals, or complex numbers, maybe you'd be better off using Wildberger's "rational trigonometry" with quadrances and spreads instead of angles? I haven't actually tried it myself. Wildberger's motivation is a sort of ultra-strict Platonism* mixed with the desire to extend analytic geometry to fields other than the real numbers, though, so it wouldn't be surprising if it wasn't actually a simpler way to write Asteroids. Doing trigonometry in Galois fields sounds super cool though and I hope I understand it one day.

Alternatively you can just directly represent angles as unit vectors in the desired direction, which is pretty much the same as using complex numbers. Angle addition is complex multiplication, angle bisection is complex square root, and computing the sine and cosine is simplicity itself. (This takes twice as much space. If you choose to store only the real part of the complex number, you can only represent angles up to half a turn, same as in Wildberger's approach, you lose some precision near the limits, and the other operations require some extra computations.) I have tried this, for example in http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra... and https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/sdf.lu..., and in the cases I've tried it, it works great.

I'm interested to hear other people's experiences on this count!

______

* His main concern is that irrational numbers don't, in some sense, really exist, so they're a bad basis for trigonometry. As I understand it, not only is Platonism now a minority among foundations-of-mathematics types, but even Platonists generally believe that irrational numbers are just as real as rational ones, so as I understand it, Wildberger's viewpoint is held by quite a small minority. That doesn't, of course, imply anything about whether it's correct.

Post reply on HN