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

391–400 of 494 posts

Re: Turns are better than radians

#391

Post by sacrosancty »

adrian_b wrote: post #132
WastingMyTime89 wrote: post #67

Earlier quoted context omitted.

The writer don’t seem to realise that radian is not an arbitrary unit but a dimensionless one which is defined so that 1rad is actually just 1. Reading the submission and the comments here, I’m under the impression that trigonometry is not extensively taught in middle schools and high schools in the USA. While I’m slightly envious you might not have to suffer developing powers of cosine and sine but that would explai…

No, like many others you have been confused by the incapacity of those who vote the modifications of the International system of units to decide what kind of units are the units for plane angle and for solid angle: base units or derived units. A base measurement unit is a unit that is chosen arbitrarily. A derived measurement unit is one that is determined from the base units by using some relationship between the ph…

Thanks for writing that. While I don't automatically believe it all, I think it's important to see what's arbitrary and what's natural in our units. I've struggled with the Hz vs rad/s before and I think I resolved it by including the cycle as a quanitity, so Hz = cycle/s and rad/s = 1/s. You don't seem to agree and I'm not confident of my decision, but it's now part of a big technical debt :P

A clear sign of how wrong people can be about the naturalness of units is Avogadro's constant which was recently demoted from a measured value to an exact arbitrary value. Chemists often believe that N_A, moles, atomic mass units, etc. are all somehow important or fundamental and don't realize that it's all based on a needlessly complicated constant with an (until 2019) needlessly complicated definition that could have just been a simple power of 10 if history had gone differently. Luckily the people defining SI have finally moved away from the old two independent mass units to just the kg that can now be exactly converted to atomic mass units by definition.

Re: Turns are better than radians

#392

Post by meheleventyone »

shadowgovt wrote: post #386
meheleventyone wrote: post #380

Earlier quoted context omitted.

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.

The API is intended to directly support tooling (which is, generally, just another app running atop the same engine).

Most APIs are intended to be used, doesn’t mean you need to mix units, particularly when they both use the same basic type and thus are easy to muddle up. That’s why you keep the API consistent and deal with conversion at the edges. I get you’re probably very keen on Godot but it’s definitely one of the weird warts that all engines accumulate and my intention isn’t to say it’s bad because of this choice. Just that I don’t like that choice and the reason why.

Re: Turns are better than radians

#393

Post by shadowgovt »

meheleventyone wrote: post #392
shadowgovt wrote: post #386

Earlier quoted context omitted.

The API is intended to directly support tooling (which is, generally, just another app running atop the same engine).

Most APIs are intended to be used, doesn’t mean you need to mix units, particularly when they both use the same basic type and thus are easy to muddle up. That’s why you keep the API consistent and deal with conversion at the edges. I get you’re probably very keen on Godot but it’s definitely one of the weird warts that all engines accumulate and my intention isn’t to say it’s bad because of this choice. Just that I…

Ah, I see what you mean. I tend to be operating with APIs in languages that wouldn't call radians and degrees the same units and wouldn't let you just call a function that takes radians with degrees without an explicit cast; forgot that was a thing people have to worry about.

Re: Turns are better than radians

#394

Post by munificent »

morelisp wrote: post #382
munificent wrote: post #340

Earlier quoted context omitted.

But what is the underlying representation in the wrapper class?

Does this matter any more than the fact the underlying representation within sin is e.g. an 80 bit number no programming language can give you? `Angle` is a bad name for this example because a newtype should be named after the unit rather than what it models, but once you've newtyped it, what matters is that you call sin with the right one, not the actual representation.

Yes, the entire point of the article is that it does in fact matter.

> what matters is that you call sin with the right one, not the actual representation.

No, the actual representation does matter. At some point, arithmetic operations are being performed and those operations consume CPU cycles. If you care about the performance of the code, you care about having a representation that minimizes the number of those operations.

Re: Turns are better than radians

#396

Post by scythe »

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…

>The actual equation you come to for ncos an nsin is:

>(-1)^(2x) = ncos(x) + i nsin(x)

