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

371–380 of 494 posts

Re: Turns are better than radians

#371

Post by aaaaaaaaaaab »

kennywinker wrote: post #324
smcameron wrote: post #152

Earlier quoted context omitted.

Back in the early 80's a common thing to do in games on 8 bit computers was to implement sin and cos as lookup tables with the angles being 0-255 or 0-128 or something like that and the result also an integer that was some fixed point representation, so you'd do something like: vx = (cos[angle] * speed) >> 8; vy = (sin[angle] * speed) >> 8;

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

The sin/cos lookup tables would only contain an octant of the circle and use various symmetries to map other values to that range. Thus the resolution is ~0.176 degrees for a 256-entry table.

sin(x) = -sin(-x) = sin(pi - x) = cos(pi/2 - x)

cos(x) = cos(-x) = -cos(pi - x) = sin(pi/2 - x)

Re: Turns are better than radians

#372

Post by mihaaly »

happimess wrote: post #165
mihaaly wrote: post #151

This constant need to redefine the known world around a favourite detail amazes me. Are people that bored?! (also I itch hearing the idea of redefining interface - and the world - to fit the implementation detail. how about reimplementing using the [0...0.7854] domain instead of the [0...1] if this is such a huge worry after decades of computing - on slower machines - with the natural radian (arc_length/radius) value…

I think that the author is speaking about their world, in which they regularly encounter a specific use of trigonometric functions which would be simplified (conceptually and computationally) by skipping the conversion from and into radians. > redefine the known world around a favourite detail I think that's a good way to think about software optimization. Deep inside nested loops of a game engine (TFA's example code…

I think they are trying to expand it beyond their world. They already have this in their world! Shown with examples. Just want it elsewhere as well.

Not everything is about software automation! Especially in this regard where decade long established practices work on legacy hardware and systems. This is ruining/complicating things for some chip of the scope.

Re: Turns are better than radians

#373

Post by bmacho »

jacobolus wrote: post #355
bmacho wrote: post #265

Earlier quoted context omitted.

The sine function, defined as x-x^3/3!+... doesn't take argument scaled in radians. It takes real numbers. It has nothing to do with radians, really. Or even with angles. The other sine function, defined using right triangles takes argument in Angles, also has nothing to do with the measuring unit. (Also I don't know who told you that log() denotes log_e. Maybe in your narrow environment, but definitely not universal…

> who told you that log() denotes log_e. Maybe in your narrow environment This is a nearly universal convention in modern mathematics (except a few niches like information theory and computational complexity theory where it means log base 2, which is usually clear from context). Engineering disciplines used to use "common" logarithms (i.e. base ten) all over the place back when most calculations were done with slide…

https://www.google.com/search?q=log(10)

Re: Turns are better than radians

#374

Post by kazinator »

jVinc wrote: post #357
kazinator wrote: post #326

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

That's a nice result. If we rearrange the products in the exponent we get

     2πix          πi2x          (  πi ) 2x
   e         ->   e         ->   (e    )
Where e^(πi) is -1. That shows there is something to the turns units; we can express the analog of the Euler identity using exponentiation using a base and factor which are integers.

Huge selling point for turns, IMHO.

Re: Turns are better than radians

#375

Post by lkuty »

bmacho wrote: post #343
lkuty wrote: post #329

Earlier quoted context omitted.

"Also I don't know who told you that log() denotes log_e. Maybe in your narrow environment," e.g. https://reference.wolfram.com/language/ref/Log.html But I must confess that we had ln() in university courses and by default log used base 10. Now I use ln and a base for the log as a subscript like log_10, log_2, etc.

Srsly? Well, then according to https://en.wikipedia.org/wiki/Brainfuck the + symbol denotes cell increment and not addition. > But I must confess that we had ln() in university courses Same. I often wonder why would anyone denote the natural logarithm with log(), when ln is shorter, and easier to read (at least for the people that were thought to use it), also it is already somewhat established.

Haha the Brainfuck analogy was funny. Note that in programming languages it looks like Log denotes Ln. Anyway, Log_b(x) = Log_a(x) / Lob_a(b), so we're covered.

Re: Turns are better than radians

#376

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

#377

Post by jacobolus »

bmacho wrote: post #373
jacobolus wrote: post #355

Earlier quoted context omitted.

> who told you that log() denotes log_e. Maybe in your narrow environment This is a nearly universal convention in modern mathematics (except a few niches like information theory and computational complexity theory where it means log base 2, which is usually clear from context). Engineering disciplines used to use "common" logarithms (i.e. base ten) all over the place back when most calculations were done with slide…

https://www.google.com/search?q=log(10)

Yes, Google in this context is a glorified pocket calculator, and follows the convention from the slide rule era. But if you find log in a mathematics paper it almost surely means the natural log.

Re: Turns are better than radians

#378

Post by dublin »

Bravo! Bravo!! Now if we can just make base10 math the default in modern languages and only let the very few propeller headed weenies that really need it ever pay attention to floating point math and IEEE-754 Hell, we can join the 21st century we were promised.

(Oh, where's my flying car, dammit?!)

Re: Turns are better than radians

#379

Post by sacrosancty »

jefftk wrote: post #122
nurbl wrote: post #13

I agree that this makes sense for the kind of situations that the article talks about. If you only need to express common angles like 90 degrees, 45 and so on, radians are just messy (though in physics, you get used to it). But in other cases, radians are useful. For example consider the case of small deviations from a direction. If you give it in radians, let's say three mrad (milliradians), it's very easy to estima…

To elaborate a bit: that works because sin(x) is very close to x for small x, but only when x is measured in radians.

also known as the fundamental theorem of engineering. Works great for small deformations of stiff materials like steel and concrete.

Re: Turns are better than radians

#380

Post by meheleventyone »

shadowgovt wrote: post #287
meheleventyone wrote: post #107

Earlier quoted context omitted.

Most game engines work in radians under the hood and expose degrees in the UI but still need to glue the UI values to the API which is the code seen in Casey’s Godot example the full context of which is a color picker and h has already been converted from degrees. Godot itself has a bunch of the API in degrees which is pretty bleugh.

It's for convenience of developing tooling. Because the only thing harder than re-framing all of mathematics so that sine and cosine are properly defined in terms of turns would be teaching artists and level designers to believe that a full turn is 2π radians instead of 360 degrees.

Yeah tooling is fine in degrees, which is what I was saying in the first part off my post. It’s more mixing it in the API rather than at the boundaries that is bleugh.
Post reply on HN