Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!uwm.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!execu!sequoia!memqa!r91400
From: r91400@memqa.uucp (Michael C. Grant)
Newsgroups: comp.sys.handhelds
Subject: Re: HP48 thinks -3 in binary is zero!
Message-ID: <4060@memqa.uucp>
Date: 2 Jul 90 12:15:47 GMT
References: <576@cbnewsb.ATT.COM>
Organization: Memory R&QA, Motorola SPD
Lines: 26

In article <576@cbnewsb.ATT.COM>, neal@druhi.ATT.COM (Neal D. McBurnett) writes:
> I was shocked to discover that adding #5h and -3 yields #5h!
> Upon further inquiry, it turns out that << -3 R->B >>  produces #0h.
> I would expect it to produce the two's complement value using the
> current wordsize, e.g.  #FFFDh.

It was my understanding that binary/hex/octal/decimal numbers (the ones
with '#' preceding them) were unsigned integers.  Thus, -3 would indeed
convert to #0h, or result in an error (which I would personally prefer).

Allowing signed numbers of this type would produce inconsistencies if
you changed the width of the number in mid-calculation.  For example,
if you had set the width to 8, typed the number
#11110000b
into the calculator, and then changed the width to 16, what would happen?
Well, I personally prefer 
#0000000011110000b
instead of the other alternative--sign extension.

Perhaps the easiest way to get around this problem would be to write
your own version of a two's complement routine, and convert ALL of your
numbers that way, so that any negative numbers would be converted properly.
I'd give you the program but I don't have my calculator handy (and I'm
not very good at remembering the keywords).

Michael C. Grant