Can't hold numbers in variable.

This is a discussion on Can't hold numbers in variable. within the C Programming forums, part of the General Programming Boards category; Hey all, I am using a bar code scanner to scan a number into my program. A typical bar code ...

  1. #1
    Registered User
    Join Date
    Jul 2005
    Posts
    10

    Can't hold numbers in variable.

    Hey all,

    I am using a bar code scanner to scan a number into my program. A typical bar code number is somewhere around 12 digits long. I have to use a float for this because its too big for an integer. That works... but the only problem is that it also gives me a slew as 0000000's at the end. How can I allleviate this problem?

    Code:
    float i;
      printf("Please enter the number");
      scanf("%f",&i);
      printf("the number is :%f",i);

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,338
    Use a string of characters.

  3. #3
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,159
    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.
    If you understand what you're doing, you're not learning anything.

  4. #4
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,062
    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.
    Sent from my iPadŽ

  5. #5
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,159
    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.
    If you understand what you're doing, you're not learning anything.

  6. #6
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,062
    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.
    Last edited by SlyMaelstrom; 12-02-2005 at 01:54 PM.
    Sent from my iPadŽ

  7. #7
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,062
    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
    Last edited by SlyMaelstrom; 12-02-2005 at 02:12 PM.
    Sent from my iPadŽ

  8. #8
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,159
    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
    Last edited by itsme86; 12-02-2005 at 02:34 PM.
    If you understand what you're doing, you're not learning anything.

  9. #9
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,062
    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.
    Sent from my iPadŽ

  10. #10
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Quote 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;
    }
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  11. #11
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,586
    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.
    Last edited by VirtualAce; 12-02-2005 at 04:13 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. sorting number
    By Leslie in forum C Programming
    Replies: 8
    Last Post: 05-20-2009, 04:23 AM
  2. Big (and small) numbers...
    By swif in forum C Programming
    Replies: 6
    Last Post: 04-22-2005, 12:21 PM
  3. hold numbers with array
    By yusiye in forum C Programming
    Replies: 16
    Last Post: 07-30-2002, 03:26 PM
  4. A (complex) question on numbers
    By Unregistered in forum C++ Programming
    Replies: 8
    Last Post: 02-03-2002, 05:38 PM
  5. Variable Allocation in a simple operating system
    By awkeller in forum C Programming
    Replies: 1
    Last Post: 12-08-2001, 01:26 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21