HP 32S: <= and >= comparisons
|
05-06-2015, 03:13 PM
Post: #1
|
|||
|
|||
HP 32S: <= and >= comparisons
Since the 32S lacks <= and >= comparisons, I'm trying to figure out the most efficient replacement. Are there better options than these? (GTO A is just an example; replace with your conditionally executed instruction of choice.)
x<=y: Code: x>y? x>=y: Code: x<y? Since the first comparison is the logical inverse of what we're looking for, and the second comparison (x=y?) will never be true if the first one is true, you're effectively writing "not x>y?" and "not x<y?", which are equivalent to "x<=y?" and "x>=y?" respectively. Are there any alternatives that are even more efficient, in terms of space or execution speed? |
|||
05-06-2015, 08:20 PM
(This post was last modified: 05-06-2015 08:50 PM by Dieter.)
Post: #2
|
|||
|
|||
RE: HP 32S: <= and >= comparisons
(05-06-2015 03:13 PM)Dave Britten Wrote: Since the 32S lacks <= and >= comparisons, I'm trying to figure out the most efficient replacement. That's simple. Composing new tests by combining two others was a common technique back in the days of the 65, 67/97 and 41. I think this has been discussed earlier, at least in the old forum. Including the combination of three or even more consecutive tests. ;-) Edit: just found it – here. (05-06-2015 03:13 PM)Dave Britten Wrote: Are there better options than these? Well, unless the desired test is available (= 1 step) it obviously won't get shorter and faster than two steps. Which is what you did here. On the '41 I usually emulate X≥Y by having X≠Y followed by X>Y. (05-06-2015 03:13 PM)Dave Britten Wrote: Since the first comparison is the logical inverse of what we're looking for, and the second comparison (x=y?) will never be true if the first one is true, you're effectively writing "not x>y?" and "not x<y?", which are equivalent to "x<=y?" and "x>=y?" respectively. It's even simpler than this, the logic for these composite tests is always the same: NOT first condition OR second condition. This way you can also test if, say X>Y or X<0 (e.g. for range checks). Which makes this technique useful even for calculators that offer the full set of tests against Y and 0. Another method is shown in example 2 of the linked forum article: use the inverse test and have it followed by another one that always tests false, thus inverting the previous test. So X≥Y is equivalent to X<Y followed by, say, FS? 1 while flag 1 is clear. Dieter |
|||
05-06-2015, 08:57 PM
Post: #3
|
|||
|
|||
RE: HP 32S: <= and >= comparisons
(05-06-2015 08:20 PM)Dieter Wrote: Well, unless the desired test is available (= 1 step) it obviously won't get shorter and faster than two steps. Which is what you did here. Yup, shorter is definitely a long-shot. I don't expect to get shorter than two steps, but for models where different instructions can potentially occupy a different number of bytes, there's a possibility for some savings there. As for speed, see below. (05-06-2015 08:20 PM)Dieter Wrote: On the '41 I usually emulate X≥Y by having X≠Y followed by X>Y. The logic for these composite tests is always the same: NOT first condition OR second condition. This way you can also test if, say X>Y or X<0 (e.g. for range checks). Which makes this technique useful even for calculators that offer the full set of tests against Y and 0. I was considering X!=Y followed by X>Y, but I have a suspicion that X<=Y followed by X=Y (or another always-false condition) will be quicker. Why? It's probably more likely that X!=Y if you're testing some loop end condition, and if you evaluate X!=Y first, you'll end up evaluating two conditionals. If you evaluate X<=Y first, then you'll skip the second conditional any time X>Y (which is what you're looking for). Though of course this depends heavily on the nature of the two operands you're testing. It might be much more likely that X=Y in a given program, with evaluating the inequality being the exceptional case. And if you aren't performing the comparison within a loop, then the difference in overhead probably wouldn't be significant anyway. Thanks for the article link. I'll read over it when I get home. On a related note, if you want to see really deficient conditionals, look at a TI-58/59/66. You only get x=t, x!=t, x>=t, and x<t, and they can only be followed by a GTO. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)