# Decimal point representation

Discussion in 'Programmer's Corner' started by harry99932, Jul 10, 2011.

1. ### harry99932 Thread Starter Member

Dec 30, 2010
38
2
Hi guys,
Wonder if anyone can help me ive been working on my assembly routines for mid range pics but im getting a bit stuck with representing and working with decimal points, i,e multiply by 6.345 the only way i can think of getting around it is by shifting the multiplied number left of the decimal point enough places to bring the multiplier into whole numbers i.e to make 6.345 into 6345 then shift the result back down again.
I cant find a great amount of basic info on this, is this a reasonable way to go about the task or not?

Thanks a lot,
Harry

2. ### MrChips Moderator

Oct 2, 2009
14,278
4,195
Yes. I do this all the time.

But why multiply by 100 or 1000, why not 256?

There are many tricks you can pull. You can limit yourself at the most to integer multiplication and not have to do divisions. Keep in mind that it is a simple task to divide or multiply by 256 or 65536.

For example, if you want to multiply by 12.34, then multiply by 3159 instead and then divide by 256.
Or, if you want to divide by 12.34, then multiply by 5311 and divide by 65536.

I can also show you easy ways to do N-point averaging. The list goes on and on... maybe I should write a chapter on integer arithmetic tricks...

Last edited: Jul 10, 2011
3. ### nigelwright7557 Distinguished Member

May 10, 2008
508
72
Why not just use C and floating point numbers ?

Dec 23, 2010
200
6

5. ### MrChips Moderator

Oct 2, 2009
14,278
4,195
Because it is slow and takes a lot of memory. Have you ever tried calculating dewpoint with 2K of memory space?
Besides, if you want to learn the most out of MCUs and programming, use assembler.

Last edited: Jul 11, 2011
6. ### harry99932 Thread Starter Member

Dec 30, 2010
38
2
brilliant thankyou mr chips im still getting my head around these sort of tricks maths isnt a huge strong point of mine and throwing what a pic can and cant do into the mix makes life a bit more interesting! from a quick look im guessing dividing a 16 bit number by 256 leaves the most significant byte as the result?

Nigel- because im a glutton for punishment and c is for girls

7. ### MrChips Moderator

Oct 2, 2009
14,278
4,195
You are correct. Dividing by 256 means the hi-byte is the result.
Of course, I am leaving out a few details so that you can learn by yourself.
For example, make sure that you have enough room for the maximum number. 16-bit positive integers max is 65535.
If you want to do rounding, just add half of the divisor before dividing. For example, before using the hi-byte, add 128 to the 16-bit result. In other words, if the lo-byte is negative, add 1 to the hi-byte when dividing by 256. (Just some the things to think about.)

Of course the MCU model can make a big difference. I am a big fan of HC11 which makes 16-bit and 32-bit arithmetic fairly easy. Let's see the PIC do that!

8. ### harry99932 Thread Starter Member

Dec 30, 2010
38
2
oooh youve just given me a mathematical epipheny!! no more skirting around the problems using opamps to do the maths thank you very much and you definatley should do a article on the matter!

9. ### ErnieM AAC Fanatic!

Apr 24, 2011
7,906
1,789
Bingo! Assuming you are using the amp as gain between sensor and an A2D you want to drive that input with the largest signal you can expect. That gives you the best resolution.

"Largest" signal also means leaving a little headroom for something unexpected, component tolerances, and other yuckie stuff you don't foresee.

Inside the micro you are free to use any scaling that makes the math as simple as possible. If you have an 8 or 10 or even 12 bit conversion value it makes little sense to go to floating point math unless you have an oodle of room to drop it in, but that is rare.

Even in a 32 bit PIC (128K ROM, 32K RAM) I am using I do most of the calculations using simple integer values.