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

Turns are Better than Radians (2022)

computerenhance.com

Post reply on HN
Print view View original

31–40 of 225 posts

Re: Turns are Better than Radians (2022)

#31

Post by jcranmer »

Analemma_ wrote: post #22
WCSTombs wrote: post #16

I think I cautiously agree with this notion to some extent, but IMHO the real answer is that it's application-dependent, and if you're writing a low-level trig library and you have to pick one or the other, it really isn't clear to me that turns should win over radians. I expect many systems that use trigonometry would sometimes use small-angle approximations either for efficiency or to bootstrap to the general case.…

I don't have a super-wide gamut of experience here and numerical analysis isn't my specialty, but nearly all trig implementations I've looked into (in both software and hardware) make heavy use of lookup tables and other shortcuts. I've never seen a Taylor series used in a general implementation - not saying it doesn't exist anywhere, but in most cases that I'm familiar with you could support turns just as easily wit…

If you're being technical, it's usually not a Taylor series, it's a minimax series. (The difference is that Taylor series minimize error at a given value, whereas minimax is trying to minimize maximum error in a range).

In most general math library implementations (e.g., the library in glibc, musl, etc.), the implementation of sin, as with most functions, is going to be a polynomial evaluation. See, e.g., https://github.com/kraj/musl/blob/kraj/master/src/math/__cos... for the implementation in musl, or https://github.com/bminor/glibc/blob/master/sysdeps/ieee754/... for glibc's implementation.

Of course, if you're not using a standard math library implementation, you're probably preferring speed over accuracy, and so you might use a lookup table and linear interpolation to get a very coarse approximation instead.

Re: Turns are Better than Radians (2022)

#32

Post by jameshart »

chabska wrote: post #4

The problem is that trigonometric functions are used in many more fields beyond geometry. The input is not always an angle around a point in euclidean space, it could be phase angle of a periodic signal. You can make an alternative set of trig functions that take turns, but you will anger a lot of people if you mess with the vanilla trig functions.

When dealing with waves you often are dealing with turns - or, as they’re called in that world, cycles. A cycle is a turn is tau is 2pi.

The SI unit for frequency after all is Hertz - cycles per second - which should really be considered equal to 2pi s^-1, but for complicated reasons, often isn’t, and most formulae that involve frequency ignore the ‘cycle’ - or it’s also hiding inside the definition of something like the wavelength or the Planck constant where it cancels out.

Meanwhile the SI unit for angular velocity is radians per second which is dimensionally equivalent to s^-1.

That said a becquerel, which measures rate of discrete events, is also dimensionally s^-1. (Next time you are measuring traffic to your website consider using the appropriate SI unit for measuring requests per second: the Becquerel.) - so dimensional equivalence isn’t the same as equivalence. You wouldn’t add a rate to a frequency, same as you probably shouldn’t add a torque to an amount of energy.

Re: Turns are Better than Radians (2022)

#33

Post by HWR_14 »

groundzeros2015 wrote: post #27
HWR_14 wrote: post #21

Earlier quoted context omitted.

There are valid reasons to prefer radians, especially in calculus. The fact that it's related to arc length is something that never (directly) comes up.

Every part of calculus with trig functions relies on this fact! The rate of motion along a circle is approximately linear at the same speed when described in radians. For example when you do a Taylor series expansion the cos/sin are well approximated by x.

That's why I put "directly" in my original post. All the nice functions in calculus rely on that fact, but that fact itself is almost never used or useful by itself .

If I were writing the article I would focus on the benefits for derivatives and integration and other things that are slipping my mind at the moment. I wouldn't waste time going down the rabbit hole of why.

At least not for an article aimed at this type of audience.

Re: Turns are Better than Radians (2022)

#34

Post by nomel »

eru wrote: post #30
nomel wrote: post #18

Earlier quoted context omitted.

It's a mistake to care about equality of floating point numbers [1]. You must usually consider the lower bits of the number as random. I assume you're saying something other than this though? [1] https://en.wikipedia.org/wiki/Machine_epsilon

Huh, what? Floating point numbers have a standard, you know. They aren't non-deterministic YOLO numbers. By default, the compiler has to stick to what the standard requires, and can't just say add arbitrary imprecision. Your epsilon is what you get when you try to analyse floating point numbers as approximations of real numbers. But they also have an independent life as bit patterns, and the compiler can't just willy…

Please look at the link where context is clear here. Floating point has limited precision and the complete inability to exactly represent some numbers.

Example, this equality check is false:

0.1 + 0.2 == 0.3

Because the last bits of a floating point number, after any practical chain of operations, is practically random, do to errors from limited precision. Yes you can always know what the result will exactly be for any operation, if you know the exact number and operations used. Good luck with something like sin/cos though, where implementations can vary wildly depending on the platform/library.

Re: Turns are Better than Radians (2022)

#35

Post by jcranmer »

slwvx wrote: post #5

