Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!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: <59214@eerie.acsu.Buffalo.EDU>
Date: 12 Feb 91 01:56:31 GMT
References: <1991Feb9.185644.17146@nntp-server.caltech.edu> <59197@eerie.acsu.Buffalo.EDU> <10768@jarthur.Claremont.EDU>
Sender: news@acsu.Buffalo.EDU
Organization: State University of New York @ Buffalo
Lines: 38
Nntp-Posting-Host: lictor.acsu.buffalo.edu

In article <10768@jarthur.Claremont.EDU> sburke@jarthur.Claremont.EDU (Scott Burke) writes:
>
>But how do you deal with the analogous problem with unit objects, namely:
>
>1_m DUP UBASE SAME yields a 0, not a 1, because for some reason the UBASE
>argument is different.  I'm not into internals, but the same behavior is
>occuring here, I think.  My (clumsy) solution was to do something along the
>lines of { "'1_m'" } blah blah UBASE \->STR POS to check if I had the 
>appropriate or desired unit.
>
>Ideas on how to convert 1_m to 1_m?  ;-)
>
>Scott.
>sburke@jarthur.claremont.edu

Hmmm.  This is apparently in response to my response.  About the unit
objects, in my previous articel where I explained (I hope) everything that
I discovered about how they are put together, I mentioned that there is a
list at #FA53h (in version A, at least) that contains { 1_kg 1_m 1_A 1_s
1_K 1_cd 1_mol 1_? } and that the output from UBASE uses pointers to each
of the strings and the Character 'k' w/in the unit objects w/in that list
in place of inline, RAM copies of those elements.  I would presume taht
this is done either for code-size or execution-speed related efficiency.
The end result is that you have to UBASE any unit objects that you want to
compare with a UBASEd unit object via SAME.

So, to compare 100_cm with 1_m, using SAME, use: 100_cm UBASE 1_m UBASE
SAME, for instance.

Please excuse any typo's, etc in this article.  I'm getting an unexplained
profusion of \377's (octal) in my EMACS mode line and whatever is causing
it is also causing otehr problems, including a HUGE performance loss.

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