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

21–30 of 494 posts

Re: Turns are better than radians

#21

Post by carpenecopinum »

smitty1e wrote: post #9

Turns sound fine. But they are turns of a circle of a given radius. So as long as everything conforms to that coordinate system, we're groovy? Radians (circle fractions) are generally preferred because we can compare, e.g. two planetary orbits, conveniently, no? Or did I miss something?

> But they are turns of a circle of a given radius. > Radians (circle fractions)

It's the other way around actually. A turn is a turn, no matter the radius of the circle. Radians are the length of the line you need to draw a fraction of a circle with a radius of 1.

(In the end, both are just ways to describe angles and thus independent of any radii... the only effective difference between them is a constant factor of tau or two pi.)

Re: Turns are better than radians

#22

Post by rikroots »

On the frontend, one thing that I discovered when implementing color spaces into my canvas library was that the CSS HWB standard[1] allows the hue part of a color (which is an angle value) to be supplied supplied as either 'Ndeg', 'Nrad', 'Ngrad' or 'Nturn' values. Other CSS color spaces involving hue don't see to accept 'turn' (though I could be misunderstanding them).

[1] - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...

Re: Turns are better than radians

#23

Post by eesmith »

tromp wrote: post #18

> Some time ago, much effort was expended to convince people to replace approximations of “pi” (3.14159…) with approximations of “tau” (6. 28318…). IMO the effort was simply to replace the use of pi with the use of tau. What does approximation have to do with it?

It's a correct description. (Perhaps further refined as "technically correct".) The following are not exact values of π or τ, only approximate ones:

  >>> import math
  >>> math.pi
  3.141592653589793
  >>> math.tau
  6.283185307179586

Re: Turns are better than radians

#24

Post by [deleted] »

tromp wrote: post #18

> Some time ago, much effort was expended to convince people to replace approximations of “pi” (3.14159…) with approximations of “tau” (6. 28318…). IMO the effort was simply to replace the use of pi with the use of tau. What does approximation have to do with it?

[deleted]

Re: Turns are better than radians

#25

Post by mjw_byrne »

"math never decreed that sine and cosine have to take radian arguments!"

This is at best questionable and at worst false.

If you only want to use sin and cos as functions for doing trigonometry, it is true that you can choose whatever angle unit you like and stick with it and it will be fine.

For most other stuff, e.g. differential equations, complex analysis, signal processing and mechanics, it's pretty much inescapable that the zeroes of sin are at integer multiples of pi, and that's that.

Re: Turns are better than radians

#26

Post by adrian_b »

While I agree that "turns" are much more convenient in some applications than radians, there is no need to invent a new terminology.

For a long time, including the 19th century, the plane angle measurement unit corresponding with 4 right angles, i.e. a complete rotation around a point, has been named "cycle".

That is why in many old physics or engineering books one will find wave numbers measured in "cycles per meter" and frequencies measured in "cycles per second", for example what is now called as a frequency of "10 MHz" was called as a frequency of "10 megacycle per second".

There are 3 important measurement units for the plane angle and each of them is the most convenient unit for a certain class of applications: the right angle, the cycle and the radian.

(An example where the right angle is the most convenient unit is when expressing a complex number with unit modulus as (i^x) instead of the (e ^ (i * x)) that is used with radians.)

Using the inappropriate plane angle measurement unit for an application causes a loss of precision (which can be large for large angles that must be reduced to the 1st quadrant) and introduces extra arithmetic operations that are not needed.

The radian is used much more frequently than it should be used because many standard programming libraries provide only trigonometric functions with arguments in radians, which is a big mistake.

The recent versions of the Floating-Point Arithmetic standard recommend the functions sinPi, cosPi, tanPi, atan2Pi, asinPi, acosPi and atanPi.

This is another serious mistake, because one normally needs either the trigonometric functions of (x * Pi * 2), i.e. with angles measured in cycles, or those of (x * Pi / 2), i.e. with angles measured in right angles, and never the functions of (x * Pi), which are recommended by the standard.

Re: Turns are better than radians

#27

Post by flowerbreeze »

vardump wrote: post #12
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…

> If anybody knows how similar calculations can be easily achieved in JS for example Simply "a = (a + 0x1234) & 0xffffffff;". Or whatever width you require, 0xff or 0xffff. JIT is going to optimize that and-operation away (at least for 32-bit mask 0xffffffff) and keep the integer value internally. You can also "cast" a var to int by "ORring" 0 with it, like "a |= 0;"

Thank you! This does exactly what I meant. I think this is the best solution for my use-cases. It even handles floating point operations to a correctly, something I didn't expect.

Re: Turns are better than radians

#28

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]

Re: Turns are better than radians

#29

Post by fmajid »

lordnacho wrote: post #8

That was quite convincing actually. I guess we all have this realization at some point in early math education. Why is it 360 degrees? Mainly because that's a nicely divisible number, no other good reason. Sometimes you find a 400 degree system on calculators but it doesn't seem to be taught anywhere (is it a French thing?) Then at some point you get shown radians, which relates the arc length to the radius. That som…

360 comes from the Babylonians, who used base-60 for numbers much for the reasons you describe (and who gave us the 24-hour day, 60 minute hour and 60-minute second, not to mention the 7-day week).

NATO forces have compasses labelled in mils or milliradians, which are not actually 1/1000 of a radian but as an approximation 1/6400 of a full turn. I still have my Silva military compass from 1989 graduated thus.

https://en.wikipedia.org/wiki/Milliradian

Post reply on HN