Yes, the idea of a turn [1] is interesting. And maybe useful. I have a different question: What would it take for a compiler to remove (elide) the multiply by pi + divide by pi that the author uses as an example? I guess one would not have to go as far as a Lean proof that two bits of code produce the same result? [1] https://en.wikipedia.org/wiki/Turn_(angle)

The short answer is you need fast-math flags to allow optimizations that may change floating-point results, and you also need to guarantee an implementation of sinpi/cospi (these were added in C23, so they're not all that common in host library implementations yet).

It's possible if you had the implementation of the math library visible to the compiler that it could do inlining and then simplify expressions, but honestly most math library function implementations are going to be the kind of function that doesn't get picked up by inline heuristics, as there's a pile of if statements (handling special cases and range reduction) that the compiler can't eliminate due to there not really existing a sufficiently powerful FP range analysis.

Re: Turns are Better than Radians (2022)

#36

Post by eru »

nomel wrote: post #34
eru wrote: post #30

Earlier quoted context omitted.

Huh, what? Floating point numbers have a standard, you know. They aren't non-deterministic YOLO numbers. By default, the compiler has to stick to what the standard requires, and can't just say add arbitrary imprecision. Your epsilon is what you get when you try to analyse floating point numbers as approximations of real numbers. But they also have an independent life as bit patterns, and the compiler can't just willy…

Please look at the link where context is clear here. Floating point has limited precision and the complete inability to exactly represent some numbers . Example, this equality check is false: 0.1 + 0.2 == 0.3 Because the last bits of a floating point number, after any practical chain of operations, is practically random, do to errors from limited precision. Yes you can always know what the result will exactly be for…

Your problem only occurs when you try to naively transport equality of real numbers into equality of floating point numbers.

https://www.netlib.org/fp/dtoa.c is how eg CPython parses literals like 0.3 into floating point numbers and how it converts floating point numbers back to strings. Lo and behold: these algorithm compare floating point numbers for equality, and would break catastrophically, if the compiler were allowed to willy-nilly fiddle with the bit patterns.

The authors of these algorithm did care about floating point equality, and that is not a mistake. (However it would be a mistake to assume that equality of mathematical real numbers translates to equality of floating point numbers.)

> Yes you can always know what the result will exactly be for any operation, if you know the exact number and operations used.

Yes, and for some algorithms like illustrated above this is exactly what people do, and have to do.

And the lower bits of 0.1 + 0.2 ain't random: they are the same on your computer as on mine, whether we run the code in 1999 or in 2029.

https://news.ycombinator.com/item?id=47767398 has a discussion.

Re: Turns are Better than Radians (2022)

#37

Post by zarzavat »

nomel wrote: post #18
eru wrote: post #15

Earlier quoted context omitted.

Well, they don't produce the same result in floating point math, I'm afraid. So you'd need to teach your compiler about what your formulas mean and what context you are using them in. (Ie are you actually doing geometry, or is your AI coding agent just trying arbitrary activation functions for your neuronal net experiments and some of them happen to look like geometry?)

It's a mistake to care about equality of floating point numbers [1]. You must usually consider the lower bits of the number as random. I assume you're saying something other than this though? [1] https://en.wikipedia.org/wiki/Machine_epsilon

This statement is a little too strong. It's a mistake to care about the equality of floating point numbers after subjecting them to irrational operations. On the other hand, the entire internet runs on the fact that doubles exactly represent the integers up to 2^53.

Re: Turns are Better than Radians (2022)

#39

Post by kens »

One weird unit for angles is the mil, defined as 6400 mils in a circle. This unit is very useful for artillery, since 1 meter displacement at a distance of 1 km is 1 mil [†]. Thus, you can see how much you missed by, divide by the distance, and easily determine how much you need to adjust your aim in mils. Another interesting thing about artillery is they traditionally do a binary search to get the distance correct, which they call "bracketing". Link: https://unitedtaskforce.net/training/sop/communication/artil...

[†] Note that this isn't exactly correct since it corresponds to pi = 3.2. A mil is almost the same as a milliradian, but 6400 mils in a circle is much more convenient than 6283.18... milliradians in a circle.

Re: Turns are Better than Radians (2022)

#40

Post by kqr »

kens wrote: post #39

One weird unit for angles is the mil, defined as 6400 mils in a circle. This unit is very useful for artillery, since 1 meter displacement at a distance of 1 km is 1 mil [†]. Thus, you can see how much you missed by, divide by the distance, and easily determine how much you need to adjust your aim in mils. Another interesting thing about artillery is they traditionally do a binary search to get the distance correct,…

It's also useful for sighting distances when the width or height of something is known. A knuckle on your outstretched arm is roughly 30 mils, so you cover the thing with your hand, count knuckles, multiply by 30, then divide the size by that number to get the distance.

You can calibrate your knuckles by doing this is reverse. Put up a target 1 cm wide and back up until it's just covered by a knuckle. Measure how far you got and divide.

It was when I thought about why this works I started really understanding radians.

Post reply on HN