Strange products upon running code...

[neilsonster]

Hi, I have been attempting to write up lessons for next year's programmers to practice with. The last problem I made was to write a function that measures distance driven using encoders and display the data to the screen (I'm using a 2004 RC and MPLAB 7.00). In writing the code myself I ran into something strange.

Specifically the problem came up in calculating the wheel circumference. It was a very simple calculation and it spit out 0 for the circumference upon running the program. I then toyed around with just multiplying some random numbers and 15x30 came out to be -62 somehow. Here is the actual line of code that has caused me the trouble:

unsigned int WheelCirc = (2000 * WHEEL_RAD * PI) / 1000000;

In the above I was trying to stay away from using a float or double number obviously. I used 100 for WHEEL_RAD and 3142 for PI. The answer should be 628 but when I display the value to the terminal window it says 0. I then figured it must have somehow gotten a very small number (compared to 1 000 000) for (2000 * WHEEL_RAD * PI) to come up with 0, which doesn't make sense. Sure enough it ends up getting an answer of -24704 for the product of (2000 * WHEEL_RAD * PI), which would be the cause of the 0.

I then tried just writing out the numbers themselves and multiplying them for the WheelCirc variable and got the same thing. I tried it as a float rather than int and did 200*3.142 with no success (the answer came up as 17437). Has anyone else experienced this with the robot controller, MPLAB, or even in just any C program? Am I missing something (I'm hardly an expert at this)? If you haven't experienced this please give it a try and let me know if you get the same odd products. It's really cramping my style .

[sciguy125]

It looks like your variable is overflowing. Check how big an unsigned int is. I have a feeling that it's only 16 bit, which is only good for 65k. Your 2000 * WHEEL_RAD * PI is over 600 million.

sizeof(unsigned int) would give you the byte size of an unsigned int. I'd try it myself, but I don't have access to the compiler at the moment.

[Mike Betts]

Originally Posted by neilsonster

...
Here is the actual line of code that has caused me the trouble:

unsigned int WheelCirc = (2000 * WHEEL_RAD * PI) / 1000000;
...

Andrew,

Try:

unsigned int WheelCirc = ((long) WHEEL_RAD * 710) / 113;

Note that the above will still fail if WHEEL_RAD gets too large...

Mike

[neilsonster]

Originally Posted by Mike Betts

Andrew,

Try:

unsigned int WheelCirc = ((long) WHEEL_RAD * 710) / 113;

Note that the above will still fail if WHEEL_RAD gets too large...

Mike

That worked! Thanks!! *looks at your signature* I'll keep the 355/113 trick in mind . One question though, what happens when you put the (long) in front of WHEEL_RAD?

[Billfred]

Originally Posted by neilsonster

One question though, what happens when you put the (long) in front of WHEEL_RAD?

In essence, it forces the compiler to treat WHEEL_RAD like a long variable. (There was a post a few days ago in another thread that went a little deeper in depth, but I just woke up. >_<)

[EricS-Team180]

Originally Posted by Billfred

In essence, it forces the compiler to treat WHEEL_RAD like a long variable.

So right you are BillFred! (long) is a c "unary" operator called a cast. It forces or "coerces" a type conversion.

...if you can, take a peek at a c manual like K&Rs "The c programming Language" ... p 46-47

In your original equation,
unsigned int WheelCirc = (2000 * WHEEL_RAD * PI) / 1000000;
the type conversion takes place across assignments, that is, the value of the right side is converted to the type of the left side. An unsigned int in the pic is 16 bits, so you get to play with 0-65535. Unfortunately, your values take you way outside this range. But with Mikes eq:
unsigned int WheelCirc = ((long) WHEEL_RAD * 710) / 113;

the cast, (long) forces the right hand side calculations to be done in 32 bits.
Then, the assignment (the = sign) forces a type conversion to 16 bits.

The higher order bits get chopped when "shortening" - going from long to unsigned int, but the value of the right hand side, now fits 0-65535, so you get the answer you expect.

(I also like the 355/113 trick )

Eric

[Ryan M.]

Originally Posted by EricS-Team180

(I also like the 355/113 trick )

Hm... so explain this 355/113 thingy for me. I see a 113 on the bottom of the equation, but where's the 355 come in? (Besides his sig. )

Just curious.

[Manoel]

Originally Posted by Ryan M.

Hm... so explain this 355/113 thingy for me. I see a 113 on the bottom of the equation, but where's the 355 come in? (Besides his sig. )

Just curious.

710 is 2 * 355

[Mike Betts]

Back in the late 1970's and early 1980's (when I was in college) you learned a lot of tricks to make integer arithmetic work efficiently*.

Remember the Pi approximation by remembering the sequence 113355. Split into two different 3-digit integers and ask yourself if Pi is greater than or less than one? Voila! Pi = 355/113

Nowadays, there are tools to assist with computing ratios. I use Mathcad which will compute ratios and allow you to adjust for accuracy. As examples which are much harder to remember than Pi:

Sqrt(2) = 239/169 (or 577/408)
e = 193/71 (or 1264/465)

When applying any ratio in embedded systems, remember to multiply first and then divide and to watch for numeric overflows...

By the way, this numerical approximation was "discovered" over 2500 years ago (Google: Zu Chongzi or 113355)... All we had to do was to learn to apply it.

Mike

* The first computer I built from scratch had a Z80 (8-bit) processor running at 3.579545 MHz (NTSC color burst frequency). It took minutes to do any non-trivial math operations...

[Ryan M.]

Thanks, Mike.

[Hutch]

Now, I've got to ask, why aren't you just using a float? I know they are emulated; I know that should make them slow. But chances are, you won't have any speed issues - and in exchange, you remove a lot of the overflow problems.

[Mike Betts]

Originally Posted by Hutch

Now, I've got to ask, why aren't you just using a float? I know they are emulated; I know that should make them slow. But chances are, you won't have any speed issues - and in exchange, you remove a lot of the overflow problems.

Hutch,

Please read this...

Mike

[Greg McCoy]

Originally Posted by Mike Betts

Nowadays, there are tools to assist with computing ratios. I use Mathcad which will compute ratios and allow you to adjust for accuracy.

I just wanted to point out that the TI-89/92 graphing calculator family can also do this with the exact() function:

exact(3.14159265358, 0.00001) = 355/113

The second argument is the tolerance. I'm not sure what other models (if any) are capable of this.

[Alan Anderson]

Originally Posted by neilsonster

I then toyed around with just multiplying some random numbers and 15x30 came out to be -62 somehow.

You've already gotten a solution, so I'll just explain the underlying problem in more detail.

When dealing with constants, C compilers typically treat them as the smallest type that can hold a particular value. In this case, both 15 and 30 can fit in a signed char, which can range from 0 to 255. Arithmetic expressions are also evaluated using the smallest type possible, with any overflows in intermediate or final results simply being ignored.

When you multiply 15 by 30, you get the answer 450. When a C program does it, here's what happens.

15 decimal = 00001111 binary
30 decimal = 00011110 binary
product = 111000010 binary
Only eight bits of the product will fit in the result, giving 11000010 binary, which is -62 decimal in a signed char.

That's one of the things I dislike most about using C in general, and the Microchip compiler in particular. The programmer has to keep track of how large intermediate results might be, and deal with the potential overflows explicitly.