i need your help

[HAMZAZAYYAD]

hi all
can i insert a formula into pic micro
y=0.1256+0.768x
x=variable(regester value)
i use 16f877a and assembly language

thank you

 

[Oznog]

Yes and no. You must use integer math and you can do this by multiplying the numbers to make them into integers.

y=0.1256+0.768x

Could be:
y=126+768*x;
y is a 16 bit number, and 768*x must be calculated with a 16 bit operation.

Note we rounded 125.6 to 126. This may or may not be acceptable depending on your accuracy requirements. Perhaps instead of multiplying everything by 1000 you could use 10000, but as with any math you would need to be sure 7680*x would not overflow the max value that could be stored by a 16 bit integer.

 

[Nigel Goodwin]

It would be fairly uncommon to want to do this?, there's usually a far simpler way if you give it some thought. You can do floating point maths (MicroChip have routines for it), but it's slow and inaccurate (as with all normal processors) - it's easier, faster, smaller, and more accurate to use interger maths and scale the values.

But better still to avoid it altogether - but this obviously depends on EXACTLY what you're trying to do?.

 

[Pommie]

It would be fairly uncommon to want to do this?, there's usually a far simpler way if you give it some thought. You can do floating point maths (MicroChip have routines for it), but it's slow and inaccurate (as with all normal processors) - it's easier, faster, smaller, and more accurate to use interger maths and scale the values.

But better still to avoid it altogether - but this obviously depends on EXACTLY what you're trying to do?.

Nigel, why do you say that floating point is slow and inaccurate. Floating point has n bits that are multiplied (or whatever other operand) together to produce a very accurate (or at least as accurate as the best case fixed point) new number. You then add together the powers to get a new power. Shift it a few times and bingo, a new floating point number. Slightly slower, far more accurate.

Mike.

 

[Nigel Goodwin]

Nigel, why do you say that floating point is slow and inaccurate. Floating point has n bits that are multiplied (or whatever other operand) together to produce a very accurate (or at least as accurate as the best case fixed point) new number. You then add together the powers to get a new power. Shift it a few times and bingo, a new floating point number. Slightly slower, far more accurate.

Because floating point IS slow and inaccurate, no matter what the processor!.

