Why the Range of Int is less by one at positive side?.........

[Harshan]

The range of signed int is - 2^15 to + (2^15 )-1 (-32768 to 32767) Why
the one less at positive Range ? (compared to the negative side..!)
I came to know that it uses 2's compliment internally for storing the
negative numbers . why it uses 2's compliment but not the ones compliment
for storing the negative numbers ?

 

[Karthik Kumar]

The range of signed int is - 2^15 to + (2^15 )-1 (-32768 to 32767) Why
the one less at positive Range ? (compared to the negative side..!)

because we need to represent the number 'zero' as well.

I came to know that it

What is 'it' ? Are you referring to the implementation.

uses 2's compliment internally for storing the
negative numbers . why it uses 2's compliment but not the ones compliment
for storing the negative numbers ?

This is entirely dependent on the machine / implementation.
And ansi C does not have any say on this.

 

[sushant]

harshan,

it is less by one bcos it takes zero into account when
positive numbers are taken care of. i.e. if u want to have
10 smallest non negative numbers it'll b frm 0 -9 not 1-10.
thats why at the positive range its one less than as expected

 

[Lawrence Kirby]

The range of signed int is - 2^15 to + (2^15 )-1 (-32768 to 32767) Why
the one less at positive Range ? (compared to the negative side..!)
I came to know that it uses 2's compliment internally for storing the
negative numbers . why it uses 2's compliment but not the ones compliment
for storing the negative numbers ?

The C language permits a 1's complement or sign-magnitude representation
of signed integers in addition to 2's complement. Your compiler uses 2's
complement almost certainly because that is what the processor it is
targetting uses. Modern processors tend to use 2's complement because it
has some nice properties and can simplify the hardware design (e.g. you
can avoid separate instructions for signed and unsigned addition and
subtraction). An obvious issue with 1's complement and sign-magnitude is
2 separate representations for the number zero.

Lawrence

 

[Harshan]

yes
i think this is coorect because of 2 zeros in 1's compliment . they are
taking 2's compliment for representation of -ve numbers and that consumes
one number for representing zero , but the negative side it is not consuming
the number so it will be 8000 to ffff -ve side and 1 to 7fff +ve
side in hex representation .

but i found that if you exceed the range value the compiler will take wrap
the value , it is somthing circular style.

 

[dandelion]

but i found that if you exceed the range value the compiler will take wrap
the value , it is somthing circular style.

\The\ compiler does not exist. \Your\ compiler (whatever it is) does.
Probably any HW with 2's complement will result in simular behavior, but in
fact, overflowing a signed integer results in undefined behavior, so do not
count on this behavior. I may be *very* different for another
processor/compiler.

PS. Does anyone know any *modern* processors with anything but 2's
complement encoding of signed integers? I can't remember ever running into
one.

 

[Michael Wojcik]

PS. Does anyone know any *modern* processors with anything but 2's
complement encoding of signed integers? I can't remember ever running into
one.

I think some processors still support packed decimal in hardware, but
that's in addition to 2's-complement. Which is good, since p-d isn't
a pure binary representation, so a C implementation on a p-d-only
machine would have to emulate all the integer operations.

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think some processors still support packed decimal in hardware,

Yes, the zSeries mainframe (of the System 360/370/390 line) still supports
packed decimal in hardware. Most mainframe languages support these native bcd
datatypes directly in the language.

but
that's in addition to 2's-complement.

IIRC, BCD support on IBM mainframes originally was an option; you could order
the original 'basic' system with binary integer support only, a 'scientific'
system with binary integer and floatingpoint support or a 'business' system with
binary integer and BCD support. The "System 360" changed that by incorporating
both the 'business' and 'scientific' support into one hardware architecture.
Legend has it that the system was named "360" because it was an 'all
encompasing' processor, and the name alluded to the 360 degrees of a complete
circle representing the complete circle of basic, business and scientific computing.

Which is good, since p-d isn't
a pure binary representation, so a C implementation on a p-d-only
machine would have to emulate all the integer operations.

- --
Lew Pitcher
IT Consultant, Enterprise Data Systems,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFB9TtEagVFX4UWr64RAuUsAKCT/nW+GjHQaRhHffN4QgzA/K3orQCg8CZU
gC23OnjwVDSsFCQtA5xUay0=
=LHK+
-----END PGP SIGNATURE-----

 

[Mike Wahler]

The range of signed int is - 2^15 to + (2^15 )-1 (-32768 to 32767)

It might be for your implementation, but the range required by
the C standard is -32767 through 32767 inclusive (but an implementation
is allowed to provide a larger range.

Why
the one less at positive Range ? (compared to the negative side..!)

Because apparently your implementation takes advantage of its
specific representation for integers.

I came to know that it uses 2's compliment internally for storing the
negative numbers . why it uses 2's compliment but not the ones compliment
for storing the negative numbers ?

Because that's what its authors decided to do. The language
standard allows one's complement, two's complement, or
signed magnitude.


-Mike

 

[Joe Wright]

It might be for your implementation, but the range required by
the C standard is -32767 through 32767 inclusive (but an implementation
is allowed to provide a larger range.





Because apparently your implementation takes advantage of its
specific representation for integers.




Because that's what its authors decided to do. The language
standard allows one's complement, two's complement, or
signed magnitude.


-Mike

It's what the authors of the CPU's accumulator decided to do.

 

[Nicolas Pavlidis]

The range of signed int is - 2^15 to + (2^15 )-1 (-32768 to 32767) Why
the one less at positive Range ? (compared to the negative side..!)

Becase 0 (Zero) is also a number ;-), and someone decided Zero to be a
positive number, so we have:
-2^15, 0 (Zero), 2^15 - 1

BTW hwat you showed was the rage of a signed _short_ not a signed int
;-)

