Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turns are better than radians

computerenhance.com

Post reply on HN
Print view View original

481–490 of 494 posts

Re: Turns are better than radians

#481

Post by [deleted] »

justinpombrio wrote: post #368
jVinc wrote: post #357

Earlier quoted context omitted.

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…

[deleted]

Re: Turns are better than radians

#482

Post by munificent »

singularity2001 wrote: post #447
munificent wrote: post #340

Earlier quoted context omitted.

But what is the underlying representation in the wrapper class?

you can have an internal representation enum and when calling sin(Angle a){ switch a.representation: rad : sin(a.rad); turn: nsin(a.turn) } conversion only needed when adding angles of different representation.

Now your performance is even worse.

Re: Turns are better than radians

#483

Post by [deleted] »

areyousure wrote: post #454
justinpombrio wrote: post #368

Earlier quoted context omitted.

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…

Perhaps an even nicer equation: 1^x = ncos(x) + i nsin(x) using a multi-valued definition of the exponentiation on the left hand side.

[deleted]

Re: Turns are better than radians

#484

Post by Aardappel »

What is the radius of a circle that has a circumference of 1 (as proposed in TFA)? It is 0.5/PI == ~0.15915, which means you are just moving the "problem" elsewhere. I am sure there's a lot of math that is simpler with radius being 1.0 (with some input in radians) vs an input in "turns" and having to deal with a 0.15915 radius.

Yes, agree turns would be so much nicer for many use cases, but I'd like to see which operations it makes worse first :)

If indeed almost every hardware/library implementation of `sin` would lose a multiply by an arbitrary constant by choosing a new input scale, that would convince me too, as long as it was the same scale for all.

Re: Turns are better than radians

#485

Post by SideQuark »

btilly wrote: post #452
SideQuark wrote: post #420

Earlier quoted context omitted.

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

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

>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...

Re: Turns are better than radians

#486

Post by EmilioMartinez »

Aardappel wrote: post #484

What is the radius of a circle that has a circumference of 1 (as proposed in TFA)? It is 0.5/PI == ~0.15915, which means you are just moving the "problem" elsewhere. I am sure there's a lot of math that is simpler with radius being 1.0 (with some input in radians) vs an input in "turns" and having to deal with a 0.15915 radius. Yes, agree turns would be so much nicer for many use cases, but I'd like to see which oper…

But the proposal here would not change the circumference to 1, it's about representing angles in another currency. More often that not when you are doing trigonometry you care more about angles than arclength. The issue stems from thinking angles in terms of arc length.

Re: Turns are better than radians

#487

Post by EmilioMartinez »

bhk wrote: post #258

The author makes the point that turns allow for exact representation of many commonly used angles, but with binary floating point, many common angles (1/6 of a turn, for example) are inexact. This could be addressed by using a whole number other than 1 to represent a turn ... one that is a multiple of 3 (or 3x3) and 5, and while we're at it, 2 (or 2x2x2), so most commonly-used angles are whole numbers! That gives us…

>1/6 of a turn is inexact

I just want to point out that that is an issue with radians too (pi/3). Whenever this happens I just use that same integer representation (or rational as some poster said) and then remember to multiply by tau before using a math library. With a turns-based library it would only make my life (very slightly) easier

Re: Turns are better than radians

#488

Post by kragen »

rocqua wrote: post #474
kragen wrote: post #370

Earlier quoted context omitted.

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

I never saw rational trigonometry, but I imagine it is mathematically overkill in another sense. When calling `sin` or `cos` in code you get back a rational approximation to the presumably irrational answer. From what I quickly gleamed, using spreads would be really annoying to represent rotations, because you lose 'aditivity'. Two subsequent rotations with spreads a and b do not have spread `a` and spread `b`. Lots…

In order to reason about the quality of the rational approximation, you need to reason about the irrational number it's an approximation to, for example as a Dedekind cut. Wildberger, rightly or wrongly, doesn't trust reasoning about that sort of thing; he wants to ground everything in the rationals. Maybe he's worried about finding some equivalent of Russell's barber paradox in the irrationals.

Also, of course, irrational numbers don't allow you to extend trigonometric theorems to Galois fields, complex numbers, and so on, which to my mind is a much more interesting direction. I don't know how much you lose if you use Wildberger's construction into a division algebra like the quaternions.

I don't actually know how you compute the "angle sum" in terms of Wildberger's spreads, but I'm pretty confident that there's a way to compute it, and it's pretty simple.

In the unit-vector representation I described, angle-sum is not just simple addition, but it's really not that bad: (a + bi)(c + di) = (ac - bd) + (ad + bc)i. That's four real multiplications, an addition, and a subtraction, and the result is exact if computed in bignums or bignum rationals. This is usually cheaper than computing sine and cosine, especially if you can use SIMD or vectors, and of course if you want to rotate some points around a center, you end up having to multiply by the sin and cos in exactly the same way anyway. (Maybe in strength-reduced fashion if you're texture-mapping or something, but that applies just as well to representing the angles as sin and cos.)

Re: Turns are better than radians

#489

Post by Aardappel »

EmilioMartinez wrote: post #486
Aardappel wrote: post #484

What is the radius of a circle that has a circumference of 1 (as proposed in TFA)? It is 0.5/PI == ~0.15915, which means you are just moving the "problem" elsewhere. I am sure there's a lot of math that is simpler with radius being 1.0 (with some input in radians) vs an input in "turns" and having to deal with a 0.15915 radius. Yes, agree turns would be so much nicer for many use cases, but I'd like to see which oper…

But the proposal here would not change the circumference to 1, it's about representing angles in another currency. More often that not when you are doing trigonometry you care more about angles than arclength. The issue stems from thinking angles in terms of arc length.

The angle needing to be used as a length (to be able to use the same scale as a unit radius) is something that naturally happens in a lot of trig algorithms.

It depends whether you care more about the "UI" (the user of the algorithm gets a more pleasant input range to use) vs how convoluted the implementation is (somewhere deep down an extra multiply by 0.15915 was needed).

All I am saying that "turns" are not universally better, they have downsides too.

Re: Turns are better than radians

#490

Post by diedyesterday »

Pi and radians mostly and naturally enter math when we are dealing with both angles and radial distances (e.g. in spherical coordinates). If we choose to normalize in terms of "turns", then angles and circumferences may look natural but radial distances acquire Pi's everywhere.
Post reply on HN