Live data from Hacker News

Turns are Better than Radians (2022)

computerenhance.com

151–160 of 225 posts

Re: Turns are Better than Radians (2022)

#151
post #145

Let's do a full circle. It all began with replacing frequent occurrence of 2π in calls of sin and cos functions with τ. This post suggests an optimisation by getting rid of τ by getting rid of radians. That way one can get rid of frequent and adjacent radians to degrees conversions and back. I say, let's get rid of sin and cos itself ! Of course I am being over the top here. However, if you represent angle not as a s…

HN has clumsy filtering, but you're allowed to write π and τ.

Re: Turns are Better than Radians (2022)

#152
post #149
post #146

Having read over this entire conversation I feel that people are almost uniformly missing the practical impact of this, which is simply that you can write your own math in terms of "turns" as much as you like. Nothing stops you right now. Defining a sinT function that takes turns is trivial. And so on for all the functions. I haven't done much graphics programming, but what I did I did with tau rather than pi. You al…

One would reap the most benefit if libraries were compiled late for the compiler to optimize away adjacent conversions and back. With C++ template libraries one can do that but compile times can become a hell.

[deleted]

Re: Turns are Better than Radians (2022)

#153
post #142

Earlier quoted context omitted.

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.

Re: Turns are Better than Radians (2022)

#154
post #151
post #145

Let's do a full circle. It all began with replacing frequent occurrence of 2π in calls of sin and cos functions with τ. This post suggests an optimisation by getting rid of τ by getting rid of radians. That way one can get rid of frequent and adjacent radians to degrees conversions and back. I say, let's get rid of sin and cos itself ! Of course I am being over the top here. However, if you represent angle not as a s…

HN has clumsy filtering, but you're allowed to write π and τ.

Thanks for the push. I was being lazy on my mobile phone.

Note to readers who maybe confused by the parent comment. I was using \pi and \tau.

I just noticed now that my default mobile keyboard has π.

Re: Turns are Better than Radians (2022)

#155
post #52

Earlier quoted context omitted.

> all angles are without a unit. Dimensionless, sure, but what do you mean here? Radians and degrees are units, are they not?

In a very awkward way: rad is m/m, which is 1...

That’s the awkward argument for being dimensionless. But we know we have units of angle because we have scale factors to convert between them.

Re: Turns are Better than Radians (2022)

#156
I mean, it's just shifting the value conversion in the other direction, isn't it?

Pi is a naturally-emerging concept: it's the ratio of a circle's circumference to its diameter. It just so happens that a lot of useful stuff we do in math operate on that ratio, not on either on the individual values (at least, not those alone).

Re: Turns are Better than Radians (2022)

#157
The nice thing about turns is that they can be represented by an unsigned integer. For example with an 8 bit unsigned integer:

- 0000_0000 = 0 or tau

- 1000_0000 = pi

- 1100_0000 = 3*pi/4

And the addition and multiplication by integer scalars all apply and the overflows work naturally. I wrote a little library in rust [0] to help with this as you can define the operations */+-% etc.

[0] https://docs.rs/turns/latest/turns/

Re: Turns are Better than Radians (2022)

#158
post #82

Earlier quoted context omitted.

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?

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)

Re: Turns are Better than Radians (2022)

#159

The nice thing about turns is that they can be represented by an unsigned integer. For example with an 8 bit unsigned integer: - 0000_0000 = 0 or tau - 1000_0000 = pi - 1100_0000 = 3*pi/4 And the addition and multiplication by integer scalars all apply and the overflows work naturally. I wrote a little library in rust [0] to help with this as you can define the operations */+-% etc. [0] https://docs.rs/turns/latest/t…

Ooh! that overflow is so clever. I would have been proud to have thought of that. Perfect fit for modular arithmetic.

Re: Turns are Better than Radians (2022)

#160
My gut instinct was that operations like sin, cos, tan, etc, were the kind that would get aggressively inlined by any modern compiler, and then after inlining the redundant conversions between radian/turns would be canceled out by optimization passes.

Of course, gut instinct can be wrong, so I checked in godbolt and was surprised to find out that even if I try to force lto, it still doesn't get inlined and remains a call.

Post reply on HN