Number confusion

[NoCforMe]

I've been programming for what, 40 years or so? But I still get stumped by what should be stupid simple things.

Like twos-complement representation of numbers.

OK, in another thread we were discussing how to take the absolute value of a number. I posted this well-known method (I think I saw it in one of Raymond Chen's blog posts):

Code Select Expand

    cdq
    xor    eax, edx
    sub    eax, edx
It seems to work. However, it also seems to fail on at least one value:

Code Select Expand

abs(2147483647) (7FFFFFFFh) = 2147483647
abs(-2147483648) (80000000h) = -2147483648
abs(-2147483647) (80000001h) = 2147483647
abs(-2147483646) (80000002h) = 2147483646OK, review for dummies (me) here:

• The largest signed 32-bit number is 2147483647, right?
• The smallest signed 32-bit number is -2147483648, right?

So why does this abs() method fail on that smallest value?
It works on the next-largest value (-2147483647).
I'm using wsprintf() to display this stuff, using %d for the decimal values. So is it 1) showing the wrong value for abs(-2147483648), or 2) is my abs() failing on this value?

Signed,
Puzzled

[NoCforMe]

OK, glimmer of understanding here:
If we're trying to take abs(-2147483648), that means the expected result will be 2147483648, right?
Except that that's larger than the largest valid signed 32-bit number (2147483647). So we can't do that.
So how is it that we cannot get the absolute value of the smallest signed 32-bit number? Doesn't that leave a hole in the whole scheme?
I can make it "work" in my testbed program by using %u instead of %d to display the result. But that's cheating, right?

All this signed/unsigned business is making my head spin ...

[NoCforMe]

... unless we always treat the result of abs() as an unsigned number ...

[alCoPaUL]

HEX((maxed positive x 2) + 1 element(0)) = FFFFFFFF <~ Cap on Abs()

not value but size..

[NoCforMe]

OK, I think I've got it figured out:

"My" abs() works fine:

Code Select Expand

abs PROC
CDQ
XOR EAX, EDX
SUB EAX, EDX
RET
abs ENDP
The result should be interpreted as an unsigned value.

The case of abs(80000000h) is kind of an anomaly:
The result of the function in this case is exactly the same as the input.
This is the one value where the absolute value of the input is outside the range of valid signed numbers; in other words, it's not "reversible".
With all other values you can negate them and end up with a valid signed value.
That doesn't work with this one value.

Amiright?

[daydreamer]

I know how two complement work,because exercises in electronic class build circuits based on nand gates that does add and modify it to does sub
After already have add,sub is made by adding two complement circuitry to adder circuitry
Pong and breakout is easier with x86 neg when bouncing,6502 had no neg opcode

[tenkey]

The case of abs(80000000h) is kind of an anomaly:
The result of the function in this case is exactly the same as the input.
This is the one value where the absolute value of the input is outside the range of valid signed numbers; in other words, it's not "reversible".
With all other values you can negate them and end up with a valid signed value.
That doesn't work with this one value.

Amiright?

Yes, that's right.

That is the one disadvantage of two's complement -- it's asymmetry. The main advantage is one zero value. To make a symmetric representation, you add a minus zero, giving you two zero values.

[NoCforMe]

Thank you; your reply is appreciated.
I was starting to wonder if this whole thread was just a monument to my stupidity. Apparently I'm not as dumb as I thought ...

[tda0626]

I've been programming for what, 40 years or so?

Wow, that is awesome.

[TimoVJL]

In the early 80s, programming became widespread with the advent of personal computers.

EDIT:
BASIC and Pascal was used in programming courses at that time, when i was at technical school, 81 - 83.
Assembly programming course was with Motorola 6800 system.
Just too long to remember those old things.

[NoCforMe]

My introduction to computing was on a mainframe (Univac), ca. 1982. BASIC.

[raymond]

For those who may not have seen or remembered some of my old posts, my introduction to computing goes back to the early 70's. From a technical point of view it would have been on a main frame, but accessed through timeshare terminals using the Fortran language. My only purpose at the time was to write a program for a warehouse inventory control.

The next attempt at programming was much later when I purchased a TRS-80 in a garage sale back in 1985. It came with a book for the Basic language but I soon discovered "machine language" which was running so much faster that I was sold to assembly for the rest of my life. After buying a PC-XT, it was 16-bit DOS at first but later convinced by Hutch to go for 32-bit MASM.

Now way too old to get involved with 64-bit systems.    

[daydreamer]

Now way too old to get involved with 64-bit systems.    

No need to be sad you x87 expert : 80 bit bigger than 64 bit :)

[NoCforMe]

I've said it before and I'll say (write) it again:
64-bit programming for me and I think it's safe to say a lot of the other coders around here is total overkill. Completely unnecessary and not worth the additional headaches and hassles.

I exempt the few professionals here who depend on 64-bit coding for their livelihood or for special programming needs (huge datasets, etc.). But for the rest of us, it's just not needed.

Hell, even 32-bit is overkill for a lot of the stuff I do (and I imagine what others here code). Sometimes a little-bitty 8-bit µprocessor is all that's needed to do the job.

[jj2007]

80 bit bigger than 64 bit :)

Yep, we owe lots of precious stuff to Raymond