dcf@zodiac.phy.duke.edu (09/29/90)
Units comparison problem: SAME doesn't behave consistently with units objects.
Consider the following:
<< '1_m' '1_m' DUP2 SAME 3 ROLLD == >>
This returns:
2: 1
1: 1
But
<< '1_m' UBASE '1_m' DUP2 SAME 3 ROLLD == >>
returns:
2: 0
1: 1
It appears that UBASE tags an object in some invisible way. When I do a
MEMORY BYTES on a plain 1_m and a UBASE 1_m I get different answers.
plain 1_m: #D2FCh UBASE 1_m: #E983h
16 12.5
Naturally, I want to avoid the "b" word, but what is going on here?
--
Daniel C. Flatin 1-919-684-8279
Duke University Dept. of Physics def@phy.duke.edu
Durham, N.C. 27706 billw@hpcvra.CV.HP.COM (William C Wickes) (10/02/90)
Daniel Flatin asks why 1_m and 1_m UBASE aren't the same, as tested by
SAME and BYTES. He is polite enough not to use the b word.
Use the i word, instead (for idiosyncrasy). The 48 has a substantial number
of objects that are built into ROM, which can be apparently identical
to objects created on the fly. For sake of memory efficiency, the
ROM objects are not copied into RAM when they are executed, but rather
are referenced by a pointer. In the case of 1_m UBASE, when UBASE
rebuilds a unit object from base units, the characters (in this case, the
"m") in the unit part are taken from a ROM table. 1_m created by
any other means has its "m" in RAM.
The upshot of all this is that the two unit objects are not identical.
SAME actually compares the bit patterns of two objects, so it reports
false. == looks at the logical values, and returns true. Likewise,
BYTES reports different sizes and checksums.
There are other cases similar to this. Try 1 'A' STO A 1 ->LIST {1} SAME,
which returns false.
The moral of the story is to use == to compare two unit objects. In general,
if you run into problems like this, use ->STR OBJ-> on both objects,
which will rebuild both in an identical manner.
Bill Wickes