I came to know that it uses 2's compliment internally for storing the
negative numbers . why it uses 2's compliment but not the ones compliment
for storing the negative numbers ?

AFAIK there can happen collisions with other numbers if the mashine only
uses ! - complement of a number to represent the negative "compliment"

Kind regads,
Nicolas

 

[Mike Wahler]

It's what the authors of the CPU's accumulator decided to do.

While it is probably most commonly done, the C language doesn't
require that an implementation use the same representation
as does the CPU.

-Mike

 

[Joe Wright]

While it is probably most commonly done, the C language doesn't
require that an implementation use the same representation
as does the CPU.

-Mike

Respectfully, nonsense.

C allows one's complement, two's complement and signed magnitude only to
accommodate CPU's structured that way. It would be unusally perverse for
an implementation to 'convert' to/from the CPU's natural representation
to another.

Do you know of an implementation which which does?

 

[xarax]

Respectfully, nonsense.

C allows one's complement, two's complement and signed magnitude only to
accommodate CPU's structured that way. It would be unusally perverse for an
implementation to 'convert' to/from the CPU's natural representation to
another.

Do you know of an implementation which which does?

Depends on your definition of "natural". The IBM Mainframe
supports both two's complement and binary coded decimal (BCD)
integers. There are machine instructions for converting
between the two formats, as well as machine instructions
for performing the usual operations, like comparing,
addition, subtraction, multiplication, division. So, a
C compiler for that platform could be implemented to use
BCD for "natural" integer represention (although it would
be insane for a commercial compiler).

 

[Mike Wahler]

Respectfully, nonsense.

Really? If what I wrote is 'nonsense', that indicates that
the C standard imposes such a requirement. If you feel that
it does, please cite it.

C allows one's complement, two's complement and signed magnitude only to
accommodate CPU's structured that way. It would be unusally perverse for
an implementation to 'convert' to/from the CPU's natural representation
to another.

The C standard does not prohibit 'perversion'. Just look at
the IOCCC.

Do you know of an implementation which which does?

No I don't, nor was I claiming that any do (nor that none do).
I'm only claiming they're not prohibited from doing so.

Also see 'xarax's reply.

-Mike

 

[Keith Thompson]

Becase 0 (Zero) is also a number ;-), and someone decided Zero to be a
positive number, so we have:
-2^15, 0 (Zero), 2^15 - 1

No, nobody decided that zero is a positive number, because it isn't.
Zero is a non-negative number. In a 2's-complement representation all
non-negative numbers have the sign bit set to 0, and all negative
numbers have the sign bit set to 1.

BTW hwat you showed was the rage of a signed _short_ not a signed int
;-)

That depends on the implementation. Both short and int are required
to have a range of at least -32767 .. +32767; there are plenty of
implementations where both short and int are 16 bits.

AFAIK there can happen collisions with other numbers if the mashine only
uses ! - complement of a number to represent the negative "compliment"

Both signed-magnitude and 1's-complement representations have two
distinct representations for zero, referred to as -0 and +0. This
probably requires a little extra work (either in hardware or in
software) to keep things consistent; for example, the two
representations must compare equal.

 

[Flash Gordon]

\The\ compiler does not exist. \Your\ compiler (whatever it is) does.
Probably any HW with 2's complement will result in simular behavior, but in
fact, overflowing a signed integer results in undefined behavior, so do not
count on this behavior. I may be *very* different for another
processor/compiler.

PS. Does anyone know any *modern* processors with anything but 2's
complement encoding of signed integers? I can't remember ever running into
one.

Even if the processor uses 2s complement there is not guarantee it will
wrap. The DSPs from TI that I have programmed have a saturation mode
where overflow results in the maximum value in whichever direction you
are going.

 

[Michael Wojcik]

So, a C compiler for that platform could be implemented to use
BCD for "natural" integer represention (although it would
be insane for a commercial compiler).

That would be a non-conforming implementation. The Standard requires
a "pure binary" integer representation. In C90 that's in 6.1.2.5.

A C implementation could offer BCD arithmetic as an extension, of
course.

 

[Ben Pfaff]

A C implementation could offer BCD arithmetic as an extension, of
course.

Or it could do decimal floating point.

 

[Keith Thompson]

Or it could do decimal floating point.

Which is a separate issue. Integer types are required to be pure
binary. Floating-point types (as far as I know) are not.

I think the requirements on floating-point representations are less
stringent than those on integers because there's a greater variety of
floating-point representations in the real world. (The world seems to
be converging on 2's-complement and IEEE floating-point, but of course
C has to support systems that haven't joined the convergence.)