Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How do computers calculate sine?

androidcalculator.com

Post reply on HN
Print view View original

71–80 of 167 posts

Re: How do computers calculate sine?

#71

Post by bigbillheck »

vardump wrote: post #70
bigbillheck wrote: post #66

Earlier quoted context omitted.

They switched away from CORDIC at one point: https://www.intel.com/content/www/us/en/developer/articles/t... (there doesn't seem to actually be a linked article there, just the summary)

Pretty weird Intel's sine computation latency hasn't changed all that much over the years. Latencies have been pretty similar for 20 years. EDIT: That's a paper for a software library, not the CPU's internal implementation. Which is probably still done with CORDIC.

> EDIT: That's a paper for a software library, not the CPU's internal implementation.

Unless you're seeing something I'm not, it's talking about x87, which hasn't been anything other than 'internal' since they stopped selling the 80486sx.

Re: How do computers calculate sine?

#72

Post by vardump »

bigbillheck wrote: post #71
vardump wrote: post #70

Earlier quoted context omitted.

Pretty weird Intel's sine computation latency hasn't changed all that much over the years. Latencies have been pretty similar for 20 years. EDIT: That's a paper for a software library, not the CPU's internal implementation. Which is probably still done with CORDIC.

> EDIT: That's a paper for a software library, not the CPU's internal implementation. Unless you're seeing something I'm not, it's talking about x87, which hasn't been anything other than 'internal' since they stopped selling the 80486sx.

Ah you're right.

Anyways I wonder why it's still so slow.

60-120 cycles sure looks like a CORDIC implementation, but perhaps not.

Re: How do computers calculate sine?

#73

Post by mhh__ »

TylerE wrote: post #16
warpech wrote: post #10

This made me realize that trigonometric functions are not deterministic across different CPU architectures, OS, and programming languages (floating point precision aside). E.g. I would assume that Math.sin(x) returns the same thing in NodeJS on Windows and Mac/M1, but it turns out it is necessarily so. https://stackoverflow.com/questions/74074312/standard-math-f...

Safer to assume that floats are never deterministic.

They're always deterministic in some sense (and as long as your OS respects the rounding mode after a context switch properly). This might sound pedantic but it determines how we think about floats — the behaviour is specified quite exactly.

Re: How do computers calculate sine?

#74

Post by contravariant »

TylerE wrote: post #16
warpech wrote: post #10

This made me realize that trigonometric functions are not deterministic across different CPU architectures, OS, and programming languages (floating point precision aside). E.g. I would assume that Math.sin(x) returns the same thing in NodeJS on Windows and Mac/M1, but it turns out it is necessarily so. https://stackoverflow.com/questions/74074312/standard-math-f...

Safer to assume that floats are never deterministic.

I don't think that's safe at all. Catastrophic cancellation would be quite a lot less catastrophic if rounding errors were random but accurate on average.

Re: How do computers calculate sine?

#75

Post by TylerE »

mhh__ wrote: post #73
TylerE wrote: post #16

Earlier quoted context omitted.

Safer to assume that floats are never deterministic.

They're always deterministic in some sense (and as long as your OS respects the rounding mode after a context switch properly). This might sound pedantic but it determines how we think about floats — the behaviour is specified quite exactly.

What I mean is that the same code running on different hardware/os may not always give the same answer. It’ll be close, but you can’t always expect bit for bit identical.

Re: How do computers calculate sine?

#76

Post by dilyevsky »

perihelions wrote: post #19
vardump wrote: post #13

CORDIC is how it's usually done in hardware (and FPGAs). https://en.wikipedia.org/wiki/CORDIC

CORDIC is pretty obsolete, AFAIK. Its advantage is that its hardware requirements are absolutely tiny: two (?) accumulator registers, and hardware adders and shift-ers—I think that's all. No multiplication needed, in particular. Very convenient if you're building things from discrete transistors , like the some of those earlier scientific calculators! (Also has a nice property, apparently, that CORDIC-like routines e…

I think still used out of necessity when hw floating point not available (like fpgas)

Re: How do computers calculate sine?

#77

Post by toolslive »

After reducing the interval, you don't want to use the Taylor series as you're building an approximation that's really good in 0 but not so good moving away from 0. It's better to use an interpolating polynomial (Chebychev comes to mind) over the whole target interval.

Re: How do computers calculate sine?

#78

Post by kevin_thibedeau »

f1shy wrote: post #46
perihelions wrote: post #19

Earlier quoted context omitted.

CORDIC is pretty obsolete, AFAIK. Its advantage is that its hardware requirements are absolutely tiny: two (?) accumulator registers, and hardware adders and shift-ers—I think that's all. No multiplication needed, in particular. Very convenient if you're building things from discrete transistors , like the some of those earlier scientific calculators! (Also has a nice property, apparently, that CORDIC-like routines e…

Multiplication is pretty much needed in cordic! And is far from obsolete! It works perfectly fine, and dont have any of the problems said in the article.

CORDIC doesn't use multipliers. That's the whole appeal for low performance hardware since it's all shifts and adds. It can still be useful on more capable platforms when you want sin and cos in one operation since there is no extra cost.

Re: How do computers calculate sine?

#79

Post by paulpauper »

toolslive wrote: post #77

After reducing the interval, you don't want to use the Taylor series as you're building an approximation that's really good in 0 but not so good moving away from 0. It's better to use an interpolating polynomial (Chebychev comes to mind) over the whole target interval.

There are many ways to do this. It's not a difficult problem unless memory is constrained.
Post reply on HN