Math trick

Newzed

Here is a little math thing I discovered while working on my keyboard interface program.

Suppose you want to divide 19 by .44 – true answer is 43.18.

If you divide 1 by .44 the answer is 2.27.

Now, if you multiply 19 by 2.27 you get 43.13, which is within .12 percent of the true value.

Of course the Stamp can’t handle decimals per se, so you multiply the .44 by 100, so that .44 becomes= 44,which is what you enter as the divisor, n1.

So n1 = 44. Now if you write n1 = 10000/n1 you get 227. If n2 = 19 – the dividend - ·and you write:

n3 (result) = (n2*n1)

you get n3 = 227*19 = 4313

DEBUG "Result is: ", DEC n3/100, ".", DEC2 n3, cr

The debug screen will display:

Result is: 43.13

This may be well-known to most programmers, but it was new to me, so I thought I would share it.· Hope it helps something you are doing[noparse]:)[/noparse])

The program is attached.· Don't forget you are entering decimal numbers, so you have to hit Enter·after you have typed the numbers.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Do you have a Stamp Tester?

http://hometown.aol.com/newzed/index.html

MagicRuB

you know what, i never really thought about it much but I have a GPS project coming up and I'm sure I could use this method. I'll be working with some substantial decimal places (maybe 10 or more!) and was looking for ways to manage them. This is a foot in the right drection.

Thanks!

Ernie

When doing "little computer" work (embeded processors·like Stamps or PICs or such - NOT a PC) you should always pay close attention to *how* you perform math operations.

A couple years ago we were working on a level sensor that would have 8 bits resolution. To determine the reading we needed to perform a simple calculation : (A/B)*C·

A, B, and C were all 16 bit integer values. The result would be in the range of 0 to 255. A problem seemingly made for the integer math such as the Stamp does. But here comes trouble...·B was never less then A, A/B would always be less then 1. My boss was lamenting this, as we would need to do some fancy math to cover floating point math.

But... by first doing A*C, then dividing that result by B, the intermediate value was greater then 1 (lots greater in fact), so we could continue to use integer calculations and not introduce any floating point math.

The moral of the story is break the problem down to the smallest steps you can, and do them in the order that takes the least work.

Boris

IfErnie said...

When doing "little computer" work (embeded processors·like Stamps or PICs or such - NOT a PC) you should always pay close attention to *how* you perform math operations.

A couple years ago we were working on a level sensor that would have 8 bits resolution. To determine the reading we needed to perform a simple calculation : (A/B)*C·

A, B, and C were all 16 bit integer values. The result would be in the range of 0 to 255. A problem seemingly made for the integer math such as the Stamp does. But here comes trouble...·B was never less then A, A/B would always be less then 1. My boss was lamenting this, as we would need to do some fancy math to cover floating point math.

But... by first doing A*C, then dividing that result by B, the intermediate value was greater then 1 (lots greater in fact), so we could continue to use integer calculations and not introduce any floating point math.

The moral of the story is break the problem down to the smallest steps you can, and do them in the order that takes the least work.

If you are actually using a microcontroller for a serious project, why not use something more powerfull than basic stamp. There are plenty out there that can do floating point math...