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

351–360 of 494 posts

Re: Turns are better than radians

#351

Post by jacobolus »

pdpi wrote: post #112

Indeed, maths never "decreed that sine and cosine have to take radian arguments". But thinking that makes any sort of point is a fundamental misunderstanding of maths. There are infinitely many sinusoidal functions out there. You can just adjust amplitude, frequency and phase to your heart's content. Trigonometry basically requires that sine and cosine have specific amplitudes and phases, but gives not one shit about…

> Degrees are completely arbitrary

Degrees are very natural in the context of ancient astronomy/astrology, where you have (1) ~365 days in a year, so that if you look at the path of something that takes a year you get about one degree change per day but with a number that is more easily divisible. (2) approximately 4y, 10y, 8y, 15y, 12y, 30y cycles for the moon and various planets. (3) A calendar with 12 months, 12 zodiac signs. (4) A timekeeping system which breaks days into 24 hours and then uses divisions by sixty for smaller units. (4) A base-sixty number system – from ancient Mesopotamia, which persisted as the standard for astronomical calculations for millennia, only displaced in the very recent past.

Re: Turns are better than radians

#352

Post by zardo »

sbaiddn wrote: post #174

Saying "rad" are bad units for sin is like saying e is a bad base for logarithms. The only "bad" thing about rads is that they're not taught early enough so that culturally 45 degrees are not know as pi/4. Then a turn would be known as simply as 2pi (or "a one eighty" as Americans infuriatingly like to call it when someone rotates 360 about themselves)

> (or "a one eighty" as Americans infuriatingly like to call it when someone rotates 360 about themselves)

I've never heard of this. Even if you fail math, you'll know this from playing Tony Hawk Pro Skater.

Re: Turns are better than radians

#353

Post by newobj »

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

Pico8 is 128x18 res, so I think the maximum number of visibly unique lines you could draw from one point is 512. You can't even express sub-one-degree (sub-1.422222 really) rotations on Pico8 visually without subsampling etc.

Re: Turns are better than radians

#354

Post by tsimionescu »

JackFr wrote: post #315
Swizec wrote: post #267

Earlier quoted context omitted.

My biggest “Screw everything” moment about math was the first lecture of my numerical methods class in college when the professor said: “All that calculus you’ve been learning your whole lives? It’s useless. Carefully curated set of a few dozen problems that are doable by hand. Here’s how it’s really done for anything remotely practical” And then we learned a bunch of algorithms that spit out approximate answers to a…

When I took 400 level Real Analysis: “All that calculus you’ve been learning your whole life? It’s a lie. Those epsilon delta proofs? They were fake - none of you were smart enough to challenge us on ‘limits’. And now we’re gonna do it all again only this time it’s really gonna be rigorous.”

Is there any somewhat simple explanation of what are the limitations of the epsilon-delta definition of limits that make it non-rigorous? I've been trying to find some information about your comment, but have so far come up empty.

Re: Turns are better than radians

#355

Post by jacobolus »

bmacho wrote: post #265
zarzavat wrote: post #191

Earlier quoted context omitted.

The situation is similar to that of the logarithm and exponential functions[0]. There’s a log2 function and a log10 function and they are both useful. But when we talk about the log() function there can be no doubt that it is to base e. If you want to define a sinT() function that works in turns then that’s totally fine. But the sin() function is defined as taking an argument scaled in radians, because it is mathemat…

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 rules, lookups in paper tables, and pen-and-paper arithmetic, but with the advent of computers multiplication is just as cheap as addition, and expressing things on log scales is less necessary.

Over time the mathematicians are winning the fight to define the symbol 'log'.

Re: Turns are better than radians

#356

Post by tsimionescu »

londons_explore wrote: post #341
tsimionescu wrote: post #322

Earlier quoted context omitted.

This has nothing to do with the article, and it is equally applicable to degrees, radians, or turns. It neither solves nor hinders the simplicity or performance issues the article was talking about.

I disagree. By wrapping an angle in an Angle class, the internal representation need never be exposed to the programmer. Rather than every programmer needing to read this blog post to see the performance benefits of using 'turns', instead now just a few library developers need to.

Types are just labels applied to variables. Their only power is type-checking a program to see whether every variable use is consistent. Wrapping something in a type doesn't magically change its value.

Not to mention, Angle is a particularly poor name, since radians, degrees and turns are all different measures of angles.

Say I have this program:

  x : Angle = 90 
  y : Angle = pi/4
  z : Angle = 1/4

  sin : Angle -> Real
  
  sin x //what will this print?
  sin y //how about this?
  sin z // ?

Re: Turns are better than radians

#357

Post by jVinc »

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. If you take it to the power of something divisible by 2 you get itself raised to zero. What's up with this spooky periodicity? Also if you have x=1/4, then we get weird numbers like sqrt(-1) what on earth is that all about? No way that will fly, no way. No I'll take my 2.718^((-1)^(1/2)) and multiply through with 6.28318 that way I don't have to bother understanding what I'm doing I can sleep comfortable at night knowing that someone else has done all the thinking that needs to be done on the matter, and that turns or rotations are a blasphemous concept that breaks the very concept of math through scaling of an axis. You'd think math was strong enough to withstand such a minor change, but the textbooks do not mention it thus it must not be contemplated!

Re: Turns are better than radians

#358

Post by bonzini »

fluoridation wrote: post #176
bonzini wrote: post #131

Earlier quoted context omitted.

But they're not equal to 1, for example a degree is 0.01745...

1° is actually 0.0174... radians . 1 radian is 57.295...°. The choice of unit to specify an angle is arbitrary.

But the angle is an adimensional unit (it's the ratio of two distances, one along the circumference and one along the radius) so 1 rad = 1. Therefore 1 degree is 0.0174... radians but it is also just 0.0174.

Re: Turns are better than radians

#359

Post by rocqua »

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…

This makes a lot of sense when you are expecting to take derivatives, integrals, or use complex numbers.

In cases outside of that, radians lose their advantage over turns.

Re: Turns are better than radians

#360

Post by wnoise »

bonzini wrote: post #127
tromp wrote: post #106

Earlier quoted context omitted.

> you always have to go back to radians to actually do calculation. The article actually argues the opposite: that the common implementations of sine and cosine start by converting their radian based arguments to turns or halfturns by dividing by pi.

That's just because the power series would take ages to converge for large arguments, so you take advantage of periodicity. But the implementation in a floating point world is a different thing than the definition in an infinite series world. For example, e^x can be implemented by handling the integer and fractional parts separately, for similar reasons. But no one really cares about the functions e^floor(y) and e^(y…

That's really not the only thing going on. Yes, it allows you to take advantage of periodicity. But many common function approximations work best (i.e. not requiring any transform of the argument) over the interval [-1, 1].
Post reply on HN