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

51–60 of 167 posts

Re: How do computers calculate sine?

#51

Post by cogman10 »

enriquto wrote: post #37
cogman10 wrote: post #20

Earlier quoted context omitted.

Well, what's fun is that (AFAIK) trigonometric functions tend not to be implemented in the newer floating point instructions, such as AVX or SSE. So while what you say is true about the x87 implementation of those functions, for anything targeting a machine built in the last 20 years it's likely the code will run consistently regardless the architecture (barring architecture floating point bugs, which aren't terribly…

> x87 is just a really weird and funky instruction set that's best left in the gutter of history hmmm, can you use the long doubles in sse or avx? They are glorious, and as far as I see from playing with godbolt, they still require dirtying your hands with the x87 stack.

The 80bit float? Not as far as I'm aware. However, it's fairly trivial to represent a 127bit float with 2 64bit floats. And with the nature of AVX/SSE, you don't really take much of a performance hit for doing that as you are often operating on both parts of the double with the same instruction.

Re: How do computers calculate sine?

#52

Post by perihelions »

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.

It uses multiplication by powers of two, which is a floating-point bit shift.

Re: How do computers calculate sine?

#53

Post by TylerE »

saagarjha wrote: post #43
TylerE wrote: post #16

Earlier quoted context omitted.

Safer to assume that floats are never deterministic.

This is not always a safe assumption (in certain scenarios floating point results being nondeterministic has the possibility to introduce bugs and security issues) and is also a kind of sad way to look at the world. The response to "I don't understand how this works" should not be to adopt an incorrect viewpoint, but to know the limitations of your understanding.

It’s not that I don’t understand, it’s that I do. Floats are inherently lossy representations. Yes, this means the more operations you perform on a float input, the fuzzier the value is.You ignore that harsh reality at your peril. If you find engineering rigor sad, I don’t know what to tell you.

Re: How do computers calculate sine?

#55

Post by enriquto »

cogman10 wrote: post #51
enriquto wrote: post #37

Earlier quoted context omitted.

> x87 is just a really weird and funky instruction set that's best left in the gutter of history hmmm, can you use the long doubles in sse or avx? They are glorious, and as far as I see from playing with godbolt, they still require dirtying your hands with the x87 stack.

The 80bit float? Not as far as I'm aware. However, it's fairly trivial to represent a 127bit float with 2 64bit floats. And with the nature of AVX/SSE, you don't really take much of a performance hit for doing that as you are often operating on both parts of the double with the same instruction.

Do you know if there's language support for that? Are there obscure gcc options that make "long double" be quadruple precision floats?

Re: How do computers calculate sine?

#56

Post by retrac »

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...

Rounding transcendentals correctly has unknown time and space complexity. [1] Sort of brushes up against the halting problem. With limited precision, the upper limit becomes calculable but it's rather large - packages that offer correct rounding on 64-bit floating point use potentially hundreds of bytes to deal with a single floating point value. Dedicated circuitry to implement it fast would be big and complicated even by today's standards.

https://en.wikipedia.org/wiki/Rounding#Table-maker's_dilemma

Re: How do computers calculate sine?

#57

Post by cogman10 »

enriquto wrote: post #55
cogman10 wrote: post #51

Earlier quoted context omitted.

The 80bit float? Not as far as I'm aware. However, it's fairly trivial to represent a 127bit float with 2 64bit floats. And with the nature of AVX/SSE, you don't really take much of a performance hit for doing that as you are often operating on both parts of the double with the same instruction.

Do you know if there's language support for that? Are there obscure gcc options that make "long double" be quadruple precision floats?

Which language?

For C++, there's this: https://en.cppreference.com/w/cpp/types/floating-point

Re: How do computers calculate sine?

#58

Post by saagarjha »

TylerE wrote: post #53
saagarjha wrote: post #43

Earlier quoted context omitted.

This is not always a safe assumption (in certain scenarios floating point results being nondeterministic has the possibility to introduce bugs and security issues) and is also a kind of sad way to look at the world. The response to "I don't understand how this works" should not be to adopt an incorrect viewpoint, but to know the limitations of your understanding.

It’s not that I don’t understand, it’s that I do. Floats are inherently lossy representations. Yes, this means the more operations you perform on a float input, the fuzzier the value is.You ignore that harsh reality at your peril. If you find engineering rigor sad, I don’t know what to tell you.

"Floats are not deterministic" is not engineering rigor, it's just wrong. They are specified precisely by IEEE-754 in how they must behave and which operations are allowed to produce which results.

Re: How do computers calculate sine?

#59

Post by zokier »

cogman10 wrote: post #30
bnprks wrote: post #27

Earlier quoted context omitted.

Sadly even SSE vs. AVX is enough to often give different results, as SSE doesn't have support for fused multiply-add instructions which allow calculation of a*b + c with guaranteed correct rounding. Even though this should allow CPUs from 2013 and later to all use FMA, gcc/clang don't enable AVX by default for the x86-64 targets. And even if they did, results are only guaranteed identical if implementations have chos…

That's a bit of a different problem IMO. Barring someone doing a "check if AVX is available" check inside their code, binaries are generally compiled targeting either SSE or AVX and not both. You can reasonably expect that the same binary thrown against multiple architectures will have the same output. This, of course, doesn't apply if we are talking about a JIT. All bets are off if you are talking about javascript o…

> Barring someone doing a "check if AVX is available" check inside their code

Afaik that is exactly what glibc does internally

Re: How do computers calculate sine?

#60

Post by zokier »

enriquto wrote: post #55
cogman10 wrote: post #51

Earlier quoted context omitted.

The 80bit float? Not as far as I'm aware. However, it's fairly trivial to represent a 127bit float with 2 64bit floats. And with the nature of AVX/SSE, you don't really take much of a performance hit for doing that as you are often operating on both parts of the double with the same instruction.

Do you know if there's language support for that? Are there obscure gcc options that make "long double" be quadruple precision floats?

You can just use standard C _Float128 type https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
Post reply on HN