Earlier quoted context omitted.
Oh, wow, forgot about fp-contract. It says it is off in C by default, what about C++?
Read closer, it defaults to fast, not off
But the documentation does appear to be correct: https://godbolt.org/z/3bvP136oc
Crazy.
141–150 of 167 posts
Earlier quoted context omitted.
Oh, wow, forgot about fp-contract. It says it is off in C by default, what about C++?
Read closer, it defaults to fast, not off
But the documentation does appear to be correct: https://godbolt.org/z/3bvP136oc
Crazy.
It's much clearer if you read one of the source code of the libm. Plan 9: https://9p.io/sources/plan9/sys/src/libc/port/sin.c Freebsd: https://cgit.freebsd.org/src/tree/lib/msun/src/k_sin.c
sine is easy because the series is globally convergent and fast converging
It would also be extremely inaccurate. The x^n numerators grow very quickly and digits get lost because unlimited precision isn't available. Likewise, the n! denominators also grow rapidly. Then the series is alternating which means cancellation is happening for every added term. If you don't believe me try for x=10.
Earlier quoted context omitted.
I always wonder when hearing about these old optimizations why they aren't used in contemporary code. Wouldn't you want to squeeze every bit of performance even on modern hardware?
The "processor-memory performance gap" is a big reason why lookup tables aren't as clear of a win on modern hardware as they were on the SNES. If it takes two CPU cycles to read from RAM, a lookup table will basically always be faster than doing the math at runtime. If it takes fifty cycles (because, while your RAM may be faster, your CPU is a lot faster), and your processor has more advanced hardware that can do mor…
Earlier quoted context omitted.
Games targetting pre-Pentium PCs also used precomputed trig tables. Pentium was fast enough that it didn't matter as much. Just a few years later it was slower to read a trig precomputed table.
in other words, for those of us who remember, they used the equivalent of a slide rule
It's much clearer if you read one of the source code of the libm. Plan 9: https://9p.io/sources/plan9/sys/src/libc/port/sin.c Freebsd: https://cgit.freebsd.org/src/tree/lib/msun/src/k_sin.c
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...
So you can use sin(x) for various x to tell what you are running on. Maybe even in the browser?
Earlier quoted context omitted.
Oh, wow, forgot about fp-contract. It says it is off in C by default, what about C++?
Read closer, it defaults to fast, not off
In any case, according to the sibling comment, the default is 'fast' even in std-compliant mode in C++, which I find very surprising. I'm not very familiar with that corner of the standard, but it must be looser than the equivalent wording in the C standard.
sine is easy because the series is globally convergent and fast converging
It would also be extremely inaccurate. The x^n numerators grow very quickly and digits get lost because unlimited precision isn't available. Likewise, the n! denominators also grow rapidly. Then the series is alternating which means cancellation is happening for every added term. If you don't believe me try for x=10.
You wouldn't evaluate the terms naively from left-to-right.
x - x^3/3! + x^5/5! - ... = x * (1 - x^2/(2*3) * (1 - x^2/(4*5) * ... ) )
I just checked in python and you get a result that is around 1000*machine epsilon off. Not great, not terrible.
What’s the best way to calculate it by hand? I’m brushing up my math basics (I graduated CS while dodging the math requirements) and it frustrates me that in trig I need to remember values at all. The values such as sqrt(2)/2 make sense but how hard is it to calculate sin(5 degrees) by hand?