How do you linearise sin & cos?
Given power series representations, wouldn't you have to go quadratic or higher?
.... unless you chopped up the domain to smaller intervals then linearly approximated within each them ( from some pre-calculated mid-points say ). You'd have to use more & smaller intervals to retain accuracy when in the extremes ( high rate of change of slope ie. 2nd derivative ). Or some other method - a ( huge ) lookup table for instance?
Sounds like you need something akin to a 'register' command but one which forces, rather than just requests/advises, the compiler to keep it's fingers off.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
How do you linearise sin & cos?
Given power series representations, wouldn't you have to go quadratic or higher?
.... unless you chopped up the domain to smaller intervals then linearly approximated within each them ( from some pre-calculated mid-points say ). You'd have to use more & smaller intervals to retain accuracy when in the extremes ( high rate of change of slope ie. 2nd derivative ). Or some other method - a ( huge ) lookup table for instance?
This is what we do. The nice thing about the linear approximation is that we can perform the float -> int conversion (argument to table index) with just bit-operations in integer registers, which is pretty fast.
Quote:
Sounds like you need something akin to a 'register' command but one which forces, rather than just requests/advises, the compiler to keep it's fingers off.
Precisely. Or, even better, something that assigns priorities to the "register" hints.
How do you linearise sin &
)
How do you linearise sin & cos?
Given power series representations, wouldn't you have to go quadratic or higher?
.... unless you chopped up the domain to smaller intervals then linearly approximated within each them ( from some pre-calculated mid-points say ). You'd have to use more & smaller intervals to retain accuracy when in the extremes ( high rate of change of slope ie. 2nd derivative ). Or some other method - a ( huge ) lookup table for instance?
Sounds like you need something akin to a 'register' command but one which forces, rather than just requests/advises, the compiler to keep it's fingers off.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: How do you linearise
)
This is what we do. The nice thing about the linear approximation is that we can perform the float -> int conversion (argument to table index) with just bit-operations in integer registers, which is pretty fast.
Precisely. Or, even better, something that assigns priorities to the "register" hints.
BM
BM
You have made a huge amount
)
You have made a huge amount of progress in the way you deal with these code issues. Compliments.
4.25 is available. The usual
)
4.25 is available. The usual suspects will probably want to dig through the assembler code ...
BM
BM
RE: 4.25 is available. The
)
:-) Yup, will probably try to disassemle it tomorrow and try to find out why it doesn't seem to be faster.
RE: :-) Yup, will probably
)
Thank you! :)
Even on a weekend,, Bernd was
)
Even on a weekend,, Bernd was faster :-). See comments in the thread on the new app.