Perhaps you've noticed that Excel (and other spreadsheets) don't use floating point for calculations involving money?, simply because it's not accurate. By definition, floating point numbers are rounded, and this loses accuracy - if you scale the values up to be integers, and then do the sums, it's not only FAR faster, but perfectly accurate (as long as you don't over or under flow). You then simply insert the decimal point back in the correct place at the end.

I presume you remember electricity bills in the past for values like £63.247586976348566 - when it should have been £63.25 or £63.24, depending on the rounding errors involved. This was back when programmers often used floating point maths for money!.

 

[mstechca]

I think that floating point is less accurate as well. To me, it depends on how many numbers you are dealing with to the right of the decimal place. The more numbers, potentially the slower, and the worse the result. In fact, an awful lot of rounding can occur.

Try this on a cheap 8-digit calculator:

0.0000001 divided by 10000000

You definitely will not get a meaningful answer, because computers only understand bits which is basically a state of power (on or off). and these bits are programmed to produce unique groups of bits, and with thought, numbers can be obtained.

 

[Pommie]

Perhaps you've noticed that Excel (and other spreadsheets) don't use floating point for calculations involving money?, simply because it's not accurate. By definition, floating point numbers are rounded, and this loses accuracy - if you scale the values up to be integers, and then do the sums, it's not only FAR faster, but perfectly accurate (as long as you don't over or under flow). You then simply insert the decimal point back in the correct place at the end.

You have just described floating point maths.
The definition of floating point multiply is,
Scale the value until a 1 is in the top bit. I.E. make it the biggest integer you can.
Keep a count of how far you shifted the value.
Do the same for the other value.
Multiply the 2 operands.
Add the powers.
You now have the most accurate answer you can get without going to a larger bit multiply.

You are correct in that if you use 64 bit floating point numbers then it is overkill for most applications but if you use floating point maths that is of the accuracy you require then it is normally more accurate and only slightly slower. It will however be faster if you don't know the size of your operands first.

Mike.

 

[Pommie]

A quick question,

What is 30 divided by a half plus 10.

Mike
P.S. not aimed at anyone, just to show that we all have fixed ideas when it comes to maths.

 

[Nigel Goodwin]

A quick question,

What is 30 divided by a half plus 10.

Mike
P.S. not aimed at anyone, just to show that we all have fixed ideas when it comes to maths.

Might regret this? :lol: but I'd say 70

 

[Pommie]

Give that man a cigar.

Do you now accept the floating point bit?

Mike.

 

[Nigel Goodwin]

Give that man a cigar.

Do you now accept the floating point bit?

Mike.

Not as such 8)

Floating point routines (like the ones at MicroChip, or in Excel, or C++), are general purpose, and because of that easily give errors. Doing it for a specific example using scaled integers prevents the errors (and is lots faster).

Have a look at https://www.electro-tech-online.com/custompdfs/2006/02/00575.pdf.

 

[Pommie]

You stated earlier that excel doesn't use floating point. I will argue that excel always uses floating point. If you check the help file, you will discover that at about a kings ransom, monetary values are no longer guaranteed.

Floating point routines are at least as accurate as the best fixed bit maths routines that uses the same number of mantissa bits.

It took me a while until I realised that shifting integers until you get the best accuracy is a long winded way of doing floating point.

Mike.

 

[Nigel Goodwin]

You stated earlier that excel doesn't use floating point. I will argue that excel always uses floating point. If you check the help file, you will discover that at about a kings ransom, monetary values are no longer guaranteed.

"No longer guaranteed" - which presumably means it previously was?, however I see that as no reason to suspect the use of floating point maths for monetary values. It's more likely just a 'get out clause' in case of the usual bugs from MicroChip?.

Floating point routines are at least as accurate as the best fixed bit maths routines that uses the same number of mantissa bits.

Sadly not true!.

It took me a while until I realised that shifting integers until you get the best accuracy is a long winded way of doing floating point.

It probably took you so long because it's NOT! - shifted integer routines work on integer numbers, floating point routines don't. They convert the numbers to scientific notation (mantissa and exponent), where the exponents have ONE digit before the decimal point, and all other digits are after the decimal point. So the actual routine works with non-integer numbers, complete with their well known inaccuracies.

If you check the MicroChip floating point application notes, both the one I posted the link to previously and the other dealing with higher functions, they acknowledge their potential problems.

 

[Pommie]

It probably took you so long because it's NOT! - shifted integer routines work on integer numbers, floating point routines don't. They convert the numbers to scientific notation (mantissa and exponent), where the exponents have ONE digit before the decimal point, and all other digits are after the decimal point. So the actual routine works with non-integer numbers, complete with their well known inaccuracies.

Floating point routines do work on integers.
FP numbers don't have to have any digits before the decimal point.
Maybe you can explain what the mantissa is if it is not an integer?

Let's try an example using 16E8 notation - 16 bit mantissa and 8 bit exponent.

Lets do 12345 * PI
PI = 11001001 00010000 E2
12345 = 11000000 11100100 E14

Note that the mantissa is simply the original number converted to an integer and the exponent is a count of how far from the right the decimal place should be. If you don't believe me then try converting the binary representation of PI to decimal and divide by 16384 (2^16/2^2).

Multiply the two mantissas together to get 10010111 01111111
Add the exponents to get 16
As the decimal point starts before the answer and needs to be shifted 16 places right then the answer is simply the mantissa converted to decimal - 38783. (excel gives the answer as 38782.96131)

This can even be done with 8 bit numbers. Obviously with greater error.
PI = 11001001 E2
12345 = 11000000 E14

Answer = 10010111 E16
Decimal = 38656

Or with bigger numbers.
PI = 11001001 00010000 E2
123450 = 11110001 00011101 E17
Multiply the two mantissas together to get 10111101 01011110
Add the exponents to get 19
Shift it the 19 places required = 101 11101010 11110000
Convert to decimal to get 387824.

Note, the inaccuracies are caused by converting the original value into an integer. Also, there is not a more accurate way to do this with 16*16 multiply.

Mike.
Edit, clarification.

 

[i_build_stuff]

All a float is is a signed integer with another byte or so telling the FPU where to put the point (scientific notation applied to binary). The % accuracy of floating point is always the same, barring overflow / underflow, as there are always the same number of bits describing the mantissa.

For example, the IEEE 754 "single" gives a 23 bit (effectively 24, since the MSB is always 1) mantissa--this means that the real number is always within (1/16,777,216) * the stored number.

 

[Pommie]

The point I was trying to get across with the above post is that scaling values in order to get them to fit in a 16 bit integer, so you can use integer maths, is doing floating point manually.

Mike.