Link to home
Start Free TrialLog in
Avatar of Stephen Kairys
Stephen KairysFlag for United States of America

asked on

What is negative 32768 for 16-bit ints?


Just curious.
When testing a routine, I encountered the following that relates to this code:

int foo; // here int is 16-bits, of ranger -32768 to +32767

foo = =32768;
foo *= -1;
printf("foo is now %d\n", foo);

here, foo still is -32768: the value has not changed.
Now, I know you cannot have +32768 in the 16-bit world, but I'm trying to understand
what's happening here. When you multiply by -1, you are changing the SIGN BIT,
so how can the value remain the same?

Thanks
stevefromc

ASKER CERTIFIED SOLUTION
Avatar of PaulCaswell
PaulCaswell
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Stephen Kairys

ASKER

OK, sounds good, but I just tried it for the number 1,

1 = 00000001
invert gives 11111110
add 1 gives 11111111

which is actually -1, right? If this var. were UNSIGNED it would be 255 (the highest possible
value of an 8-bit), so if it were signed it must be -1 (the first value "below" 0).

Did I get it :)  ?

Thanks
Spot on!!!!

The crucial point is that this behaviour happens across the whole spectrum of possible numbers except at each end just because -0 must be the same as 0.

Paul
Negative 0. What a concept! Wonder if you can divide by it ;)

Seriously, though, thank you for an informative and interesting answer. Raising points
from 50 to 100.

stevefromc
Hi PaulCaswell,
> -0 must be the same as 0
Now that's interesting. I never saw the '+1 bias' of neg that way.

Cheers!

Stefan
Mmmmmmm!!!!!!! Glad to be of service!!!!!!
Avatar of Kent Olsen

Hi StevefromC,

Actually, the concept of negative 0 has been around for a long time.  It's found in 1's complement architecture, where the negative value of any positive integer is obtained simply by toggling all of the bits in the word.

000000000000001 = 1
111111111111110 = -1

000000000000010 = 2
111111111111101 = -2

etc.  Hence,

000000000000000 = 0
111111111111111 = -0

When there were lots of vendors making room-sized computers, there was a huge argument among engineers as to which was better.  Both -0 and negative values that aren't bit complements of their positive values are abstractions so both sides had good arguments. To me, having a "negative 0" bit pattern that tests true for both negative (which tests only the sign bit) and zero (which tests that all bits are the same) makes more sense than the logical complement not equalling the arithmetic complement.

A couple of things to note.  When used as a operand, negative zero behaves exactly like positive zero.  Divide by it and generate a fault.  Add it and get the value of the other operand, etc...  The arithmetic units of those computers would not generate a negative 0.  You could only do that via the shift or boolean units.


Kent
Thanks Kent, its good to feel that there is at least one other old codger out there although I have to admit I wasnt quite a programmer when the 'room-sized' guys were around. I have seen ferrite-ring 'core' in wooden frames in a working computer. It was about 'half-room' sized and it was a typesetter (an APS micro 5) about 15 years ago.

Paul
Thanks for the info, Kent.  

Btw, and this sort of dates me, I wrote my first program back in 1974 on an IBM1130 in
8th grade, in BASIC. We fed in the interpreter through punch-cards, and typed in the program
w/o, as I recall the ability to save, and a rather small limit to the size of the program.

To say nothing of typing in my first FORTRAN program on punch-cards :)

What a day.  I get called an old codger by Paul (who is due congratulations for making the top 10!) and am then reminded of my "seniority" by Stete.

Kids.....  :)



BTW, my first real experience with real computers was in college in 1974.