Thread: Can't hold numbers in variable.

Change %f to %.0f in your printf() call. Also, you might want to consider using a string instead of an integer to hold the data. Or use a larger integer type. If you #include <stdint.h> you should be able to declare a uint64_t type which creates an unsigned 64-bit integer that can easily hold a 12-digit number.

You shouldn't use a float, you should use a long. I believe on most systems longs can manage 12 digits. Anyway, if you wanted to keep the float, then format your %f identifiers to %.0f

*Edit* I dun got beaten to the punch. Curse you.

Longs are typically 32-bit nowadays on Windows-type machines. 32-bit integers can only handle up to 9 digits (10 digits if the first digit is less than 4). I'd strongly recommend using a string to hold the number instead. But if the data absolutely has to be in numeric format then it should be in a 64-bit integer instead of a float.

I managed 10.

It got pretty funky after that. Infact, it gets funky midway into 10 digits. I'm to lazy to find the max though. 32-bits in binary... you do the math. Somewhere in the fours as you said, I guess.

Code:

#include <stdio.h>

int main() {
    long foo = 1234567891;
    
    printf("%d", foo);
    
    return 0;
}

/* Output: 1234567891 */

Strings would be a good bet. I'm always hearing debates about 64-bit integers and processing speeds and stuff. I don't really know the details, but you got a few good programmers saying they're alright, so you can do either or I guess.

Actually, mine crapped out at the last bit. Maybe I'm doing this wrong though.

Code:

#include <stdio.h>
#include <math.h>

int main() {
    unsigned long foo = 0, count;  // I also tried just long foo
    
    for (count = 0; count < 32; count++) {
       foo += pow(2, count);
       printf("%d \n", foo);
       }
    
    return 0;
}

Output:

Code:

1
3
7
15
31
63
127
255
511
1023
2047
4095
8191
16383
32767
65535
131071
262143
524287
1048575
2097151
4194303
8388607
16777215
33554431
67108863
134217727
268435455
536870911
1073741823
2147483647
-1  // I guess the max should be 4294967294

I think it's undefined behavior, but:

Code:

itsme@itsme:~/C$ cat overflow.c
#include <stdio.h>
#include <stdint.h>

int main(void)
{
  printf("%lu\n", (unsigned long)-1);
  printf("%llu\n", (uint64_t)-1);

  return 0;
}

Code:

itsme@itsme:~/C$ ./overflow
4294967295
18446744073709551615
itsme@itsme:~/C$

That's 4,294,967,296 unique values for the 32-bit one. 0 through 4,294,967,295. 64-bit integers hold quite a bit more

Mmmmkay, I just compiled that code and got this:

Code:

4294967295
4294967295

So maybe my computer/compiler/program doesn't like uint64_t
...then again, maybe I just screwed it up.

Originally Posted by SlyMaelstrom

Mmmmkay, I just compiled that code and got this:

Code:

4294967295
4294967295

So maybe my computer/compiler/program doesn't like uint64_t
...then again, maybe I just screwed it up.

Dev-C++? clicky

Code:

#include <stdio.h>
#include <stdint.h>

int main(void)
{
  printf("%lu\n", (unsigned long)-1);
  printf("%I64u\n", (uint64_t)-1);

  return 0;
}

64-bit would be ok if you had a 64-bit CPU. However since XP is currently not 64-bit on a 32-bit system and in fact cannot be pure 64-bit - using 64 bits will incur a speed hit. Remember the days when all we had was 16 bits? Say for instance we had a large value and needed to store it? You would use AX and another register to represent the value. Then you would use an algo to combine the values into a final result to be displayed. For an explanation of this algo I recommend reading The Art of Assembly Language by Randall Hyde. The same process must be used to use a 64-bit value on a 32-bit CPU. Now I'm sure that most, if not all, CPUs by now are internally 64-bit but as of yet Intel has not exposed any standard 64-bit registers external to the CPU, excluding MMX(x) and SSE(x).

So a 64-bit value must be stored in two 32-bit registers to be used by the CPU. You also cannot load a 64-bit value from memory into the CPU even in MMX. In fact MMX specifically prohibits this and so to me it's functionality and usefuleness in certain situations is quite limited. You can store a 64-bit value into memory by a combination of opcodes but again this requires cycles. Probably won't notice the difference given the insane clock speeds we have today but the underlying mechanism is using two 32-bit values to represent one 64-bit value.

Using the floating point processor solely for the purpose of gaining digits is not recommended by Intel. Their are a lot of problems with this approach. The FPU is intended to be used with floating point values only and not integral values. The floating point architecture is designed to operate efficiently on floats and the CPU will operate efficiently on integral values. Using an FPU to simply gain digits might cause the underlying assembly code to leave the FPU in an unpredictable state. There is a lot more going on in the FPU opcodes that you might think and it operates on a totally different principle. Check the Intel documentation concerning the math-coprocessor functions and operations. You will be quite surprised by what you find. You may also want to check your compiler documentation to see if and when it issues a reset to the FPU. The FPU state and registers must be reset under certain conditions to ensure accuracy and proper calculation of values. If this state become invalid then all data output from the FPU will also be invalid. Several combinations of opcodes and/or operations whether they be in C/C++ or in pure asm can and will leave the FPU in an invalid state. It is also possible with your setup that you might encounter a NaN which is essentially a not a number flag. There are values for which no known binary representation exists in the FPU format. Compensations for this will result in a loss of precision and could alter your final value even though you did not intend for it to do this.


So, in short, use a string. It is more suited to what you want to do. Use the FPU correctly and your code will get along quite nicely with it.