HP Forums
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?
GTO A

x>=y:

Code:
x<y?
x=y?
GTO A

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.