## Long mathematics problem

8 posts / 0 new
Author
Message

I'm pulling my hair out trying to figure this out:

```  long a=625;
b=(F_CPU * a);

c=(F_CPU * a) / 2000000;
d=(1410065408L) / 2000000L);
e=(long)(((long)(((long)F_CPU) * ((long)625)))) / 2000000L;
```

gives

```a=625
b=1410065408
c=5000
d=705
e=705
```

I understand that if I don't declare it a long ahead of time, it will wrap. But here, even in the most extreme case, it does something weird! The worst part is, 705 isn't anything special in hex (0x2C1), so I am truly comfuzzled.

Anyone can give a hand and point out the obvious to me?

Edit: Typing in frustration, I CLEARLY didn't give enough information.

c is the only correct answer. F_CPU=16000000, so the problem reduces to 625*8, or in other words 5000.

Last Edited: Fri. Mar 19, 2010 - 02:37 PM

You forgot to tell us what F_CPU is actually defined as? (and in particular is it defined with a UL suffix?)

Quote:

You forgot to tell us what F_CPU is actually defined as? (and in particular is it defined with a UL suffix?)

Quote:

b=(F_CPU * a);

Quote:

a=625
b=1410065408

...and according to my calculator 1410065408/625 is not an integer. ???

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Quote:

...and according to my calculator 1410065408/625 is not an integer.

Mine too - which I took to be part of the problem - hence the need to know what F_CPU was SUPPOSED to have been.

Sorry, doy did I not give enough information. As I've (now) included in the original post, F_CPU is 16000000 and (c) is the correct answer. Although how you guys were supposed to guess that is beyond me...

Which in retrospect shows me that the compiler is being smarter than I am and is simplifying F_CPU/2000000 already before the buffer overflow.

I don't even get what your question was in the first place, if you already knew F_CPU.

Just to be clear do you have:

`#define F_CPU 16000000`

or

`#define F_CPU 16000000UL`