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

321–330 of 494 posts

Re: Turns are better than radians

#321

Post by 6gvONxR4sf7o »

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…

> Of course you can work in other units, but you'll need to insert the appropriate scaling factors all over the place.

You probably take out more scaling factors than you introduce.

> Euler's formula (e^ix = cosx + isinx) is the simplest when working with radians.

Euler’s still simple:

e^(2 i pi y) = cosy + isiny

Or if you start noticing c = e^(2 pi) showing up all over the place:

c^iy = cosy + isiny

> How do you do the same with "turns" on a sphere?… You can't in any meaningful way.

Why not do the same thing? One steradian is 1/(4 pi) of a sphere’s solid angle. What if one “steturn” or whatever just covered a full solid angle? And similarly for higher dimensions?

Neither definition seems more natural to me, especially being used to all the factors of 2 and pi that pop over all over the place in the status quo.

Re: Turns are better than radians

#322

Post by tsimionescu »

armchairhacker wrote: post #320

Better than turns, radians, etc. is an `Angle` newtype AKA wrapper class. It completely eliminates misinterpretation of the value, miscalculation from [angle = angle + tau*n] as all angles are normalized, is more descriptive, and in a decent language is zero-cost. Programmers should not be using (radians: float) in modern languages which support wrapper classes

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.

Re: Turns are better than radians

#323

Post by fisherjeff »

MichaelCollins wrote: post #317
fisherjeff wrote: post #225

Earlier quoted context omitted.

On a related note, it bothers me that there’s so much urgency to teach younger kids more and more advanced math. I use more and higher math on a day-to-day basis than practically anyone I know, but it’s very rarely even calculus, and even then it’s typically just discrete integrals or derivatives. There’s just an absolute ton of math being taught that’s going completely to waste, and it’s at the expense of the humani…

I think much of math 'education' is constructed as a filter to identify a small handful of math prodigies. The general population suffering anxiety and youth lost in the filter is seen as an acceptable sacrifice for the greater good of finding the math prodigies so those can be given a real math education.

Yes, this is a very good point. In my experience from, uh, several decades ago, it also felt like a lot of math educators watched (and showed in class...) Stand and Deliver way too many times and the only message they took away was "we should teach everyone calculus!"

Re: Turns are better than radians

#324

Post by kennywinker »

smcameron wrote: post #152
otikik wrote: post #117

Fun fact: PICO-8 only provides turn-based trigonometric functions https://pico-8.fandom.com/wiki/Sin > PICO-8 uses an input range of 0.0 to 1.0 to represent the angle, a percentage of the unit circle. Some refer to these units as "turns". For instance, 180° or π (3.14159) radians corresponds to 0.5 turns in PICO-8's representation of angles. In fact, for fans of τ (tau), it's just a matter of dropping τ from your exp…

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

Re: Turns are better than radians

#325

Post by js2 »

mathieuh wrote: post #195
js2 wrote: post #183

Earlier quoted context omitted.

I'm a 50 yo programmer. I have a CS degree. I don't even remember my college calculus much less my high school trig. I just haven't had cause to use it in my career, not as a sysadmin, not as a programmer. My son is taking calc 3 and I knew I happened to have my calc 3 notes from the mid-90s, so I pulled them out of the filing cabinet and my very carefully taken notes, my proofs, my hand drawn graphs, it was all gibb…

I'm 27, educated in the UK, all I remember about trigonometry is SOHCAHTOA.

I’m handy outside of work and use sohcahtoa often enough to remember it. Triangles are everywhere and sometimes you need to compute angles and lengths of sides.

Statistics is also useful and applicable to everyday life, but I didn’t learn that till college as best I can recall.

I don’t regret having spent time learning calc, or physics or chemistry or biology for that matter. If you asked me to come up with a curriculum I’d have a really hard time prioritizing. Maybe the one thing I’d like to see kids learn better is how to be self-directed learners. I’m still fairly surprised at the number of colleagues I have who seem unable to problem solve and figure something the fuck out. Even knowing when and how to ask for help.

Re: Turns are better than radians

#326

Post by kazinator »

> 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 then what do we make of:

   ncos x   +   i nsin x
This has to be

   cos 2πx  +   i sin 2πx
which is then

     2πix        (   2π) ix        ix 
   e           = ( e   )      =  f 

      
           2π
Where f = e is a weird number like 535.4916. This f doesn't have nice properties. E.g.:

      d     x           x
      -   f     /=    f 
      dx
Otherwise it works; for instance 90 degrees is 0.25 and surely enough

     0.25i 
   f          = i
In situations not involving e in relation to angular representations via Euler, f cannot replace e.

I'm all for having parallel trig functions in libraries that work with turns, though.

The annoying 2π factor shows up in lots of places though. Should way, say, in electronics, redefine a new version of capacitive reactance which doesn't have 2πf in the denominator, but only f?

Re: Turns are better than radians

#327

Post by 6gvONxR4sf7o »

cillian64 wrote: post #50
Double_a_92 wrote: post #34

Earlier quoted context omitted.

Why do they need to be at multiple integers of pi, instead of at half turns?

If you differentiate sin(x) with respect to x then you get cos(x), but only if your trig functions are using radians. Any other unit results in an extra coefficient appearing. That’s not an insurmountable problem, but radians are the fundamental unit here, not just an arbitrary choice.

You get extra coefficients appearing, but also extra coefficients disappearing. If 2 pi x is showing up everywhere, you still have to deal with it:

d/dx sin(2 pi x) = 2 pi cos(2 pi x)

vs

d/dy new_sin(y) = 2 pi new_cos(y)

“Fundamental unit” really depends on what you care about.

Re: Turns are better than radians

#328

Post by unclad5968 »

vimsee wrote: post #57
severak_cz wrote: post #20

Earlier quoted context omitted.

It's 360 degrees because of stars. One degree is how much stars move by one day.

> One degree is how much stars move by one day. I was going to look that up to confirm it, but then I realized I could prove that statement true using some simple logic I already know. Earth does one cycle around the sun in 365 days. So at midnight looking straight up on a specific star (that is angled perpendicular of the rotating poles of earth) in the sky, the star you would have spotted on that day would appear s…

Wikipedia agrees with you, technically, except the theory specifically names the sun as the star used. However, the reference is a wolfram alpha article, which only references the book The Elements of Typographic Style. I've never read the book but using the sun position makes sense to me, so I will also choose to believe this until corrected.

Re: Turns are better than radians

#329

Post by lkuty »

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…

"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.

Re: Turns are better than radians

#330

Post by [deleted] »

flowerbreeze wrote: post #6

My favourite way of handling angles was always with either unsigned char or 16bit unsigned int that was treated as 1/nth of turn. Usually in these cases cos/sin tables were pre-calculated for speed, although that need went away to an extent. As long as as the calculations wrap around on the underlying system, it makes angles much easier to manage, because angle1 + angle2 = angle3 is always within 0 to 255 or 0 to 655…

[deleted]
Post reply on HN