Why numeric_limits<int>::min() is differently defined?

views:

159

answers:

+5 Q:

Why numeric_limits<int>::min() is differently defined?

To retrieve the smallest value i have to use numeric_limits<int>::min()

I suppose the smallest int is -2147483648, and tests on my machine showed this result. But some C++ references like Open Group Base Specifications and cplusplus.com define it with the value -2147483647.

I ask this question because in my implementation of the negaMax Framework (Game Tree Search) the value minimal integer * (-1) has to be well defined. Yes, with minimal int = (numeric_limits::min() + 2) i am on the safe side in any case, thus my question is more theoretically but i think nevertheless quite interesting.

From the cplusplus.com link you posted (emphasis mine):

The following panel shows the different constants and their guaranteed minimal magnitudes (positive numbers may be greater in value, and negative numbers may be less in value). Any particular compiler implementation may define integral types with greater magnitudes than those shown here

Numeric limits are always system and compiler defined, try running with a 64bit compiler and system, you may see totally different numbers.

Adam W 2010-02-22 22:20:24

you are right, but for example min char need not to be defined as -127 on one machine and -128 on the other, this is not defined by the system (32bit or 64bit). So what is the reason for the difference?

Christian Ammer 2010-02-22 22:33:54

Christian: as others have said, twos complement is not the only way to do arithmetic. Ones complement is another way of handling numbers, there the minimum value you store in a byte is -127, not -128 (and similarly for 16 bits, 32 bits, and 64 bits). The C++ standard is flexible about this for the types that are actually meant to represent numbers (i.e. short, int, and long), and thus provides a guarantee that can be satisfied by both ones complement and twos complement, even while most implementations actually make it one bigger thanks to the architecture dictating twos complement.

Yuliy 2010-02-22 22:48:53

+5 A:

If a value is represented as sign-and-magnitude instead of two's complement, the sign bit being one with all other bits as zero is equivalent to -0. In sign-and-magnitude the maximum positive integer and negative integer are the same magnitude. Two's complement is able to represent one more negative value because it doesn't have the same symmetry.

2010-02-22 22:20:27

~~c++ uses two-s compliment for signed integers. Thus the smallest signed integer is defined by 100..00 (usually 32 bit).~~

Simply shifting 1<<(sizeof(int)*8-1) should give you the smallest signed integer.

Obviously for unsigned integers, the smallest is 0.

edit: you can read more here
edit2: apparently C++ doesn't necessarily use two-s compliment, my mistake

tzenes 2010-02-22 22:21:48

"c++ uses two-s compliment for signed integers" I don't think this is true. It's implementation defined.

GMan 2010-02-22 22:23:26

My mistake, you are correct, it is implementation defined.

tzenes 2010-02-22 22:46:40

@GMan: Quite. C++ will use whatever its hardware integer math units give it. If that happens to be *one's* compliment, then that's what it has.

T.E.D. 2010-02-22 22:55:52

+3 A:

The value of numeric_limits<int>::min() is defined by implementation. That's why it could be different. You shouldn't stick to any concrete minimal value.

Kirill V. Lyadvinsky 2010-02-22 22:21:48

This. In practice it's often defined by machine architecture, but you could make a standard-conforming compiler that did it's own bit twiddling to represent negative numbers.

gnud 2010-02-23 01:12:55

On cplusplus.com you forgot to read the qualifier

min. magnitude*

This is not necessarily the actual value of the constant in any particular compiler or system, it may be equal or greater in magnitude than this.

KitsuneYMG 2010-02-22 22:26:11

ansaurus

tags:

views:

answers:

Why numeric_limits<int>::min() is differently defined?

related questions