On Wed, 2005-08-17 at 17:47 -0700, William Chops Westfield wrote:
> Ah.  It hadn't occurred to me that the dsPIC compiler would be
> one of the places where people would be beginning to use floating
> point in a big way, and that there might be flaws in that area.
> 
> On the smaller PICs, floating point is generally strongly avoided.
> 
> (indeed, FP is avoided on many embedded platforms for somewhat
> historic performance reasons.  Cisco's IOS is well over 20M
> of binary with no floating point to speak of...)

I'd say it's more then just performance reasons.

Floating point can be a very dangerous tool when doing things that
interact in the real world. Because of it's huge dynamic range it's very
easy for small errors to creep into calculations, eventually becoming
big errors.

A good example of this is something I encountered in my second year in
University.

During a mid term exam there was one question that I got stuck on. It
was a materials course, and there were huge ranges of numbers (numbers
of atoms, universal constants, etc.).

The question was quite simple, a few formulas and the answer should have
come out. But every time I did the calculations the result was obviously
wrong (obvious only if you understood the concepts behind the question).

On closer inspection I found that there was one area in the calculations
where a calculator ended up with an answer of zero. The reason being the
number was smaller then 1E-99, which most calculators out there simply
respond as "zero".

I did that portion of the calculation by hand and ended up with a
reasonable (and correct) answer. Most people got the wrong answer, and
complained to the Prof that the calculator indeed gave that answer.

The Prof came back simply with: don't blindly trust your calculator. I'm
convinced (although he never admitted it) that he purposely structured
that question in that way since he knew only people who TRULY understood
what all the formulas were for would get the correct answer. VERY
sneaky!

Similarly, in controller applications you can quickly get into trouble
if you do to many FP ops. If you don't properly check end cases you can
end up with inputs generating blatently wrong outputs. 

Of course, this is easily done with fixed point as well. The difference
is people are more careful with fixed point. They consider the range of
numbers, the end cases, and choose a fixed point position base on those
results.

With FP people tend to think "I can handle ANY range" and end up causing
very bad things to happen.

FP is good if you understand what it really is and plan your inputs
properly to deal with the pitfalls.

Personally I've never needed to use FP in an embedded project. I'm not
saying I NEVER will, but so far I haven't.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist