Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!att!cbnewsb!druhi!neal
From: neal@druhi.ATT.COM (Neal D. McBurnett)
Newsgroups: comp.sys.handhelds
Subject: HP48 thinks -3 in binary is zero!
Message-ID: <576@cbnewsb.ATT.COM>
Date: 30 Jun 90 22:40:10 GMT
Sender: news@cbnewsb.ATT.COM
Reply-To: neal@druhi.ATT.COM
Organization: AT&T Bell Laboratories, Denver
Lines: 32

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.

This problem arose in the following situation.  I want to keep track
of the cumulative error in the internal clock, so I wrote a program
"TADJ" as a replacement for the standard CLKADJ function which
adjusts the internal clock.  TADJ takes an adjustment in seconds
and both modifies the internal clock via CLKADJ and keeps track of
the cumulative error by incrementing a global variable "OFFSET".
OFFSET is a binary integer because I usually use it in conjunction with
the result of TICKS, which is binary.

Here is TADJ:
  << 8192 * DUP CLKADJ
	'OFFSET' STO+
  >>

This works fine for positive arguments, but when I try "-10 TADJ" I
end up adjusting the internal clock, but "OFFSET" is unchanged!

I can't think of any justification for this.  It is also a royal
pain to get around it.  I can't simply convert the binary to a real
number before doing the arithmetic, because it is a huge number
(related to the number of clock ticks since the year zero, just like the
output of TICKS....) and precision would be lost.  I guess my best
bet is to use << +/- STO- >> if the argument is negative.  Sigh.

HP, can you fix this in a future ROM?

-Neal McBurnett, neal@druhi.ATT.COM, AT&T Bell Labs, Denver.