Try to formally define this procedure, though. You end up going in circles.

Here's another version:

lim[N->infinity] (1 + ix/N)^N = cos(x) + i sin(x)

Now there are no "weird numbers", and both sides of the equation can be calculated directly, even by hand if you wanted.

If all you're teaching students is a bunch of formulas to be memorized, the (-1)^x notation is kind of cute. But usually when teaching math, we want to build some kind of understanding.

Re: Turns are better than radians

#397

Post by morelisp »

munificent wrote: post #394
morelisp wrote: post #382

Earlier quoted context omitted.

Does this matter any more than the fact the underlying representation within sin is e.g. an 80 bit number no programming language can give you? `Angle` is a bad name for this example because a newtype should be named after the unit rather than what it models, but once you've newtyped it, what matters is that you call sin with the right one, not the actual representation.

Yes, the entire point of the article is that it does in fact matter. > what matters is that you call sin with the right one, not the actual representation. No, the actual representation does matter. At some point, arithmetic operations are being performed and those operations consume CPU cycles. If you care about the performance of the code, you care about having a representation that minimizes the number of those op…

So make sure you use `typeof sin[0]` or whatever the syntax is in your language for your own variables - in the end this still requires newtyping the thing.

For performance in this context, the actual representation does not matter - only that your code and your sin code agree to avoid the conversion cost.

Re: Turns are better than radians

#398

Post by meheleventyone »

shadowgovt wrote: post #393
meheleventyone wrote: post #392

Earlier quoted context omitted.

Most APIs are intended to be used, doesn’t mean you need to mix units, particularly when they both use the same basic type and thus are easy to muddle up. That’s why you keep the API consistent and deal with conversion at the edges. I get you’re probably very keen on Godot but it’s definitely one of the weird warts that all engines accumulate and my intention isn’t to say it’s bad because of this choice. Just that I…

Ah, I see what you mean. I tend to be operating with APIs in languages that wouldn't call radians and degrees the same units and wouldn't let you just call a function that takes radians with degrees without an explicit cast; forgot that was a thing people have to worry about.

That’d definitely be my preference as well. Games is full of this as well. Handedness and general definition of coordinate system is another fairly arbitrary decision you want to keep consistent in your API but have to translate at the boundaries quite often.

Re: Turns are better than radians

#399

Post by ComputerGuru »

eesmith wrote: post #171
SuchAnonMuchWow wrote: post #54

Earlier quoted context omitted.

The effort wanted to replace all uses of Pi (including the ones in math formulas) and not just their use in (floating-point) computer programs where we implement approximations of those formulas.

Sure. But just because there was {a lot of work to replace all uses of pi with tau} doesn't mean there wasn't {a lot of work to replace all approximate uses of pi with approximate uses of tau in computer programs}.

Right, which makes it an effectively incorrect description. It is like if I said I wanted to change all green fruits to orange ones and you reported that as "my undertaking to change green apples to orange apples." It's the truth, but it's not the whole truth.

Re: Turns are better than radians

#400

Post by red_trumpet »

mjw_byrne wrote: post #143
red_trumpet wrote: post #105

Earlier quoted context omitted.

> or the imaginary and real parts of e^ix For that particular application, x is exactly the argument[1] of your complex number, though! [1] https://en.wikipedia.org/wiki/Argument_(complex_analysis)

True, however that doesn't mean x represents an angle. It means you can put a geometric interpretation on an abstract formula. e^ix = cos x + i sin x regardless of what x represents - if you were doing electrical engineering it might be time, for example. Interpretation is often strongly motivated by what "comes first" in the order in which you learn things, so the whole debate is a bit subjective anyway. Another com…

> the area is just a convenient geometric interpretation, which actually makes no sense for many (most?) integrals.

Could you elaborate on this? Because we defined the (Lebesgue) integral in my analysis 3 course exactly in this way: First define what measurable sets are, and what their volume is. Then the integral of a non-negative function is the volume under its graph, if that is measurable.

Post reply on HN