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

411–420 of 494 posts

Re: Turns are better than radians

#411

Post by halter73 »

tsimionescu wrote: post #332
throwawayffffas wrote: post #264

Earlier quoted context omitted.

To clarify my objection is with this statement > no one ever writes down numbers in the unit of radians, they already convert to half rotations or full rotations by scaling with pi That statement is true only if you are talking about geometry, If you are working in any other domain the trigonometric functions operate on real numbers and have nothing to with rotations or angles and if I call sin(1) I expect to get bac…

Still, the discussion is only about convenience. For example, e^ix = cos x + i sin x (with sin/cos taking an argument in radians) would become e^ix = cos 2pi x + i sin 2pi x (with sin/cos taking an argument in turns). It's more cumbersome than the radian-based definitions, but it's not strictly different.

As mentioned elsewhere in this thread, with turn-based rotation units, this relationship can be simplified to avoid transcendental numbers entirely:

> (-1)^(2x) = cos(x) + i sin(x)

Re: Turns are better than radians

#412

Post by munificent »

morelisp wrote: post #397
munificent wrote: post #394

Earlier quoted context omitted.

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.

I think you're confusing "representation" to mean just the number of bits allocated to the number, but the article and my comments also use it to mean what the numeric range of those values represents (hence "representation").

How that's modeled in the static type system is completely orthogonal to the underlying arithmetic operations that are performed and their efficiency. The article is entirely about the latter.

Re: Turns are better than radians

#413

Post by jacobolus »

bmacho wrote: post #383
jacobolus wrote: post #377

Earlier quoted context omitted.

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.

Please read back what GGP claimed, and I replied.

Yes, this whole thread repeatedly describes the context as “mathematics”, in which context log unambiguously means the natural log.

Re: Turns are better than radians

#414

Post by naniwaduni »

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.

> I disagree. By wrapping an angle in an Angle class, the internal representation need never be exposed to the programmer.

Because nobody will ever instantiate one?

At the end of the day, you're not implementing these as an exercise in hermetic design, you're trying to do arithmetic, presumably on numbers you have.

Re: Turns are better than radians

#415

Post by InitialLastName »

moffkalast wrote: post #334
shoxidizer wrote: post #163

Earlier quoted context omitted.

> A unit that could be inherently defined by math itself and not a farmer looking at their hands and feet? Where do you think base ten comes from?

Base 2, 10, 3, 8, hex, radians stay radians.

Radians aren't a unit, and degrees have nothing to do with peoples' hands or feet.

Imagine using an angle measurement for physical things such that angles with rational measurements stack to a full circle. Preposterous.

Re: Turns are better than radians

#416

Post by bmacho »

jacobolus wrote: post #413
bmacho wrote: post #383

Earlier quoted context omitted.

Please read back what GGP claimed, and I replied.

Yes, this whole thread repeatedly describes the context as “mathematics”, in which context log unambiguously means the natural log.

Well, both the Wolfram MathWorld and the EMS prefers log_e = ln, and log = log_10:

https://mathworld.wolfram.com/Logarithm.html

https://mathworld.wolfram.com/CommonLogarithm.html

https://encyclopediaofmath.org/wiki/Logarithmic_function

https://encyclopediaofmath.org/wiki/Logarithm_of_a_number .

Also me, and the other commenter below learned "ln" for the natural logarithm, and used "log" only for binary/decimal logarithm.

I am starting to think that log = log_e is actually the minority usage, but it is certainly not universal.

Re: Turns are better than radians

#417

Post by morelisp »

munificent wrote: post #412
morelisp wrote: post #397

Earlier quoted context omitted.

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.

I think you're confusing "representation" to mean just the number of bits allocated to the number, but the article and my comments also use it to mean what the numeric range of those values represents (hence "representation"). How that's modeled in the static type system is completely orthogonal to the underlying arithmetic operations that are performed and their efficiency. The article is entirely about the latter.

No, I think you're confused about what I'm saying about performance. I definitely don't think "representation" just means the number of bits.

> How that's modeled in the static type system is completely orthogonal to the underlying arithmetic operations that are performed and their efficiency.

No! A type system gives information in in both directions. Normally yes, we use it to impose some interpretation on a representation to produce a value, so we can think in values and not bits. But if two types model the same range of entities, i.e. angular measurements, it also tells you if you have a value with a representation that you might have to spend time futzing with to integrate with something else expecting the same entity but a different type.

If we had reasonable types, sin could define the type it wants to do what it does efficiently (turns, or radians if the platform has an efficient instruction, or a lookup table index into some division of a quadrant, or whatever). That representation matters to the sin author, but not the user. All the user cares about is, then, how many times do I have to pay some conversion cost? And if I'm using the type the sin author provided, the answer is zero (or maybe like one, at initial load). But that relies on the sin author using such a newtype.

(Arguably the user also cares how much memory it takes to store the representation the sin author chose, but in practice for sin that's going to be a word or less whatever the representation is.)

You also have a blinkered view of the article if you think it's "entirely about" performance, given how often it also talks about simplicity and accuracy.

Re: Turns are better than radians

#418

Post by JackFr »

tsimionescu wrote: post #354
JackFr wrote: post #315

Earlier quoted context omitted.

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.

I'm shaky on this - it's been thirty years - but I believe the Calc I epsilon delta proofs relied on the notion of an open and closed intervals on the real line, which we all intuitively understood.

The upper level Real Analysis made us bring some rigor as to what an interval on the real line actually meant going from raw points and sets to topological spaces to metric spaces, then compactness, continuity, etc. all with fun and crazy counterexamples.

Re: Turns are better than radians

#419

Post by LukeShu »

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

The original Asteroids source code has been released, we can look at what it did! (Also, even before that the EPROM images had been disassembled, but looking at the original sources is more fun.)

It indeed used (-128, 128) for (-180°,180°)

For instance, here it is using 64 (written as "40", because hexadecimal) for "PI/2":

    COS:    CLC                     ;COS(A)=SIN(A+PI/2)
            ADC I,40
    ;       JMP SIN
It implements COS in terms of SIN, and SIN wraps everything to be in the domain [0,64] (that is [0°,90°] ) then retrieves that from the lookup table.

code: https://github.com/historicalsource/asteroids/blob/main/A351...

table: https://github.com/historicalsource/asteroids/blob/main/A351...

Re: Turns are better than radians

#420

Post by SideQuark »

btilly wrote: post #339
panda-giddiness wrote: post #166

As already mentioned by others, radians are not arbitrary units for angles; in fact, they are the "natural" "units", so to speak. By definition, an angle is just the ratio of a circular arc ( s ) to its radius ( r ), θ = s / r (as an exercise, imagine how to apply this definition to the angle between two intersecting lines). When the length of the circular arc equals its radius ( s = r ), the angle subtended is exact…

The fact that it is natural doesn't make it performant and straightforward for all applications. For example linear algebra is the natural and general way to handle vectors. However game developers still find quaternions faster and more performant.

>The fact that it is natural doesn't make it performant and straightforward for all applications.

How does changing the scale make anything more or less performant?

If anything, it makes things less performant since to use any hardware supported trig functions you now have to convert your weird angle representation into radians. For simple addition or fractions of your angle, it is just as performant as using angles in any scaling.

> For example linear algebra is the natural and general way to handle vectors. However game developers still find quaternions faster and more performant.

They only use quaternions for a few things, like slerp, and mostly because of gimbal lock.

For everything else they still use linear algebra, and linear algebra is used much, much more than quaternions for nearly any 3d program.

Post reply on HN