UBASE: The Bug ... still there after all these years!
in [HP48]
|
Prev: Little logarithm problem
Next: Firmware load location
From: Han on 27 Jul 2010 18:22 On Jul 23, 10:38 am, Crawl <crawland1...(a)lycos.com> wrote: > 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. Why not just do: 1_N 1_m / 1_s^2 * UBASE 1_kg == This gives 1. I don't know if I would call this a UBASE bug. Objects on the stack are referenced by pointers. The SAME command is not your typical comparison test. It checks whether two objects are identical. Two objects may occupy different memory blocks (and have different reference pointers), but be encoded with the same bit patterns. Rather than using SAME, perhaps you should use == to test whether the two objects are equivalent (e.g. 4/4 is equivalent to 1). The == command actually handles two units (it calls the entry UM=?) and correctly determines if two units are equal. You can even do << 1_N*s^2/m 1_kg == >> and it will correctly return 1.
From: Han on 27 Jul 2010 18:23 > Why not just do: > > 1_N > 1_m > / > 1_s^2 > * > UBASE > 1_kg > == I meant to write: 1_N 1_m / 1_s^2 * 1_kg ==
From: Han on 27 Jul 2010 18:40 The bug that is referred to by John's post is technically a bug in compatibility (not the command UBASE), and on the HP48GX series only. The G series were advertised to be compatible with the S series as far as UserRPL was concerned, but due to changes in addresses, this is not the case when using binary transfers between the machines. (Were the G series advertised as being binary compatible with the S series?) An ASCII transfer ("source compatible") would eliminate the errors which John described when transferring between the S and G series even if units were converted with UBASE. The same applies to the newer series, which as far as I know, were advertised only as "source" compatible. Out of curiosity, why would using == not work for your program? The == is actually more robust than the SAME command (and == defaults to SAME, as John explained in his older post).
From: John H Meyers on 27 Jul 2010 22:09 On 7/27/2010 5:40 PM: > Out of curiosity, why would using == not work for your program? Did you not explore both possible outcomes of that test? 1_m 1_s == Error: Inconsistent Units To continue the program, as desired, you would have to trap this error (which we will illustrate, below) > The G series were advertised to be compatible with the S series as far > as UserRPL was concerned, but due to changes in addresses, this is not > the case when using binary transfers between the machines. Whatever the original "UBASE bug" was, that's not quite the problem in the original post, where the OP gave this example, all on HP50G, simply by performing UserRPL commands: > Easy way to see the "bug" [well, some subtle pitfall in programming]: > > 1_kg > UBASE > 1_kg > SAME ==> 0. [should be 1.] Surprise! -- but there's a reason: The two stack objects here, when de-compiled to SysRPL, are: UNIT %1 PTR 2D841 tok_g umP umEND ; (including a possibly version-dependent PTR, whose value is CHR \6B -> "k" rather than supported entry point CHR_k or a supported character object) [was such version-dependency the original "bug," after all?] UNIT %1 CHR \6B "g" umP umEND ; (second object on the stack) tok_g is also a supported PTR whose value is "g" -- but as you can see, the entire structure differs, despite "looking alike," and could still be, even if that PTR were "supported" or U.B.S., so that SAME doesn't do what the OP expects. But then, [ 1. ] DUP AXL AXL produces other things that "look alike," yet are even different object types! The OP's original idea seems to be that "look alike" on the stack should have meant "the same," but now we realize that things may be different, inside, than they look on the outside. If, for some purpose, "look alike" is close enough, then "look alike" is about the same thing as "will be the SAME after \->STR" which seems true enough, even though two "user binary" objects which aren't really the SAME can turn out to be "equal" via == whether because of binary word size truncation, or even if the "binary word size" is 64, but that's a story for another day :) If you want to see whether two unit objects have consistent units (which seems to have been the OP's original quest), there are numerous ways, e.g. you can perform subtraction, and if you get no error, then the units are consistent; this is probably faster than using steps which de-compile and re-compile. To test whether units are consistent and return T/F (1/0), for example: \<< -55. CF DUP2 IFERR - THEN DROP2 0. ELSE DROP 1. END \>> (don't forget that flag -55 and IFERR are importantly related) You can also test using CONVERT in place of subtraction, which, like subtraction, still accepts unit-less pure numbers. You can also simply ignore the need to test, because, sooner or later, the program will calculate something using the inputs, and will surely also get an "Inconsistent Units" error when it does. What can we learn by such explorations on our math toy? o "Looks aren't everything" o "Compatibility is more important" o "If we don't check compatibility now, we can just get divorced later" ;-) P.S. - apparently there might still be a chance to get version-dependent, non-supported results from UBASE (any other commands?) within _this_ calculator series, re the "character objects" embedded within unit objects -- should we check all 49/50 series ROM versions to date, to find out whether or not _all the possibilities_ are "U.B.S."? Glossary: U.B.S. == "Unsupported But Stable" If not U.B.S. then even same-series binary transfers could be hazardous, like some of W.R.'s powerful, minimal-size, but possibly crashing functions :) [r->] [OFF]
From: Han on 28 Jul 2010 01:29
> 1_m 1_s == > Error: Inconsistent Units Ahh, I see now =) A good whack on the head with a clue-stick always does the trick. |