And actually, multiplication with floating point is fast even without an FPU.
I don't think that's true, the overheads of unpacking/repacking, exponent, normalization and exception processing of floating-point numbers mean that software emulation is perhaps an order of magnitude slower than with FPU hardware. This is why on integer-only hardware fixed-point formats are so often used to avoid most of this overhead - especially in signal processing where the range of values is well defined.
It is usually the case that (with a hardware multiply and no FPU) multiplication is faster than addition in floating-point - but that's because the house-keeping for addition is so complex...
I've struggled with fixed point approximations on the BASIC Stamp, and so much depends on careful understanding of a limited range and scaling to keep within bounds, and the results (using ** and * operators) are opaque, not pretty.
The nice polynomials can involve small differences between large terms. For example, the polynomial for sin at 7.2 digits (about 28 bits) takes 5 coefficients each with 12 significant figures (about 40 bits). One nice thing about CORDIC is a 28 bit result a 32 bit CPU without resorting to higher precision.
Here is my code mentioned above, it is not as complete as I thought, I did the circular functions and started the linear but had not touched the hyperbolic. I was still struggling to decide on number representations if I remember correctly.
The main thing to notice is that there is a common algorithm for each of the function types so the code is fairly compact.
Kye,
I have a general question about numbers and range.
In the great circle there is a multiplication of many sin/cos values. The sin/cos from the cordic are in the range +-$4000_0000, so a multiplication will likely cause an overflow.
How can the numbers be still right?
When I had to multiply sin/cos values I formatted the trig results to 32 bit, and used multiply high. I cannot understand the math behind this solution.
Thanks in advance,
Massimo
Kye,
Thanks for this gem!! I have used Taylor expansion to get Sin/Cos to 32 floating-point resolution, but I look forward to doing some integer math now.
@Max72 - Its untested... So, it probably doesn't work. The cordic stuff near the bottom does work however, but the distance calculation may not. But, the formula I used is the haversin so I believe it should get the correct result. Probably will overflow. When I get to testing I'll release a tested one.
Comments
I don't think that's true, the overheads of unpacking/repacking, exponent, normalization and exception processing of floating-point numbers mean that software emulation is perhaps an order of magnitude slower than with FPU hardware. This is why on integer-only hardware fixed-point formats are so often used to avoid most of this overhead - especially in signal processing where the range of values is well defined.
It is usually the case that (with a hardware multiply and no FPU) multiplication is faster than addition in floating-point - but that's because the house-keeping for addition is so complex...
The nice polynomials can involve small differences between large terms. For example, the polynomial for sin at 7.2 digits (about 28 bits) takes 5 coefficients each with 12 significant figures (about 40 bits). One nice thing about CORDIC is a 28 bit result a 32 bit CPU without resorting to higher precision.
The main thing to notice is that there is a common algorithm for each of the function types so the code is fairly compact.
Cheers,
Graham
cordicobject.spin
I have a general question about numbers and range.
In the great circle there is a multiplication of many sin/cos values. The sin/cos from the cordic are in the range +-$4000_0000, so a multiplication will likely cause an overflow.
How can the numbers be still right?
When I had to multiply sin/cos values I formatted the trig results to 32 bit, and used multiply high. I cannot understand the math behind this solution.
Thanks in advance,
Massimo
Thanks for this gem!! I have used Taylor expansion to get Sin/Cos to 32 floating-point resolution, but I look forward to doing some integer math now.