HP 32S: <= and >= comparisons - Printable Version +- HP Forums ( https://www.hpmuseum.org/forum)+-- Forum: HP Calculators (and very old HP Computers) ( /forum-3.html)+--- Forum: General Forum ( /forum-4.html)+--- Thread: HP 32S: <= and >= comparisons ( /thread-3791.html) |

HP 32S: <= and >= comparisons - Dave Britten - 05-06-2015 03:13 PM
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? RE: HP 32S: <= and >= comparisons - Dieter - 05-06-2015 08:20 PM
(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 RE: HP 32S: <= and >= comparisons - Dave Britten - 05-06-2015 08:57 PM
(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. |