Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu
From: cloos@acsu.buffalo.edu (James H. Cloos)
Newsgroups: comp.sys.handhelds
Subject: Re: Question about binary numbers and SAME  (HP-48)
Keywords: binary, SAME, Version E, bug
Message-ID: <59197@eerie.acsu.Buffalo.EDU>
Date: 12 Feb 91 00:21:47 GMT
References: <1991Feb9.185644.17146@nntp-server.caltech.edu>
Sender: news@acsu.Buffalo.EDU
Organization: State University of New York @ Buffalo
Lines: 56
Nntp-Posting-Host: lictor.acsu.buffalo.edu

In article <1991Feb9.185644.17146@nntp-server.caltech.edu> anderson@truebalt.caltech.edu (Eric R. Anderson) writes:
>
>  I was debugging a program last night when I ran into what seems to be
>strange behavior between binary numbers and SAME.  If I add two binary
>numbers, then place their sum on the stack, SAME returns 0 if the word
>size is less than 61, but 1 if the word size is 61 or greater.  Using
>== returns 1 for all values of word size.  For example, the sequence
>
>     #5d #10d + #15d SAME
>
>returns different values depending on the word size, while the same
>sequence with == replacing SAME always returns 1.  It behaves the same
>way for subtraction, multiplication, and division, and for hex, oct, and 
>bin modes.  According to the manual, SAME should work the same as == in
>this case, since I'm not comparing strings or algebraics.  It depends
>on what the word size was when the calculation was made, not when SAME
>was executed, so
>
>    61 STWS #5d #10d + #15d 60 STWS SAME
>
>returns 1.
>  Is this a bug, a feature, or the way it should work?  Any explanations?
>The calculator is an E version, by the way.    
>-- 
>Eric Anderson                                     eanderso@caltech.bitnet

I don't know if this would/should be considered a bug, but I'm not sure if
the manual explains this at all.  I'll explain what is happening
(empiracally, btw ;) and you can draw your own conclusions.  First of all,
binary integers (a.k.a. Hex Strings) are stored exactly like Strings
(a.k.a. Character Strings); only the prolog differs.  Second of all,
whenever you enter a binary via the command line, regardless of the word
size setting, it is created using 64 bits of storage (plus 5 nybbles for
teh prolog, plus five nybbles for the size).  The problem is that when
calculations are done on binaries, the result is created using only as many
nybbles as are required for the current wordsize.  (Ie, \<< WORDSIZE 4 / 0
RND 4 * \>> will return the number of nybbles needed for WORDSIZE bits.)
The result of all this is that, if the wordsize is less than 61, the
results of any calculations on binary integers will be less than 16 nybbles
long (excluding the prolog and size fields), and SAME will not recognize it
as being the SAME as a binary that was entered via the command line.

The way around this is to add #0 (or even 0) to the binaries that a)
haven't had any calculations done on them, & b) are to be used as arguments
for SAME.

Or, you can just add binaries to the list of strings and algebraics for
those data types for which SAME and == are not the same.

(Bill MIGHT have mentioned something along this line in _28_Insights._)

-JimC
--
James H. Cloos, Jr.		Phone:  +1 716 673-1250
cloos@ACSU.Buffalo.EDU		Snail:  PersonalZipCode:  14048-0772, USA
cloos@ub.UUCP			Quote:  <>