HP 32S: <= and >= comparisons

[Dave Britten]

(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.