Floating point - please enlighten me!

[HankMcSpank]

Ok, I came into PIC not knowing much at all (still don't - but I can sit transfixed at example programs like an lethargic lizard warming its blood on a rock for hours!!), so it should be of no surprise I don't know much about floating point....but it's becoming rapidly apparent that most of the stuff I've an interest in erhmm kinda needs it - now I know there are a few tips & tricks/workarounds, but just so I'm clear what the issue is....

Is poor floating point a limitation .....

a) of PBP

or

b) the PIC range of processorors themselves?

If the former (a)....and you were faced with doing a lot of stuff where floating point would be a blessing - what path would you take?!!!

If the latter (b)....what's a good option to explore with respect to other variants?

Many thanks.

[Acetronics2]

Is poor floating point a limitation .....

a) of PBP

or

b) the PIC range of processorors themselves?
.

Hi, Hank

Floating point calculations need room and therefore time ... that's one sure point.

We have to admit ... aheum ... Calculations are not something PBP has particularly developped, ( do not strike on the head ...) as it's most of time to be preferably done via .asm ( did you see PBP floating point support on melab's site ??? )

Also remember PBP only recently introduced the 32 bits calculations with the 18F series, ...

Well, how to tell it ... it's not the best compiler for mathematical calculations ... and , Honestly ...

you should turn to more powerful chips ( did I say 16 or 32 bits ??? ) if you really want to calculate in such a way ...

Is it really necessary ??? ... Always ze good question ...

Alain

[mackrackit]

I have never used them, maybe they are OK.
http://www.awce.com/compare.htm

[Jerson]

Floating point is a limitation of the PBP compiler. Nothing to do with PICs in general. You can use a floating point library and get by, but the question is do you really really need it? Most times, you will be using compile time fractions which can be broken down into simple integer operations.

The most general work around is to find an equivalent fraction that can be represented in integer math. For example, if you need to do pi x d, you can do

(d * 22)/7 to get a value in integers
or
(d*220)/7 to get a value with 1 decimal place. Only now, you need to place the decimal point while displaying the value.

I use an utility called MISCEL from http://www.miscel.dk which allows you to compute integer equivalents of a fraction in various word sizes.

The liabilities of Floating Point
1 - Bulky code
2 - Very time intensive computing A single operation can take approx 2-300mS
3 - PBP does not support it

Of course, even the long support needs you to migrate your code to an 18F series

[mark30504]

Hello

Trying to use some floating point.

PIC16f886

I have tried it several ways by no real luck

I have an number that need to be mulitiplied by .2235 to get corrrect result

Result can be rounded back to integer

For example

number = 250 usually a varriable but have tried it this way for testing

I have tried

number * .2235 ( won't compile)

and

number * (1000/4474) Compiles but result is zero

Answer should be somewhere around 55.8

I am not sure if the math is not working or I can not just see the number

That is; once the number is computed it is sent out RS232, it would work best if it was a whole number between 0-255 at time of sending
in this case 56 would be great.

Not sure where the problem lies.

Should the math be working ?

Is so how do I round to a whole number ?

thanks

Mark

I have never used them, maybe they are OK.
http://www.awce.com/compare.htm

[pedja089]

Try to use DIV32.

Dummy VAR WORD
Number VAR BYTE
Result VAR BYTE
Dummy = Number * 1000
Result=DIV32 4474

[ronsimpson]

Not using a compiler, using a calculator.
Input=250 and you want about 1/4 of that.
250*.2235=55.875
With out using a decimal point!
250*223/1000=55.75 (I did not use 2235/10000)
If the input will fit into a byte and 223 fits into a byte. Then (byte * byte)=word and then word/1000=55.
If you need a input like 350 which is a word and/or you want to use 2235/10000 then you will need to do word*word and word**word to get two words or 32 bits. You might also look at word*/word to get 16 bits out of the middle of the 32 bits.

[mark30504]

Try to use DIV32.

Dummy VAR WORD
Number VAR BYTE
Result VAR BYTE
Dummy = Number * 1000
Result=DIV32 4474

Make sure I have this right.

By defineing Result at a byte, this will round the result to byte lenght ?

Lets say I need a decimal like .0004
Would I need several lines of code or can I just use

Dec1 VAR WORD
Result VAR BYTE
Something VAR WORD

Dec1=1/2500 'this should be .0004 ' will this work ? or need DIV32
Result = Something * Dec1 ' something being between 0 and 500

Result is now rounded ?

Do I alway need a DIV32 when a want a decimal result ?

[ScaleRobotics]

What everyone else said.

Most C languages for PIC18 devices let you do 32 bit floats. So it is not that PICs can't do it. But these do bloat your code, and slow your calculations. Same is true for the work arounds for PBP http://melabs.com/resources/fp.htm

The happy medium is to determine what you really need, vs what you want. The limitation of PBP just makes you think a little harder about how to work through a problem, and be the most efficient.

About 90% of the time a member has said they needed it, I have seen their need disproved by other members on the forum. I have even been there myself. I thought I needed it to calculate the distance between two gps waypoints. Then I found there was a work around. It turned out the cordic equation (in assembly) can be about 90 times faster than math(h).

Then there is N-bit math. I have not had a chance to use that yet, but they do look very cool. http://www.picbasic.co.uk/forum/cont...153-N-Bit_MATH

[ScaleRobotics]

You could simplify your math to make it easier for the Picbasic commands.

Since you have:

Temp = ADC10 * ((ADC10 * .00034) + .2235)

Why don't we get rid of that ugly .00034
1/.00034 = 2941

So we multiply both sides by 2941 ...

Temp * 2941 = ADC10 * (ADC10 + 657)

Then lets divide both sides by 2941 ...

Temp = (ADC * (ADC10 + 657)) / 2941

Then you can use div32

dummy = ADC10 * (ADC10 + 657)
Temp = div32 2941

And I think the result is close enough...