CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 15 of 15

Thread: double vs int64

  1. #1
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    double vs int64

    You'd think this would be a simple thing to find out from the internet but I must admit, I've struggled to find the answer

    1) What is the range of numbers covered by a 64-bit double?
    2) Ignoring fractions, is the above range wider or narrower than the range covered by an int64?
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  2. #2
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: double vs int64

    Best regards,
    Igor

  3. #3
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: double vs int64

    Also look at limits.h
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

  4. #4
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: double vs int64

    Thanks guys. If I'm using my rusty old calculator correctly it looks like double has got a MUCH wider range than int64 - and even the humble float is almost comparable to int64. float seems to be roughly +/-1.1 x 10^17. int64 approx. +/-9.25 x 10^18. int32 is +/-2.1 x 10^9.
    Last edited by John E; July 31st, 2013 at 04:01 AM.
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  5. #5
    Join Date
    Apr 1999
    Posts
    27,449

    Re: double vs int64

    Quote Originally Posted by John E View Post
    Thanks guys. If I'm using my rusty old calculator correctly it looks like double has got a MUCH wider range than int64 - and even the humble float is almost comparable to int64. float seems to be roughly +/-1.1 x 10^17. int64 approx. +/-9.25 x 10^18. int32 is +/-2.1 x 10^9.
    But you realize that there is a big difference between using integral and floating point values, correct? That difference being accuracy.

    Floating point variables are not exact (unless they are sums of inverse powers of 2). An int64 is always exact, since it is an integer. Calculations that require exact math cannot be done reliably using floats and doubles. So the reasons for using float/double versus int64 is much more than range.

    For example for money calculations, it is advantageous to use integers representing the smallest unit of currency (example, for USA it would be cents instead of dollars). Then the int64 can be used to represent purely cents instead of a dollar.cents.

    Regards,

    Paul McKenzie
    Last edited by Paul McKenzie; July 31st, 2013 at 04:48 AM.

  6. #6
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: double vs int64

    Hi Paul,

    Yes, I understand about the inherent inaccuracies with float and double. Here's the problem I'm considering:-

    Code:
    void some_func(int64_t a, int64_t b)
    {
          printf ("%u\n", abs( a-b ));
    }
    I'm working on a program (originally written for Linux) which consistently sends 64-bit values to abs(). That's just a simple example above. The actual functions are usually more convoluted. The problem is that VC++ doesn't seem to have a version of abs() that accepts int64_t. The only types available support float, double, int or long. I'm trying to figure out which type I should use so that I don't lose accuracy (or at least, I lose as little accuracy as possible).
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  7. #7
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: double vs int64

    an int64 has an effective accurate range from - 263 all the way to + 263-1

    a double has an 53bit mantissa (with an implied leading 1) and it has a separate sign bit so it has an effective accurate integer range from - 254 all the way to + 254.
    Or to put it another way, a double can accurately represent any value an int55 (assuming such a thing existed) can.

    now, a double can store larger values (and it can store fractions), but none of those will guarantee accurate integer values not are they in a continuous range. or put another way, any other values not in the "int55" range will be approximations.

  8. #8
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: double vs int64

    Quote Originally Posted by John E View Post
    The problem is that VC++ doesn't seem to have a version of abs() that accepts int64_t.
    make your own...
    Code:
    int64_t abs(int64_t val)
    {
      if (val<0)
           return -val;
      else 
           return val;
    }
    depending on need, you may have to do somethign special in case val is -263 because that can't be represented in a positive int. A potential solution is returning an unsigned int64_t, but that may not fit your problem domain.

  9. #9
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: double vs int64

    Quote Originally Posted by John E View Post
    Thanks guys. If I'm using my rusty old calculator correctly it looks like double has got a MUCH wider range than int64 - and even the humble float is almost comparable to int64. float seems to be roughly +/-1.1 x 10^17. int64 approx. +/-9.25 x 10^18. int32 is +/-2.1 x 10^9.
    Yes, it has a wider range, but that range isn't continuous. try storing 144.115.188.075.855.873 in a double, then reading it back out.

    also note that most calculators don't work with a "double", but work with a floating point type that is larger than a double. So even your rusty old calculator probably exceeds the capabilities of a double.

  10. #10
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: double vs int64

    Quote Originally Posted by OReubens View Post
    make your own...
    Code:
    int64_t abs(int64_t val)
    {
      if (val<0)
           return -val;
      else 
           return val;
    }
    Good suggestion, Thanks.

    I also realised that for 64-bit values on Linux, they should really be calling llabs(), rather than abs(). A convenience macro can then be used to map llabs() to __abs64() which is the Windows equivalent.
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  11. #11
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: double vs int64

    Quote Originally Posted by OReubens View Post
    try storing 144.115.188.075.855.873 in a double, then reading it back out.
    Presumably I was supposed to remove all the periods?

    Interestingly, the compiler told me the number would get truncated from int64 to double. But according to the debugger it looked lie the right number
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  12. #12
    Join Date
    Apr 1999
    Posts
    27,449

    Re: double vs int64

    Quote Originally Posted by John E View Post
    Presumably I was supposed to remove all the periods?
    The dot is the thousands separator in Belgium (where I presume ORueben is posting from).

    Regards,

    Paul McKenzie

  13. #13
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: double vs int64

    yes, sorry about that. thousand separator.

    Also, a correction. I initially looked up the value of DBL_MANT_DIG to post the above, and DBL_MANT_DIG is defined as 53
    I knew a double has an implied 1 in front, so I added this on, but DBL_MANT apparently already has it built in as well. (Doh!)

    so change my above to:
    a double has an 52bit mantissa (with an implied leading 1) and it has a separate sign bit so it has an effective accurate integer range from - 253 all the way to + 253.
    Or to put it another way, a double can accurately represent any value an int54 (assuming such a thing existed) can.
    Interestingly, the compiler told me the number would get truncated from int64 to double. But according to the debugger it looked lie the right number
    well yes, storing it in a double right away as in
    double x = 144115188075855873;
    I would have expected the compiler to output a warning (which in and by itself should already have been a clue of it's own).


    what you were getting is probably the compiler seeing it is a const and displaying the full const value without stuffing into an actual double.
    any sort of "simple" code is probably going to need some form of "don't optimize this" to actuall proove the point I was trying to make.
    Code:
    	double x = 144115188075855873;
    	__int64 i = (__int64)x;
    Running this in a debug build or with all optimisations off results in i being equal to 144115188075855872 on VC2010. (and I would expect the same result on any compiler given how truncating/rounding should work.
    Last edited by OReubens; August 1st, 2013 at 07:23 AM.

  14. #14
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: double vs int64

    Thanks again for that full explanation OReubens. I tried that assignment, like you suggested (double to int64_t) and you were absolutely right. The int64_t was 1 less than the original number.

    Actually I think there's something else I haven't fully understood in all this (the meaning of the letter 'E'). Looking at that web page that Igor linked to, I noticed that type float can hold a maximum (positive) number of 3.4E38. I originally thought that 'E' meant 'e' the natural logarithm (i.e. 2.7182818). So I calculated 3.4E38 to mean:-

    3.4 x E^38 - or in other words, ((2.7182818^38) * 3.4)

    But my debugger suggests that my assumption was completely wrong! It gives the impression that 3.4E38 actually means (3.4 * 10^38)

    How confusing...
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  15. #15
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: double vs int64

    E stands for exponent and is used for scientific notation. You're impression is right 3.4E38 means 3.4 * 10^38. See

    https://en.wikipedia.org/wiki/Scientific_notation
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured