Re: Strange products upon running code...
 

While you're certainly entitled to your opinion, you should be aware that it is based on a guess and could easily have little to do with reality. With the tools we're given, floating point operations on a PIC are very expensive.
On the other hand, a floating-point library itself eats up a lot of program space. If you just want to eliminate the trig lookup table, using a CORDIC algorithm is probably the most appropriate tactic.

Re: Strange products upon running code...
 

I think we have different definitions of fast: mine is that it works within the time allowed. It may not be the fastest it could possibly be, but it's good enough.

I had forgotten that the floating point library takes up space - thanks for pointing that out.

The solution of using floats is still far more elegant and easy to understand than some integer hacks and a look up table, and I feel that it's more important to have code that's easy to understand and maintain than it is to optimize something that (at least for me), doesn't need optimization. It's the same reason that I use std::string rather than C strings, even though there is a small performance penalty.

Re: Strange products upon running code...
 

One thing I'd like to point out that there is a strong tendency to apply continuous math to a digital or discrete system. In other words when dealing with microcontrolers without hardware floating point processors allot of algorithms can be better solved with matrix math. State machines are an example when the inputs just have a binary state. With analog to digital conversion there are a finite set of integer inputs. A solution matrix (table) can be built of the desired outputs. Usually its faster to parse the matrix and find the desired outputs than it is to use continuous math. It's not bad with 1 input and 1 output. As the number of inputs and outputs increase it gets harder but, still can be more productive than dealing with solving complex equations on a microcontroller.