381–390 of 494 posts
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
But what is the underlying representation in the wrapper class?
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
If you're not using derivatives, integrals, or complex numbers, maybe you'd be better off using Wildberger's "rational trigonometry" with quadrances and spreads instead of angles? I haven't actually tried it myself. Wildberger's motivation is a sort of ultra-strict Platonism* mixed with the desire to extend analytic geometry to fields other than the real numbers, though, so it wouldn't be surprising if it wasn't actu…
:)
If the op had claimed this is only about API design and efficiency, he'd get much less shit because he has a good argument there.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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…
It changes its meaning and operations.
`x : Angle = 90` and friends should just be illegal. `x : Angle = Degrees(90)` is better. Then the programmer can use whatever is convenient.
Earlier quoted context omitted.
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…
One way to handle this with an Angle type is to not allow an automatic cast from float/double/int. instead, you expose methods that normalise the input and internally can represent it as whatever, i.e. from_degrees, from_turns, from_radians or similar that force the programmer to be explicit about their unit, when the angle is constructed.
Alternatively, Angle could be the base class and each unit gets its own class that Angle inherits from.
Earlier quoted context omitted.
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…
> Wrapping something in a type doesn't magically change its value.
Most formal definitions of value disagree, e.g. from Stepanov & McJones:
A value type is a correspondence between a species (abstract or concrete) and a set of datums. A datum corresponding to a particular entity is called a representation of the entity; the entity is called the interpretation of the datum. We refer to a datum together with its interpretation as a value. In this case the species is abstract, rotational measurement - and the interpretation is the unit. 2pi radians, 360 degrees, and 1 turn all correspond to the same abstract entity; radians, degrees, and turns are types.
But you can also find the mistake just based on your own comment, where you've taken an unjustified leap from variable to value:
> Types are just labels applied to variables... Wrapping something in a type doesn't magically change its value.
Types are labels applied to variables, specifically in order to produce a particular value from the contents of some memory region (what Stepanov & McJones call "datum"). If changing types didn't change values, types would be near-useless (cf, as a concrete example, C's near-useless type system).
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…