Prev: Little logarithm problem
Next: Firmware load location
From: John H Meyers on 29 Jul 2010 02:06
On the confused meaning of "UBASE bug":

The OP's original issue comes about simply because
there are "equivalent" unit (composite) objects
whose internal structure is not identical;
thus two equivalent unit objects
are not necessarily the SAME.

There are even simpler examples,
such as this (manufacturing an object
from its "hex string" decomposition
using H\-> from internal "development" library 256):

"47A20339200000000000000010B2130"
DUP BYTES DROP #BE42h ==
#100001h * LIBEVAL

What you see on the stack: { 1. }

Now enter another { 1. } yourself.

Now type SAME ==> result is 0

The first list contains an actual real number object.

The second list contains a "supported" (always the same)
ROM address (PTR) of an equal-valued real number object
(the calculator almost always prefers to make these
substitutions automatically, to create smaller objects).

One of the original principles of HP's RPL
is that addresses of objects can represent objects indirectly,
so this ends up permitting various different possible "composite" objects
(lists, unit objects, algebraic objects, and program objects)
to be equivalent, without being precisely identical.

However, this is not the "UBASE bug,"
as I understood the original issue on original HP48S/G calculators.

What I had found, way back then,
was that unit objects resulting from 1_r UBASE or 1_sr UBASE
performed on one calculator (HP48GX ROM version "M")
could not be transferred to another calculator (HP48GX ROM version "R"),
because each object turned out to contain
a NON-supported and NON-stable ROM address,
and in each case the address in the "R" ROM
differed by 1 from the address in the "M" ROM.

You could say "close, just no cigar" -- however, during the actual
evaluation of objects, the "RPL interpreter" actually executes
whatever is found at such ROM addresses, as CPU (Saturn) instructions,
which could lead to complete crashes and even loss of all stored data,
which could be a pretty serious "bug"

The address of the "k" in 1_kg UBASE was also non-supported,
but it seemed to have remained the same in both HP48GX ROM versions
as it was in the HP48SX, so that case made no difference,
unlike the "1 nibble slip" in the location of the string constants
for the other, rarer units.


During the development of "Vger" (HP49G), one of the team members
asked me to remind him about some HP48GX bug like this,
and I believe that I sent along a link to the original post
about this "UBASE bug."

Well, fast-forward by more than a decade,
and we can see that all of the above seems to have been
carried over unchanged into the HP49/50 series, in that
"unsupported" ROM addresses (PTR xxxxx) creep into
each one of the same UBASE cases as in the HP48S/G series.

This is not what caused the OP's original program to fail,
since his objects would not have been the SAME
even if a "supported" ROM address had been used for "k"
(there was still another difference between the objects,
where UBASE provides entry point tok_g instead of explicit string "g"
as is perfectly acceptable and reasonable), but we've found out,
by deeper exploration, that probably the same original UBASE code
may have been carried over into the HP49/50 series --
and why not, since the idea was to add new things (MK and CAS)
to a product that seemed already to have been thoroughly debugged
and working fine, without starting over from the beginning.

We do not know, however, whether this behavior of UBASE
is actually a "bug" in the HP49/50 series -- it would be
the same original "bug" only if the unsupported PTRs
generated by UBASE "move around" between different ROM versions,
and if they do move around, the nature of the "bug" would be
that one ROM version could produce objects that would either
simply be invalid when interpreted by another version
or might go as far as crashing other versions when evaluated,
but none of these cases would have anything to do with
the unexpected result of SAME in the OP's original program!


Meanwhile, to do what the OP wanted (to check whether
two unit objects on the stack have compatible units),
the fastest way may be to apply CONVERT and trap any error.

CONVERT should not only be faster than subtraction,
but also accepts only unit objects and pure number arguments,
thus providing assured "object type checking" at the same time.

No need to bother with UBASE at all, nor to try UBASE ==
(the == command itself, when employed on unit objects,
calls the same internal functions as CONVERT,
which could be used directly to begin with).

In short, the goal (check for units compatibility)
does not call for employing UBASE at all,
and is best achieved by a completely different approach.


Amplify this to larger scale world events,
and we have trillions of dollars and so many thousands of lives
thrown at problems which those things don't solve either,
all based on not knowing simpler and better things of great effectiveness,
so why should we do anything more reasonable when it comes to our calculators?

As Mark Twain wrote, about 100 years ago, during which almost nothing has changed:
http://www.spring-ford.net/staff/jfari/documents/The%20Damned%20Human%20Race%20by%20Mark%20Twain.pdf

Best wishes from http://www.mum.edu
and http://www.maharishischooliowa.org

[r->] [OFF]

From: Kim DeVaughn on 3 Aug 2010 04:52
John H Meyers <jhmeyers(a)nomail.invalid> writes:
>
> On the confused meaning of "UBASE bug":

OK ... how about UAB (Undocumented Anomalous Behaviour) of the
UBASE command then ... :-) ...?

Anyway, thanks very much for the in-depth analysis of this unusual
"feature" in your two very detailed postings ... I have a lot better
understanding of it (though some of the gory details are beyond my
knowledge-level, ATT).

I'm not at all clear on HP's motivation in creating multiple forms
of objects that purport to be the same thing (eg, TYPE 13), but
really aren't. Was it just to save a bit of memory here and there,
or for performance reasons, or ???

Perhaps this explains the use of some weasel-words in the AUR on
p. 3-215 for the SAME cmd, WRT unit objects:

"SAME is identical in effect to == for all object types except
algebraics, names, and some units."

Note the reference (without any elaboration) to "some units".

Ah, well ... at least there are a few ways around the problem (once
one knows that the problem exists). Thanks also for your alternate
methods for determining if two unit objects are "equivalent".


The question now is which of the emulators, etc. mimic the "proper"
operation of the UBASE and/or SAME commands (with "proper" being
defined as the way the calculator does it).

I would check into this, but I have been quite unsuccessful at
getting any such programs to run on Win7 (64-bit). I do see that
there is a new version of Debug4x that specifically mentions Win7
and 64-bits. And I think I may have found newer USB drivers than
came on the DVD with the 50g at HP's very own website (mayhaps I'll
actually get Conn4x working now). Then on to Emu48. Maybe.

Thanks again for all the info!

/kim

--
=========================================================
"Some days even a blind pig finds an acorn." --Unknown
First  |  Prev  | 
Pages: 1 2 3
Prev: Little logarithm problem
Next: Firmware load location