1. easy arithmetic question

Code:
```#include <stdio.h>
#include <math.h>

int main()
{
int i = 1073741824ul;
int total = i + i;
printf("%d", total);
return 0;
}```
Output: -2147483648

The real answer is suppose to be: 2147483648

why does C return a negative number?

2. I doubt that the real answer is supposed to be 2147483648, since that is not a valid int on any system I'm aware of (on my sizeof(int)==4 system, INT_MIN is -2147483648 and INT_MAX is 2147483647). I'm guessing that someone simply dropped a negative sign when they told you what the "right" answer was (or you did, if you did the modular arithmetic yourself).

3. Originally Posted by tabstop
I doubt that the real answer is supposed to be 2147483648, since that is not a valid int on any system I'm aware of (on my sizeof(int)==4 system, INT_MIN is -2147483648 and INT_MAX is 2147483647). I'm guessing that someone simply dropped a negative sign when they told you what the "right" answer was (or you did, if you did the modular arithmetic yourself).
..."right" meaning arithmetically right...

In python: 1073741824 * 2 = 2147483647 this is arithmetically correct.

Why does the above C program even compile? Let alone produce that output?

4. Why wouldn't it compile?

And if you want a "ul" number, why not make i "unsigned long i" instead of "int i"? Also note that you don't print unsigned numbers with %d, but with %u (%lu for unsigned long).

5. Originally Posted by brooksbp
why does C return a negative number?
Since this hasn't been answered yet. It's due to wraparound. When an variable in C gets larger than the maximum +ve value it can hold, you will overflow into the sign bit and set it. When the sign bit is set, the number is considered -ve and hence you see a -ve answer. You won't have that problem if you a) use a bigger variable like a long long b) in this case if you make the total unsigned.

QuantumPete

6. Technically
Code:
```#include <stdio.h>
#include <math.h>

int main()
{
int i = 1073741824ul;
int total = i + i;
printf("&#37;u", total);
return 0;
}```
Should yield the desired result despite the fact i would still hold a negative value.

If something does not compile, typically your compiler throws back some sort of error or a vast list of warnings that it deemed fatal enough to not compile your code. Consult those.[/edit]

7. Originally Posted by brooksbp
In python: 1073741824 * 2 = 2147483647 this is arithmetically correct.
No it isn't. A simple logic check would tell ya that 4 * 2 isn't going to give you 7, or even more basic that an even * even isn't going to give you an odd.

The whole thing boils down to what the range of the storage is and what their overflow behavior is. C says that signed integer overflow is undefined. On your system a signed int is too small to hold that value.

8. Originally Posted by brooksbp
..."right" meaning arithmetically right...

Why does the above C program even compile? Let alone produce that output?
Because C has made the "choice" of mapping closely to the computer hardware. In the lowest level of your computer, the CPU performs "wraparound" (as mentioned above) when values don't fit in its registers. A computer language could take this into account (specifically if it targeted a virtual machine, as do Java or the .NET languages), but this is at a (significant) performance penalty.

When using MMX/SSE instructions, x86 CPUs also have a "saturation" mode in arithmetic (i.e. when the result of a value would be larger than the maximum value representable by the type, it would clip to that maximum value). This is really nice for certain types of calculations (in image processing, for instance). However, C does not offer a mapping to this mode.

Computer Programming: An Introduction for the Scientifically Inclined