UBASE: The Bug ... still there after all these years!
in [HP48]
|
Prev: Little logarithm problem
Next: Firmware load location
From: Kim DeVaughn on 17 Jul 2010 18:40 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 18 Jul 2010 01:43 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 23 Jul 2010 10:31 This seems like a faster, more rational fix. 1_kg UBASE 1_kg UBASE SAME
From: Crawl on 23 Jul 2010 10:38 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 25 Jul 2010 03:45
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 |