From: Kim DeVaughn on
As John Meyers so elequently put it nearly TWELVE BLOODY YEARS AGO:

"Yes, there *is* a UBASE bug!"

It bit me last night, and took me several hours to track down. Since
I've not seen any mention of it lately, I thought I'd do so (and maybe
reduce my level of frustration with HP's inability to fix problems
over such a length of time in the process ... grrrr).

Oh, and I also wanted to mention a work-around I found that mitigates
the problem (at least it does so on my 50g, 2.15 ROM).

Easy way to see the bug:

1_kg
UBASE
1_kg
SAME ==> 0. [should be 1.]

What is going on here is described in detail in John's excellent
postings, which fortunately are available in:

"http://www.hpcalc.org/hp48/docs/misc/ubasebug.zip"

If one can, using == instead of SAME eliminates the erroneous result,
but I can't do that in my application (without a lot of fiddling), as
the units entered may well be inconsistent with the units tested
against, and I don't want == giving me an error when I do the test.

I found that the UBASE'd object will survive in its altered state
through various operations (*, /, etc). But the altered state does
NOT survive the object's being converted to a string.

So ... either of these inelegant, ugly work-arounds can serve as a
temp-fix until the HP engineers develop a proper solution (and yes,
I have a nearly-brand-new bridge for sale, too ... ).

To wit:

1_kg 1_kg
UBASE UBASE
->STR or ->STR
1_kg OBJ->
->STR 1_kg
SAME SAME ==> 1. [both correct]


Many thanks go to John for confirming my conclusion that UBASE has a
bug. Just wish I'd Googled-around for clues about 4 hours sooner ...!


Cheers ...

/kim


PS: FWIW, my 48sx behaves in an identical fashion, making this bug
at least 20 years old.

--
========================================================================
"Some days you eat the bear ... some days the bear eats you." --Unknown
From: Andreas Möller on
For other bugs see:
http://bugs.hpcalc.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=

And yes, there are more bugs than listed at Bugzilla.

Regards,
Andreas
http://www.software49g.gmxhome.de

From: Crawl on
This seems like a faster, more rational fix.

1_kg
UBASE
1_kg
UBASE
SAME



From: Crawl on
On Jul 23, 10:31 am, Crawl <crawland1...(a)lycos.com> wrote:
> This seems like a faster, more rational fix.
>
> 1_kg
> UBASE
> 1_kg
> UBASE
> SAME

I imagine what you're doing is trying to write a program to automate
checking if two units are the same after a calculation involving mixed
units. And, yeah, that approach works even then.

Eg.,

1_N
1_m
/
1_s^2
*
UBASE
1_kg
UBASE
SAME

gives 1.
From: Kim DeVaughn on
Crawl <crawland1000(a)lycos.com> writes:
>
> On Jul 23, 10:31�am, Crawl <crawland1...(a)lycos.com> wrote:
>> This seems like a faster, more rational fix.
>>
>> 1_kg
>> UBASE
>> 1_kg
>> UBASE
>> SAME

Yes, that's another solution, though for the most part, I like
keeping the work-around hack all together with the offending UBASE
command rather than somewhat spread-out. Easier to document what
is going on I think (as below).


> I imagine what you're doing is trying to write a program to automate
> checking if two units are the same after a calculation involving mixed
> units.

Not really. What I'm doing is trying to insure that the user input
a quantity in the proper units of some kind; in this case, mass (or
elsewhere, length, energy, etc).

The actual code snippet is:

...
...
<object on stack is user input, already tested to be of TYPE 13>
DUP
UBASE
->STR @ This hack is a work-around needed
OBJ-> @ to overcome a bug in the UBASE cmd.
DUP
-
0_kg
SAME
NOT
IF
THEN
DROP
"Fish tacos! Use mass next time."
DOERR
END
...
...


Also, with the "->STR OBJ->" hack, the unit object is actually
corrected to its proper form, and not left in some mangled
condition. So in some future program, where I may not use
the UBASE'd object right away, I won't have to track this thing
down again ... :-) ...!

Of course if the UBASE were being executed in an inner loop, we'd
certainly go for the better performing solution.


Cheers ...

/kim

--
=========================================================================
"First things first. But not necessarily in that order." --The Doctor
 |  Next  |  Last
Pages: 1 2 3
Prev: Little logarithm problem
Next: Firmware load location