Most negative double value

Discussion in 'C Programming' started by Peter Ammon, Feb 19, 2004.

  1. Peter Ammon

    Peter Ammon Guest

    What's the most negative double value I can get? Is it always
    guaranteed to be -DBL_MAX? If so, why (or rather, where)?

    Thanks.
     
    Peter Ammon, Feb 19, 2004
    #1
    1. Advertising

  2. Peter Ammon

    Malcolm Guest

    "Peter Ammon" <> wrote in message
    > What's the most negative double value I can get? Is it always
    > guaranteed to be -DBL_MAX? If so, why (or rather, where)?
    >

    Most floating point formats have a negative flag bit which can be set or
    unset. The most natural system is for the maximum and minimum to be of the
    same magnitude.
     
    Malcolm, Feb 19, 2004
    #2
    1. Advertising

  3. Peter Ammon wrote:
    > What's the most negative double value I can get? Is it always
    > guaranteed to be -DBL_MAX? If so, why (or rather, where)?
    >
    > Thanks.
    >


    It is DBL_MIN and it is always -DBL_MAX in IEEE-754 compliant systems..

    --
    #include <stdio.h>
    #define p(s) printf(#s" endian")
    int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

    Giannis Papadopoulos
    http://dop.users.uth.gr/
    University of Thessaly
    Computer & Communications Engineering dept.
     
    Papadopoulos Giannis, Feb 20, 2004
    #3
  4. Peter Ammon

    Peter Ammon Guest

    Papadopoulos Giannis wrote:
    > Peter Ammon wrote:
    >
    >> What's the most negative double value I can get? Is it always
    >> guaranteed to be -DBL_MAX? If so, why (or rather, where)?
    >>
    >> Thanks.
    >>

    >
    > It is DBL_MIN and it is always -DBL_MAX in IEEE-754 compliant systems..


    DBL_MIN on my platform is 2.2250738585072014e-308 which is positive.

    --
    Pull out a splinter to reply.
     
    Peter Ammon, Feb 20, 2004
    #4
  5. Peter Ammon wrote:
    > Papadopoulos Giannis wrote:
    >
    >> Peter Ammon wrote:
    >>
    >>> What's the most negative double value I can get? Is it always
    >>> guaranteed to be -DBL_MAX? If so, why (or rather, where)?
    >>>
    >>> Thanks.
    >>>

    >>
    >> It is DBL_MIN and it is always -DBL_MAX in IEEE-754 compliant systems..

    >
    >
    > DBL_MIN on my platform is 2.2250738585072014e-308 which is positive.
    >

    F**K.....
    I should never post again after 02:00 in the morning...

    Yes, the most negative value is -DBL_MAX...
    The smallest positive is DBL_MIN...

    A big sorry...

    --
    #include <stdio.h>
    #define p(s) printf(#s" endian")
    int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

    Giannis Papadopoulos
    http://dop.users.uth.gr/
    University of Thessaly
    Computer & Communications Engineering dept.
     
    Papadopoulos Giannis, Feb 20, 2004
    #5
  6. In article <c13jg2$hit$>,
    Papadopoulos Giannis <> wrote:

    > #include <stdio.h>
    > #define p(s) printf(#s" endian")
    > int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}


    You are aware that this is nonsense?

    If not, then think about it for five minutes before you respond.
     
    Christian Bau, Feb 20, 2004
    #6
  7. Peter Ammon

    CBFalconer Guest

    Peter Ammon wrote:
    > Papadopoulos Giannis wrote:
    > > Peter Ammon wrote:
    > >
    > >> What's the most negative double value I can get? Is it always
    > >> guaranteed to be -DBL_MAX? If so, why (or rather, where)?

    > >
    > > It is DBL_MIN and it is always -DBL_MAX in IEEE-754 compliant systems..

    >
    > DBL_MIN on my platform is 2.2250738585072014e-308 which is positive.


    Which is apparently correct. From N869:

    [#10] The values given in the following list shall be
    replaced by implementation-defined constant expressions with
    (positive) values that are less than or equal to those
    shown:

    -- the difference between 1 and the least value greater
    than 1 that is representable in the given floating
    point type, b1-p

    FLT_EPSILON 1E-5
    DBL_EPSILON 1E-9
    LDBL_EPSILON 1E-9

    -- minimum normalized positive floating-point number,
    bemin-1

    FLT_MIN 1E-37
    DBL_MIN 1E-37
    LDBL_MIN 1E-37

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Feb 20, 2004
    #7
  8. Peter Ammon

    Dan Pop Guest

    In <c132k7$gvp$> Peter Ammon <> writes:

    >What's the most negative double value I can get? Is it always
    >guaranteed to be -DBL_MAX?


    Yes.

    >If so, why (or rather, where)?


    Because the standard uses a sign-magnitude model for the floating point
    numbers. 5.2.4.2.2 in C99. Sorry, but the text is next to impossible
    to quote in plain text format, without using some special convention,
    a la TeX and friends.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Feb 20, 2004
    #8
  9. Christian Bau wrote:
    > In article <c13jg2$hit$>,
    > Papadopoulos Giannis <> wrote:
    >
    >
    >>#include <stdio.h>
    >>#define p(s) printf(#s" endian")
    >>int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

    >
    >
    > You are aware that this is nonsense?
    >
    > If not, then think about it for five minutes before you respond.


    Please explain...

    --
    #include <stdio.h>
    #define p(s) printf(#s" endian")
    int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

    Giannis Papadopoulos
    http://dop.users.uth.gr/
    University of Thessaly
    Computer & Communications Engineering dept.
     
    Papadopoulos Giannis, Feb 20, 2004
    #9
  10. In article <c15dn0$r78$>,
    Papadopoulos Giannis <> wrote:

    > Christian Bau wrote:
    > > In article <c13jg2$hit$>,
    > > Papadopoulos Giannis <> wrote:
    > >
    > >
    > >>#include <stdio.h>
    > >>#define p(s) printf(#s" endian")
    > >>int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

    > >
    > >
    > > You are aware that this is nonsense?
    > >
    > > If not, then think about it for five minutes before you respond.

    >
    > Please explain...


    Do you think that bigendian and littleendian are the only possibilities?
    Could the char that you are reading consist completely of padding bits
    in the int, in which case you could get two different results when you
    run the program twice?
     
    Christian Bau, Feb 20, 2004
    #10
  11. Peter Ammon

    Old Wolf Guest

    > > >>#include <stdio.h>
    > > >>#define p(s) printf(#s" endian")
    > > >>int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}
    > > >
    > > >
    > > > You are aware that this is nonsense?
    > > >
    > > > If not, then think about it for five minutes before you respond.

    > >
    > > Please explain...

    >
    > Do you think that bigendian and littleendian are the only possibilities?
    > Could the char that you are reading consist completely of padding bits
    > in the int, in which case you could get two different results when you
    > run the program twice?


    Do you think that "endianness-detector" is the only possibility
    for the purpose of this program? It could in fact be a random
    greeting program in Martian, or a pedant-trapper, or a
    compiler test, or pretty much anything really.
     
    Old Wolf, Feb 21, 2004
    #11
  12. Christian Bau wrote:
    > Do you think that bigendian and littleendian are the only possibilities?


    No, but I believe that are the most common ones..

    > Could the char that you are reading consist completely of padding bits
    > in the int, in which case you could get two different results when you
    > run the program twice?


    I think if I change *(char*)&v to *(char*)&v==1 I can rid of it.. Or
    don't I??

    PS If the code below does not work (and I have come across it many
    times, in books and the Inet), then what should??

    --
    #include <stdio.h>
    #define p(s) printf(#s" endian")
    int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

    Giannis Papadopoulos
    http://dop.users.uth.gr/
    University of Thessaly
    Computer & Communications Engineering dept.
     
    Papadopoulos Giannis, Feb 21, 2004
    #12
  13. Peter Ammon

    Peter Ammon Guest

    Dan Pop wrote:

    > In <c132k7$gvp$> Peter Ammon <> writes:
    >
    >
    >>What's the most negative double value I can get? Is it always
    >>guaranteed to be -DBL_MAX?

    >
    >
    > Yes.
    >
    >
    >>If so, why (or rather, where)?

    >
    >
    > Because the standard uses a sign-magnitude model for the floating point
    > numbers. 5.2.4.2.2 in C99. Sorry, but the text is next to impossible
    > to quote in plain text format, without using some special convention,
    > a la TeX and friends.
    >
    > Dan


    There it is! Thanks.

    -Peter

    --
    Pull out a splinter to reply.
     
    Peter Ammon, Feb 21, 2004
    #13
  14. In article <c17q21$1rv7$>,
    Papadopoulos Giannis <> wrote:

    > Christian Bau wrote:
    > > Do you think that bigendian and littleendian are the only possibilities?

    >
    > No, but I believe that are the most common ones..
    >
    > > Could the char that you are reading consist completely of padding bits
    > > in the int, in which case you could get two different results when you
    > > run the program twice?

    >
    > I think if I change *(char*)&v to *(char*)&v==1 I can rid of it.. Or
    > don't I??
    >
    > PS If the code below does not work (and I have come across it many
    > times, in books and the Inet), then what should??


    The pragmatic solution is to add an appropriate #define into some header
    file. Also helpful is to write code that doesn't depend on endianness in
    the first place: For example, to write a value x up to 2^32 to a file,
    write the bytes (x >> 24) & 0xff, (x >> 16) & 0xff, (x >> 8) & 0xff, x &
    0xff and you will get the same results everywhere.

    C doesn't even say that there is such a thing as a "byte ordering": If
    for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
    the 16 bits of an int could be mapped in any possible permutation to the
    16 bits in an array of two chars.
     
    Christian Bau, Feb 22, 2004
    #14
  15. In article <>,
    (Old Wolf) wrote:

    > > > >>#include <stdio.h>
    > > > >>#define p(s) printf(#s" endian")
    > > > >>int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}
    > > > >
    > > > >
    > > > > You are aware that this is nonsense?
    > > > >
    > > > > If not, then think about it for five minutes before you respond.
    > > >
    > > > Please explain...

    > >
    > > Do you think that bigendian and littleendian are the only possibilities?
    > > Could the char that you are reading consist completely of padding bits
    > > in the int, in which case you could get two different results when you
    > > run the program twice?

    >
    > Do you think that "endianness-detector" is the only possibility
    > for the purpose of this program? It could in fact be a random
    > greeting program in Martian, or a pedant-trapper, or a
    > compiler test, or pretty much anything really.


    If you read the next reply of the original poster, you will find that it
    is an "endianness-detector".
     
    Christian Bau, Feb 22, 2004
    #15
  16. Christian Bau wrote:
    > The pragmatic solution is to add an appropriate #define into some header
    > file. Also helpful is to write code that doesn't depend on endianness in
    > the first place: For example, to write a value x up to 2^32 to a file,
    > write the bytes (x >> 24) & 0xff, (x >> 16) & 0xff, (x >> 8) & 0xff, x &
    > 0xff and you will get the same results everywhere.


    Yes, this is right if I am writing robust code to run everywhere... On
    the other hand this is a really simple (and maybe stupid) program that
    tries to find machine endianess and is part of my signature...

    > C doesn't even say that there is such a thing as a "byte ordering": If
    > for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
    > the 16 bits of an int could be mapped in any possible permutation to the
    > 16 bits in an array of two chars.


    OK, but all the great minds of processor design have come to the
    conclusion that the 16bit integer will be represented in either big
    endian or little endian...

    PS even with padding bits, I think *(char*)&v==1 should do the trick...
    comments?

    --
    #include <stdio.h>
    #define p(s) printf(#s" endian")
    int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

    Giannis Papadopoulos
    http://dop.users.uth.gr/
    University of Thessaly
    Computer & Communications Engineering dept.
     
    Papadopoulos Giannis, Feb 22, 2004
    #16
  17. On Mon, 23 Feb 2004, Papadopoulos Giannis wrote:
    >
    > Christian Bau wrote:
    > > The pragmatic solution is [...]

    >
    > Yes, this is right if I am writing robust code to run everywhere... On
    > the other hand this is a really simple (and maybe stupid) program that
    > tries to find machine endianess and is part of my signature...


    I.e., it's not pragmatic or correct. Which will attract attention
    in comp.lang.c, because that's the kind of thing we do here. :) If
    you don't want comments on your sig, then you should not post your
    sig to comp.lang.c.

    > > C doesn't even say that there is such a thing as a "byte ordering": If
    > > for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
    > > the 16 bits of an int could be mapped in any possible permutation to the
    > > 16 bits in an array of two chars.

    >
    > OK, but all the great minds of processor design have come to the
    > conclusion that the 16bit integer will be represented in either big
    > endian or little endian...


    Depends on what you mean by "great minds." I think the PDP-11
    has been brought up as a (32-bit) counter-example before... or was
    it the PDP-7? I don't know. And anyway, comp.lang.c doesn't care
    about processor design, we care about C programming.

    > PS even with padding bits, I think *(char*)&v==1 should do the trick...
    > comments?


    Wrong. Assuming 'v' is an int, you're invoking undefined behavior
    by trying to look at its bits as if they represented a valid 'char'
    value. So anything can happen, including nasal demons or wrong
    answers.

    -Arthur
     
    Arthur J. O'Dwyer, Feb 22, 2004
    #17
  18. Arthur J. O'Dwyer wrote:
    > I.e., it's not pragmatic or correct. Which will attract attention
    > in comp.lang.c, because that's the kind of thing we do here. :) If
    > you don't want comments on your sig, then you should not post your
    > sig to comp.lang.c.


    I've never said I do not want comments on what I'm writing.. Comments
    are always acceptable...

    > Wrong. Assuming 'v' is an int, you're invoking undefined behavior
    > by trying to look at its bits as if they represented a valid 'char'
    > value. So anything can happen, including nasal demons or wrong
    > answers.
    >
    > -Arthur


    For a 32-bit machine would

    union boo {
    unsigned int i;
    unsigned char c[4];
    };

    union boo a;

    and looking at a.c[0]

    be more acceptable??

    --
    #include <stdio.h>
    #define p(s) printf(#s" endian")
    int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

    Giannis Papadopoulos
    http://dop.users.uth.gr/
    University of Thessaly
    Computer & Communications Engineering dept.
     
    Papadopoulos Giannis, Feb 22, 2004
    #18
  19. On Mon, 23 Feb 2004, Papadopoulos Giannis wrote:
    >
    > Arthur J. O'Dwyer wrote:
    > > I.e., it's not pragmatic or correct. Which will attract attention
    > > in comp.lang.c, because that's the kind of thing we do here. :) If
    > > you don't want comments on your sig, then you should not post your
    > > sig to comp.lang.c.

    >
    > I've never said I do not want comments on what I'm writing.. Comments
    > are always acceptable...


    Well then, stop trying to justify yourself. ;-) ;-)

    > > Wrong. Assuming 'v' is an int, you're invoking undefined behavior
    > > by trying to look at its bits as if they represented a valid 'char'
    > > value. So anything can happen, including nasal demons or wrong
    > > answers.

    >
    > For a 32-bit machine would
    >
    > union boo {
    > unsigned int i;
    > unsigned char c[4];
    > };
    >
    > union boo a;
    >
    > and looking at a.c[0]
    > be more acceptable??


    Not from the standard's point of view. Let's assume that by
    "32-bit machine" you mean "an implementation on which 'CHAR_BIT'
    is 8 and 'sizeof(int)' is 4." Then it is *still* possible that
    INT_MAX could be 32767 or 65535 (I think) or some other number,
    and a.c[0] could be composed entirely of padding bits and thus
    irrelevant to the "endianness" of the machine (whatever that
    means in a padding-bits context).

    Actually, it would be a *little* more "acceptable"; now that
    you've switched to 'unsigned char', the Standard guarantees that
    'unsigned char' has no trap representations. Thus what you have
    now is either implementation-defined or unspecified behavior,
    depending on your interpretation of the Standard (I think); but
    not undefined behavior, as it was before.

    Anyway, the basic point I guess is that you haven't fully defined
    what you mean by "endianness." Sure, there are two or three obvious
    "endian" cases, but how do you classify the big gray area including
    padding bits and weird bit orders?
    If you assume as a prerequisite that the implementation *must*
    have either the 1234 or the 4321 byte order, and no padding bits,
    then your program works perfectly. But standard C doesn't make that
    assumption -- it makes different assumptions such that it is actually
    impossible to determine whether a given 'int' is big- or little-endian
    in a portable fashion. (I'm fairly sure that's right -- something
    like the Halting Problem probably applies somehow.)

    HTH,
    -Arthur
     
    Arthur J. O'Dwyer, Feb 23, 2004
    #19
  20. Peter Ammon

    Clark Cox Guest

    In article <c1bckd$1ffa$>,
    Papadopoulos Giannis <> wrote:

    > Christian Bau wrote:
    > > The pragmatic solution is to add an appropriate #define into some header
    > > file. Also helpful is to write code that doesn't depend on endianness in
    > > the first place: For example, to write a value x up to 2^32 to a file,
    > > write the bytes (x >> 24) & 0xff, (x >> 16) & 0xff, (x >> 8) & 0xff, x &
    > > 0xff and you will get the same results everywhere.

    >
    > Yes, this is right if I am writing robust code to run everywhere... On
    > the other hand this is a really simple (and maybe stupid) program that
    > tries to find machine endianess and is part of my signature...
    >
    > > C doesn't even say that there is such a thing as a "byte ordering": If
    > > for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
    > > the 16 bits of an int could be mapped in any possible permutation to the
    > > 16 bits in an array of two chars.

    >
    > OK, but all the great minds of processor design have come to the
    > conclusion that the 16bit integer will be represented in either big
    > endian or little endian...
    >
    > PS even with padding bits, I think *(char*)&v==1 should do the trick...
    > comments?


    No, consider a situation where:

    char is 8 bits
    int is 8 padding bits, followed by 24 value bits

    The value of the expression (*(char*)&v) could be anything at all, so
    comparing it to 1 is completely useless.
     
    Clark Cox, Feb 23, 2004
    #20
    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. prem_eda
    Replies:
    5
    Views:
    8,049
    Pieter Hulshoff
    Oct 11, 2004
  2. H.MuthuKumaraRajan
    Replies:
    3
    Views:
    493
    H.MuthuKumaraRajan
    Feb 4, 2004
  3. Sydex
    Replies:
    12
    Views:
    6,659
    Victor Bazarov
    Feb 17, 2005
  4. John
    Replies:
    11
    Views:
    2,231
  5. xkenneth
    Replies:
    8
    Views:
    371
    Bruno Desthuilliers
    Feb 6, 2008
Loading...

Share This Page