Floating Point arithmetic does not work?

Heater.

From time to time a little debate starts up here about the use of Floating Point arithmetic on the Propeller. Perhaps someone someone posts a question on if or how floating point math can be done on the Propeller (Or indeed any other MCU).

Often such questions arise because someone simply cannot fathom how to do something simple like add, subtract, multiply, divide non-integer number numbers.

Or they just can't be bothering to worry about over flows and under flows.

Or they might be trying something a bit harder involving trig functions.or logs.

Often some bright sparks (Like me:)) Jumps up and proclaims "If you think you need floating point to solve your problem then you don't understand your problem". That being what a boss of mine used to preach back in the 1980's to us young software guys when we got stuck on problems on minicomputers with no float support and no time to let the compiler do it in software.

Others will chime in and point out that taking the easy way out with floating point is quite OK if you have time and space available.

I'm actually happy to "float or not" depending on the situation as long as you are aware of the possible pitfalls.

Anyway to the point: The weather forecasting community has recently discovered they cannot trust their weather models to produce the same results from the same input using the same software when run on different super computers. Basically down to the way floating point works on different machines.

See here: http://journals.ametsoc.org/doi/abs/10.1175/MWR-D-12-00352.1

In light of that result I'm upgrading my bosses statement:

"If you think you need floating point to solve you problem then you don't understand your problem. If you find you do need floating point to solve your problem then you definitely no longer understand your problem"

P.S. This property of weather models to give very different results in the face of very small errors in input has been known since the 1970's It's what gave rise to chaos theory. If you think of the output of every iteration of such a model as an input to the next iteration then these rounding errors they are reporting are the same effect and I don't see why anyone is surprised.

Mike Green

I still disagree with your boss's upgraded statement. If you think you need floating point to solve your problem, you may not understand it well enough. Take the time to analyze your problem, particularly with regards to numerical accuracy and assure yourself that you won't be getting meaningless numbers out under some circumstances due to the finite accuracy involved either in floating point or even fixed point calculations. As you've implied, floating point is often used as the "poor man's fix" for a lack of understanding of the problem and its calculations as opposed to being another tool in the toolbox of good program design and implementation.

Heater.

I'm with you there Mike.

However perhaps my upgraded bosses statement is not forceful enough.

I am going to assume that these weather forecasting models have been put together of a long period of time by some of the finest minds in mathematics and computer science we have. However the discrepancies they found when running the same code with the same inputs on different machines seems to be a newsworthy surprise to them. Seems they did not understand that this might happen.

So my stronger statement might be:

"If you think you need floating point to solve you problem then you don't understand your problem. If you find you do need floating point to solve your problem then your problem is no longer understandable".


Aside: One of the most reported bugs in JavaScript run times is along the lines of "0.1 + 0.2 == 0.3 yields false." Which clearly shows that those who jump into floating point without understanding what it is can get very confused and surprised and can easily create broken software.

Heater.

Of course I might be misrepresenting my boss. He probably did not mean that statement in such a general way. Rather he knew the problems we were having with those machines and that application (3D radar signal processing) and he knew they could be dealt with. Also that using floating point would make our code unacceptably slow in that environment. He was a clever guy.

skylight

With the project i've been working on I couldn't see any way around without using the floating point math object, converting 0-255 into 0 to 100% I needed to divide 2.55 into a result.

Mike Green

That one's easy. You multiply by 100, then divide by 255. If the range of values doesn't permit this because of overflow, divide by 255, then multiply by 100. You can also remove the common factor of 5 and multiply first by 20, then divide by 51.

skylight

Mike, you've done it again! my old grey matter just didn't think that way, I think you may have saved me a lot of memory space, Thanks

Martin_H

For my robot arm I use trigonometry to do inverse kinematics. With PBasic's support for integer trigonometry functions you could in theory do integer IK with the help of an external servo controller. But neither Spin nor C have built in support for integer trig functions, and the one library I saw was in Spin and slower than F32. So floating point has a place because of this.

localroger

If you're doing kinematics, it's more likely that you want cartesian-polar coordinate tarnsforms than actual trig functions. The ROM sine tabl is very good for that to a resolution adequate for most robotic tasks. Using an angular measure of 1/65536 full circle polar operations operate much more naturally than they do with floating point, due to the circular nature of 2's complement math.

Martin_H

I recall trying that but needing atan which put the kibosh on things. Also, F32 is in PASM so it was faster than integer Spin code for the sine lookup.

Duane C. Johnson

skylight wrote: »

With the project i've been working on I couldn't see any way around without using the floating point math object, converting 0-255 into 0 to 100% I needed to divide 2.55 into a result.

This is probably not correct.
I bet it should be:
0-256 into 0 to 100% where 256 doesn't happen therefore 100% is never happens.
So the resultant math is:
* 25 / 64

Duane J

skylight

Hi Duane, I was converting a dmx value to percentage value the byte value range is 0-255