Most negative double value

[Peter Ammon]

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.

 

[Malcolm]

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.

 

[Papadopoulos Giannis]

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)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

 

[Peter Ammon]

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.

 

[Papadopoulos Giannis]

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)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

 

[Christian Bau]

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

You are aware that this is nonsense?

If not, then think about it for five minutes before you respond.

 

[CBFalconer]

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

 

[Dan Pop]

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

 

[Papadopoulos Giannis]

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)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

 

[Christian Bau]

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?

 

[Old Wolf]

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.

 

[Papadopoulos Giannis]

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)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

 

[Peter Ammon]

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

 

[Christian Bau]

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


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]

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".

 

[Papadopoulos Giannis]

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)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

 

[Arthur J. O'Dwyer]

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.

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

 

[Papadopoulos Giannis]

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)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

 

[Arthur J. O'Dwyer]

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

 

[Clark Cox]

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...


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.