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

211–220 of 494 posts

Re: Turns are better than radians

#211

Post by uup »

jacobolus wrote: post #194
SkeuomorphicBee wrote: post #134

Earlier quoted context omitted.

The point of the original post is that depending on your field (e.g. game engine), maybe all the calculations you need can be done easier in the unit of convenience (e.g. sine of a turn is easier to calculate than sine of radian), so if that is the case you should stick with the unit of convenience thru all the layers and forget about converting to radians in your code. And using fraction of a turn is also a very goo…

If you are making something like a game engine using computer hardware from the past 30 years, you should avoid angle measures to the extent possible. It is much computationally cheaper and more robust (and easier to reason about) to use vector algebra throughout. Then you have no transcendental functions, just basic arithmetic and the occasional square root. You need the dot product and the wedge product (or combine…

I mean that’s all well and good until you have an object in your game and you’re like “I’d like this object to be leaning at 45 degrees, oops I mean 0.70710678118 + i*0.70710678118

Re: Turns are better than radians

#212

Post by mjw_byrne »

jacksnipe wrote: post #197
mjw_byrne wrote: post #161

Earlier quoted context omitted.

"triangles have very little to do with the true nature of sin and cos" <- this is what I mean.

Sure, but circles are geometric too :)

Absolutely, but IMO circles have as little to do with sin and cos as triangles do :-)

Re: Turns are better than radians

#213

Post by syrrim »

adrian_b wrote: post #63
fbanon wrote: post #32

>But math never decreed that sine and cosine have to take radian arguments! Ummm, actually it did. The Taylor-series of sine and cosine is the simplest when they work with radians. Euler's formula (e^ix = cosx + isinx) is the simplest when working with radians. Of course you can work in other units, but you'll need to insert the appropriate scaling factors all over the place. "Turns" don't generalize to higher dimens…

The simplicity of the Taylor series of sine and cosine is irrelevant, there are no important applications for those series. There is only one consequence of those series that matters in practice, which is that when the angles are expressed in radians, for very small angles the angle, its sinus and its tangent are approximately equal. While this relationship between small angles, sinuses and tangents looks like an arg…

A simple example: suppose we want to compute cos(x)-1 near x=0, with high accuracy, in single precision fp. How to do this? Its very easy: google "taylor series for cosine", lobb off the fist term (1), and you're done.

Re: Turns are better than radians

#214

Post by jacobolus »

uup wrote: post #211
jacobolus wrote: post #194

Earlier quoted context omitted.

If you are making something like a game engine using computer hardware from the past 30 years, you should avoid angle measures to the extent possible. It is much computationally cheaper and more robust (and easier to reason about) to use vector algebra throughout. Then you have no transcendental functions, just basic arithmetic and the occasional square root. You need the dot product and the wedge product (or combine…

I mean that’s all well and good until you have an object in your game and you’re like “I’d like this object to be leaning at 45 degrees, oops I mean 0.70710678118 + i*0.70710678118

At a high level you should be expressing something like one of "turn this by the angle between vector (1,0) and vector (1, 1)"; "point this in the direction of vector (1, 1)"; or "turn this by the square root of the rotation i" (i = a quarter turn).

If you use angle measures (of whatever units), when you say "rotate by an eighth of a turn" you are instead going to end up with something internally like: multiply some vector by the matrix

[cos ¼π, –sin ¼π ; sin ¼π, cos ¼π]

which is ultimately the same arithmetic, except you had to compute more intermediate transcendental functions to get there.

If you just have to do this a few times, angle measures (in degrees or whatever) are a convenient human interface because most people are very familiar with it from high school. You can have your code ingest the occasional angle measure and turn it into a vector-relevant internal representation immediately.

P.S. If you write 1/√2 in your code compilers are smart enough to turn that into a floating point number at compile time. :-)

Re: Turns are better than radians

#215

Post by dan_mctree »

cygx wrote: post #118
hutzlibu wrote: post #76

Earlier quoted context omitted.

Whats wrong with long variable names?

Did you ever need to do involved mathematical manipulations using pen and paper? How would you judge the readability of the following expressions: zero_point equals negative prefactor divided_by two plus_or_minus square_root_of( square_of(prefactor divided_by two) minus absolute_term ) zero_point = -prefactor/2 ± √((prefactor/2)² - absolute_term) x = -p/2 ± √((p/2)² - q)

I might be strange but the second seems far more readable than the third to me. The first is of course nonsense.

Re: Turns are better than radians

#216

Post by ouid »

ncmncm wrote: post #123
doliveira wrote: post #90

Earlier quoted context omitted.

Yeah, seems to me that languages should allow way more semantic expression than most do today. I wish I had done CS, those kinds of compiler optimization sounds so fun. I'd love to work on that

Good news, optimization is engineering, not CS. CS is all about what a program would eventually do, if you were ever to run it. Once you run it, you have moved to the domain of technicians. Engineering is about making it run better.

Compiler optimization is very much CS.

Re: Turns are better than radians

#217

Post by [deleted] »

hutzlibu wrote: post #76
doliveira wrote: post #52

Earlier quoted context omitted.

sin(x) ~~ x only in radians, so honestly that's reason enough. Once in a while we get programmers wanting to disrupt mathematical notation for whatever reason... Worst I've seen so far was one arguing that equations should be written with long variable names (like in programming) instead of single letters and Greek letters. Using turns because it's a little easier in specific programming cases is just as short-sighte…

Whats wrong with long variable names?

[deleted]

Re: Turns are better than radians

#218

Post by techtinker »

fbanon wrote: post #32

>But math never decreed that sine and cosine have to take radian arguments! Ummm, actually it did. The Taylor-series of sine and cosine is the simplest when they work with radians. Euler's formula (e^ix = cosx + isinx) is the simplest when working with radians. Of course you can work in other units, but you'll need to insert the appropriate scaling factors all over the place. "Turns" don't generalize to higher dimens…

I do not see how higher dimensions invalidates the concept. Steradians are replace by a scaled unit-less number that I will called sterturns that goes from 0 to 1.

Re: Turns are better than radians

#219

Post by ncmncm »

ouid wrote: post #216
ncmncm wrote: post #123

Earlier quoted context omitted.

Good news, optimization is engineering, not CS. CS is all about what a program would eventually do, if you were ever to run it. Once you run it, you have moved to the domain of technicians. Engineering is about making it run better.

Compiler optimization is very much CS.

Only in practice. And, mostly implemented by engineers.

Re: Turns are better than radians

#220

Post by uup »

jacobolus wrote: post #214
uup wrote: post #211

Earlier quoted context omitted.

I mean that’s all well and good until you have an object in your game and you’re like “I’d like this object to be leaning at 45 degrees, oops I mean 0.70710678118 + i*0.70710678118

At a high level you should be expressing something like one of "turn this by the angle between vector (1,0) and vector (1, 1)"; "point this in the direction of vector (1, 1)"; or "turn this by the square root of the rotation i " ( i = a quarter turn). If you use angle measures (of whatever units), when you say "rotate by an eighth of a turn" you are instead going to end up with something internally like: multiply som…

In most game engines, constructing the rotation matrix is trivial. Something like Quaternion.Euler(0, 45, 0). The ultimate position / rotation of any given object in a game is usually a compound transform computed via matrix multiplication anyway, e.g. a model view projection matrix. I'm not sure it's the best way, but that's just how most game engines work.
Post reply on HN