long -> double -> long

Discussion in 'C Programming' started by Steven Woody, Aug 28, 2007.

  1. Steven Woody

    Steven Woody Guest

    long i = nnn;
    long j;
    double d;
    d = i;
    j = ( long )d;

    in this case, i == j ?

    thanks.
     
    Steven Woody, Aug 28, 2007
    #1
    1. Advertising

  2. Steven Woody

    Jack Klein Guest

    On Tue, 28 Aug 2007 03:09:37 -0000, Steven Woody
    <> wrote in comp.lang.c:

    > long i = nnn;
    > long j;
    > double d;
    > d = i;
    > j = ( long )d;


    The cast is completely unnecessary, and completely useless. The
    conversion is performed automatically on assignment, and cast does not
    change that. If the value of the double is outside the range of
    values representable in an unsigned long, the behavior is undefined,
    with or without the cast.

    > in this case, i == j ?


    Maybe.

    > thanks.


    You're welcome.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Aug 28, 2007
    #2
    1. Advertising

  3. In article <>,
    Steven Woody <> wrote:
    >long i = nnn;
    >long j;
    >double d;
    >d = i;
    >j = ( long )d;


    >in this case, i == j ?


    Not necessarily. double pretty much has to be at least 64 bits,
    including the sign and exponent; you end up with about 52 bits
    of mantisa as the minimum. If the nnn that you are storing
    is more than the radix to the power of (1 more than #bits in mantisa)
    (e.g., 2^(1+52), then nnn cannot be stored exactly unless
    the last (64-(1+#bits in mantisa)) happen to be 0.

    This does come up in practice; on SGI and Sun 64 bit machines
    programs compiled in 64 bit mode have 64 bit doubles and 64 bit longs.
    ((1L<<53)+1L) is too large to be stored in a double in such a system.
    --
    "law -- it's a commodity"
    -- Andrew Ryan (The Globe and Mail, 2005/11/26)
     
    Walter Roberson, Aug 28, 2007
    #3
  4. Steven Woody

    Guest

    On Aug 28, 8:09 am, Steven Woody <> wrote:
    > long i = nnn;
    > long j;
    > double d;
    > d = i;
    > j = ( long )d;
    >
    > in this case, i == j ?
    >
    > thanks.


    i==j yes it is true.
     
    , Aug 28, 2007
    #4
  5. <> wrote in message
    news:...
    > On Aug 28, 8:09 am, Steven Woody <> wrote:
    >> long i = nnn;
    >> long j;
    >> double d;
    >> d = i;
    >> j = ( long )d;
    >>
    >> in this case, i == j ?
    >>
    >> thanks.

    >
    > i==j yes it is true.
    >

    Normally, yes. On some systems all integers representable by a long will be
    representable exactly by a double, and so i will always equal j. Change the
    double to a float and put it a very high value, and assuming four bytes for
    each, you will see that j is now usually approximate.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Aug 28, 2007
    #5
  6. Steven Woody

    Ian Collins Guest

    Malcolm McLean wrote:
    >
    > <> wrote in message
    > news:...
    >> On Aug 28, 8:09 am, Steven Woody <> wrote:
    >>> long i = nnn;
    >>> long j;
    >>> double d;
    >>> d = i;
    >>> j = ( long )d;
    >>>
    >>> in this case, i == j ?
    >>>
    >>> thanks.

    >>
    >> i==j yes it is true.
    >>

    > Normally, yes. On some systems all integers representable by a long will
    > be representable exactly by a double, and so i will always equal j.
    > Change the double to a float and put it a very high value, and assuming
    > four bytes for each, you will see that j is now usually approximate.
    >

    Given a sufficiently high value in that case, j must be approximate.

    --
    Ian Collins.
     
    Ian Collins, Aug 28, 2007
    #6
  7. Steven Woody

    Guest

    On Aug 28, 8:09 am, Steven Woody <> wrote:
    > long i = nnn;
    > long j;
    > double d;
    > d = i;
    > j = ( long )d;
    >
    > in this case, i == j ?
    >
    > thanks.


    you have nnn to i by using long data type. the output of both i and j
    will be 0 because it is not poible to output character through long.
     
    , Aug 28, 2007
    #7
  8. Steven Woody

    Steven Woody Guest

    On Aug 28, 11:49 am, -cnrc.gc.ca (Walter Roberson)
    wrote:
    > In article <>,
    > Steven Woody <> wrote:
    >
    > >long i = nnn;
    > >long j;
    > >double d;
    > >d = i;
    > >j = ( long )d;
    > >in this case, i == j ?

    >
    > Not necessarily. double pretty much has to be at least 64 bits,
    > including the sign and exponent; you end up with about 52 bits
    > of mantisa as the minimum. If the nnn that you are storing
    > is more than the radix to the power of (1 more than #bits in mantisa)
    > (e.g., 2^(1+52), then nnn cannot be stored exactly unless
    > the last (64-(1+#bits in mantisa)) happen to be 0.
    >
    > This does come up in practice; on SGI and Sun 64 bit machines
    > programs compiled in 64 bit mode have 64 bit doubles and 64 bit longs.
    > ((1L<<53)+1L) is too large to be stored in a double in such a system.
    > --
    > "law -- it's a commodity"
    > -- Andrew Ryan (The Globe and Mail, 2005/11/26)


    thanks for all your inputs. i now understan, if nnn is so large that
    it can not be presented in a double with zero exponent, it becomes
    unexactly. since my system has a 16bit integer and 32bit double, so i
    believe this will not happend and i in above code always equals to j.

    thanks again.
     
    Steven Woody, Aug 28, 2007
    #8
  9. In article <>,
    Steven Woody <> wrote:
    >On Aug 28, 11:49 am, -cnrc.gc.ca (Walter Roberson)
    >wrote:
    >> In article <>,
    >> Steven Woody <> wrote:


    >> >long i = nnn;
    >> >long j;
    >> >double d;
    >> >d = i;
    >> >j = ( long )d;
    >> >in this case, i == j ?


    >thanks for all your inputs. i now understan, if nnn is so large that
    >it can not be presented in a double with zero exponent, it becomes
    >unexactly.


    Ummm, not exactly.

    The below relates to the most common means of representing floating
    point numbers. There are other schemes that differ a bit in the
    details:

    Take the integer and write it out in binary, with no leading 0's.
    Count the number of bits and subtract 1; the result will be the
    "unbiased" exponent used. Internally, a constant will be added to
    this exponent to produce a "biased exponent" that will actually
    be stored (the reasons for this have to do with storing numbers less
    than 1.) Thus, the unbiased exponent will be non-zero for any integer
    greater than 1. Now discard the leading 1 bit from the binary
    representation of the integer, *leaving any leading 0s there*.
    Start storing this binary number into the available
    mantissa digits (e.g., 23 bits for IEEE 32 bit floats),
    starting from the "left" (highest bit position) and progressing
    towards the right. If you run out of binary digits before you
    run out of available bits, then you were able to store the integer
    exactly in the floating point number; pad any remaining mantissa
    bits out with binary 0's. If you run out of available mantissa
    bits before you run out of binary digits, then you were not
    able to store the integer exactly.

    Or, as a simpler wording: count the number of binary digits in
    the representation of the integer, and subtract 1 from that count.
    If the result is more than the number of mantissa bits available,
    then you cannot store the integer exactly.


    >since my system has a 16bit integer and 32bit double, so i
    >believe this will not happend and i in above code always equals to j.


    There are two problems with that.

    A) Your code is written around -long-, not around -int-, and it is not
    valid in C for a long to be as little as 16 bits. long in C requires at
    least 32 bits.

    B) Secondly, in any conforming C program, it is not valid for
    double to be as little as 32 bits: 32 bits is not enough to
    achieve the requirement that DBL_DIG (the number of decimal
    digits that can be reliably stored) be at least 10;
    32 bits is only enough for 6 decimal digits of reliable storage.
    The minimum number of bits needed to meet the C90 constraints
    on the range and precision of double, is 43.

    --
    "No one has the right to destroy another person's belief by
    demanding empirical evidence." -- Ann Landers
     
    Walter Roberson, Aug 28, 2007
    #9
  10. Steven Woody

    Old Wolf Guest

    On Aug 28, 3:36 pm, Jack Klein <> wrote:
    > On Tue, 28 Aug 2007 03:09:37 -0000, Steven Woody
    >
    > > j = ( long )d;

    >
    > The cast is completely unnecessary, and completely useless.


    It does have some use: to document that the writer
    intended to possibly lose precision in the value.

    (Not that I approve of such use, but others do).
     
    Old Wolf, Aug 28, 2007
    #10
  11. Steven Woody

    Steven Woody Guest

    On Aug 29, 1:33 am, -cnrc.gc.ca (Walter Roberson)
    wrote:
    > In article <>,
    > Steven Woody <> wrote:
    >
    > >On Aug 28, 11:49 am, -cnrc.gc.ca (Walter Roberson)
    > >wrote:
    > >> In article <>,
    > >> Steven Woody <> wrote:
    > >> >long i = nnn;
    > >> >long j;
    > >> >double d;
    > >> >d = i;
    > >> >j = ( long )d;
    > >> >in this case, i == j ?

    > >thanks for all your inputs. i now understan, if nnn is so large that
    > >it can not be presented in a double with zero exponent, it becomes
    > >unexactly.

    >
    > Ummm, not exactly.
    >
    > The below relates to the most common means of representing floating
    > point numbers. There are other schemes that differ a bit in the
    > details:
    >
    > Take the integer and write it out in binary, with no leading 0's.
    > Count the number of bits and subtract 1; the result will be the
    > "unbiased" exponent used. Internally, a constant will be added to
    > this exponent to produce a "biased exponent" that will actually
    > be stored (the reasons for this have to do with storing numbers less
    > than 1.) Thus, the unbiased exponent will be non-zero for any integer
    > greater than 1. Now discard the leading 1 bit from the binary
    > representation of the integer, *leaving any leading 0s there*.
    > Start storing this binary number into the available
    > mantissa digits (e.g., 23 bits for IEEE 32 bit floats),
    > starting from the "left" (highest bit position) and progressing
    > towards the right. If you run out of binary digits before you
    > run out of available bits, then you were able to store the integer
    > exactly in the floating point number; pad any remaining mantissa
    > bits out with binary 0's. If you run out of available mantissa
    > bits before you run out of binary digits, then you were not
    > able to store the integer exactly.



    thanks!

    >
    > Or, as a simpler wording: count the number of binary digits in
    > the representation of the integer, and subtract 1 from that count.
    > If the result is more than the number of mantissa bits available,
    > then you cannot store the integer exactly.


    it seems it conflits with above description. by above, you seem to
    compare the bits numbers of the integer substracting ( 1 + bits of
    leading 1's ) with the bits of mantissa.

    >
    > >since my system has a 16bit integer and 32bit double, so i
    > >believe this will not happend and i in above code always equals to j.

    >
    > There are two problems with that.
    >
    > A) Your code is written around -long-, not around -int-, and it is not
    > valid in C for a long to be as little as 16 bits. long in C requires at
    > least 32 bits.
    >
    > B) Secondly, in any conforming C program, it is not valid for
    > double to be as little as 32 bits: 32 bits is not enough to
    > achieve the requirement that DBL_DIG (the number of decimal
    > digits that can be reliably stored) be at least 10;
    > 32 bits is only enough for 6 decimal digits of reliable storage.
    > The minimum number of bits needed to meet the C90 constraints
    > on the range and precision of double, is 43.
    >
    > --
    > "No one has the right to destroy another person's belief by
    > demanding empirical evidence." -- Ann Landers
     
    Steven Woody, Aug 29, 2007
    #11
  12. On Tue, 28 Aug 2007 16:45:38 -0000, Steven Woody
    <> wrote:

    >On Aug 28, 11:49 am, -cnrc.gc.ca (Walter Roberson)
    >wrote:
    >> In article <>,
    >> Steven Woody <> wrote:
    >>
    >> >long i = nnn;
    >> >long j;
    >> >double d;
    >> >d = i;
    >> >j = ( long )d;
    >> >in this case, i == j ?

    >>
    >> Not necessarily. double pretty much has to be at least 64 bits,
    >> including the sign and exponent; you end up with about 52 bits
    >> of mantisa as the minimum. If the nnn that you are storing
    >> is more than the radix to the power of (1 more than #bits in mantisa)
    >> (e.g., 2^(1+52), then nnn cannot be stored exactly unless
    >> the last (64-(1+#bits in mantisa)) happen to be 0.
    >>
    >> This does come up in practice; on SGI and Sun 64 bit machines
    >> programs compiled in 64 bit mode have 64 bit doubles and 64 bit longs.
    >> ((1L<<53)+1L) is too large to be stored in a double in such a system.
    >> --
    >> "law -- it's a commodity"
    >> -- Andrew Ryan (The Globe and Mail, 2005/11/26)

    >
    >thanks for all your inputs. i now understan, if nnn is so large that
    >it can not be presented in a double with zero exponent, it becomes
    >unexactly. since my system has a 16bit integer and 32bit double, so i
    >believe this will not happend and i in above code always equals to j.


    Not quite. Most (if not all) floating point systems have the implied
    decimal point (technically a radix point since it is not decimal) at
    the far left so no integers greater than 1 have a zero exponent (and
    on my system, neither does 1).

    Its more a of function bit representation. If the number of
    significant bits in your long (sbl) exceeds the number of significant
    bits a double can hold (sbd), then the rightmost sbl-sbd digits of the
    long will not be present in the double. If any of these bits are 1,
    they will be lost in the first conversion and cannot be recovered in
    the second.

    By way of example, consider a double with a 5-bit mantissa and the
    implied decimal point at the far right. If the long is (in binary)
    11111, then the double will be 11111 with an exponent of 0 and the
    conversion back produces the same value. If the long is 111111, the
    double will be 11111 with an exponent of 1 and the conversion back
    will produce 111110. However, if the long started as 1111100 (which
    is a greater value), the conversion back works because all the
    "missing" bits are zero.

    Please don't quote signatures (the part following the "-- "
    separator).

    BTW, is you shift key broken? Just as code is easier to read when it
    follows conventions, so is the accompanying text. When asking for
    help, it behooves the requestor to make things as easy as possible for
    the those tempted to respond.


    Remove del for email
     
    Barry Schwarz, Aug 30, 2007
    #12
  13. On Tue, 28 Aug 2007 20:19:37 +1200, Ian Collins <>
    wrote:

    >Malcolm McLean wrote:
    >>
    >> <> wrote in message
    >> news:...
    >>> On Aug 28, 8:09 am, Steven Woody <> wrote:
    >>>> long i = nnn;
    >>>> long j;
    >>>> double d;
    >>>> d = i;
    >>>> j = ( long )d;
    >>>>
    >>>> in this case, i == j ?
    >>>>
    >>>> thanks.
    >>>
    >>> i==j yes it is true.
    >>>

    >> Normally, yes. On some systems all integers representable by a long will
    >> be representable exactly by a double, and so i will always equal j.
    >> Change the double to a float and put it a very high value, and assuming
    >> four bytes for each, you will see that j is now usually approximate.
    >>

    >Given a sufficiently high value in that case, j must be approximate.


    Not if a sufficient number of low order bits in the binary
    representation of the initial value are zero.


    Remove del for email
     
    Barry Schwarz, Aug 30, 2007
    #13
  14. On Tue, 28 Aug 2007 08:25:13 -0000, ""
    <> wrote:

    >On Aug 28, 8:09 am, Steven Woody <> wrote:
    >> long i = nnn;
    >> long j;
    >> double d;
    >> d = i;
    >> j = ( long )d;
    >>
    >> in this case, i == j ?
    >>
    >> thanks.

    >
    >you have nnn to i by using long data type. the output of both i and j
    >will be 0 because it is not poible to output character through long.


    It is perfectly acceptable to assign a char to a long. But since the
    original poster didn't do that, why would you bring it up?


    Remove del for email
     
    Barry Schwarz, Aug 30, 2007
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ferran
    Replies:
    9
    Views:
    3,093
    Kevin Goodsell
    Apr 12, 2004
  2. JKop
    Replies:
    4
    Views:
    16,555
  3. Sydex
    Replies:
    12
    Views:
    6,598
    Victor Bazarov
    Feb 17, 2005
  4. Michael Mair

    Typecast long double->double seems to go wrong

    Michael Mair, May 24, 2004, in forum: C Programming
    Replies:
    4
    Views:
    688
    Michael Mair
    May 24, 2004
  5. Daniel Rudy

    unsigned long long int to long double

    Daniel Rudy, Sep 19, 2005, in forum: C Programming
    Replies:
    5
    Views:
    1,234
    Peter Shaggy Haywood
    Sep 20, 2005
Loading...

Share This Page