Threaded Mode | Linear Mode

David Hayden · (This post was last modified: 10-16-2022 11:07 PM by David Hayden.)

Roger Hill, Bill Butler and I have been having an email conversation about the contest. As you might expect, Roger and Bill have been creating amazing solutions. With their permission, I'm posting the email thread here.

Bill Butler on 3 October 2022 Wrote:Hi Roger and Dave,

Hope these email addresses still work.

I came to this year’s RPL programming challenge after the fact. While initially being a bit annoyed with Gene’s statement of the problem insofar as it applies to the 50g with his usual lack of awareness of or concern for the implications of having type 28 integers, I came to accept, as both of you have clearly shown, that as a programming problem for the 50g it just adds to the challenge. While some bound on the number of steps is clearly necessary, for the 50g any restriction on the number of digits is clearly not. One might prefer having 2 inputs – both the integer and a limit on the number of steps – and then have the program stop with either a palindrome or when this limit is reached (as well as, if desired, redundantly indicating which has occurred). Anyway, for the problem as stated my initial effort (having the benefit of Dave’s program) was at 163.5 bytes and over twice as fast as Dave’s (using IDIV2 with the digit reversal only once in the loop and once initially). And then Roger posted his bombshell! (Who else could have come up with that one?) Inspired by Roger’s program I then proceeded to avoid any local or stack variables with this time the digit reversal restricted to the loop. The (simpler?) result below is both marginally smaller than Roger’s and over twice as fast. The 4.5-byte-larger IDIV2-free versions are respectively over 5 times as fast and 12 times as fast as Dave’s, obviously relevant if judging were based on size*speed rather than just size. I had also used START rather than WHILE for the digit reversal but with (the marginally advantageous) XPON instead of LOG. In addition, testing the number of cycles before augmentation rather than after allows for the slightly smaller 7. SQ < rather than the 50 < . (Note that Dave’s checksum and byte count are for 50. rather than the 50 in his listing.)

So FWIW here it is (#FE40h, 143.)

Code:

<< -1. OVER 0. DO + OVER 7. SQ < OVER 6. ALOG SQ ≤ AND 3. UNPICK SWAP 1. + SWAP DUP 0. DUP PICK3 XPON START 1. ALOG SWAP OVER * UNROT IDIV2 ROT + NEXT NIP 3. DUPN - UNTIL 6. PICK AND NOT AND END DROP R->C * C->R >>

Then using Roger’s 4.5-byte larger IDIV2-free digit reversal, i.e.

replacing 1. ALOG SWAP OVER *
UNROT IDIV2 ROT +

with SWAP 1. ALOG / DUP IP
UNROT FP + 1. ALOG *

gives the faster program mentioned above (#1141h, 147.5).

Specifically how many times faster than Dave’s program the 5 programs being discussed are is given below where times were averaged over 10 trials for each of the 4 inputs 98, 9338, 98., and 9338. (Gene’s two examples).
program checksum size IDIV2? x faster
Dave #31E0h 185. Y 1.000
Roger1 #620Bh 144.5 Y 1.076
Bill1 #FE40h 143 Y 2.183
Roger2 #9A2Dh 149. N 5.314
Bill2 #1141h 147.5 N 12.634
Still teaching here (remotely through lockdowns and now again in person) and so far COVID-lucky (though being careful using N95 masks everywhere as well as being 5x vaxed).

Best wishes to you both.

Bill

Thanks Bill! We missed you at HHC and hope that you can come next year. Nice catch on the 50 vs. 50. in my listing. I'll update the post in the forum.

We had another entry from a new-comer - Jay Peng. I'll try to get his email address so we can share this with him.

All the best,
Dave

Roger Hill on 4 October 2022 Wrote:Hi Bill,

Thanks for your message; we missed you at HHC! Hope to see you next year.

I’m guessing that Gene specified floating point for the HP-50 version so as to make the 50 and 41 contests the same.

Good idea about saving on the number of digit reversals. This ought to be useful in writing a long-integer version where speed would probably be a significant factor.

I think Jay Peng gave me a printed version of his program (which he wrote on an HP-48), and will see if I can find it.

All the best,

— Roger

Roger Hill on 9 October 2022 Wrote:Hi Bill and Dave,

In an attempt to combine the best features of all of our programs, I came up with yet another program (#9DEh, 130.5 bytes):

Code:

<< -1. 0 ROT R->I DO + DUP2 6. ALOG SQ < SWAP 7. SQ <= AND ROT 1. + OVER * UNROT R->I * DUP 0. 1. PICK3 R->I SIZE START 1. ALOG * SWAP 1. ALOG IDIV2 ROT + NEXT NIP DUP2 SAME UNTIL END DROP >>
Basically, the program add together the results of the previous cycle and checks for out of bounds; if so it changes both the cycle number and result to zeroes. After reversing the digits as in previous programs, the two numbers are compared and the DO loop is exited if they are equal.

One slight hitch in this approach, however, is both LOG and XPON bomb out with a zero argument; this is fixed by using R->I SIZE instead. Another problem is that if the input is itself a palindrome it would output the same number with zero cycles (logically correct, but not what the contest requires). I tried several ways of forcing the second iteration, and the most byte-economical method that I found was to turn the input into “integer“ format. By the time it goes through the digit-reversal mill it has become a “real”, and using SAME to make the final comparison will answer false even if the two numbers are equal. After the second iteration both numbers have become “real” so that SAME has the same effect as ==.

As in previous programs, a faster (but 4.5 bytes longer) IDIV2-free version can be made by replacing the START…NEXT code as Bill notes below.

Enjoy!

— Roger

Bill Butler on 13 October 2022 Wrote:Hi Roger and Dave,

Roger’s latest (#9DEh, 130.5) is a very nice exploitation of the difference between SAME and == for integers!

Three minor tweaks maybe:

1) The R->I on the test result (after UNROT) can be avoided by using 6 and 7 for 6. and 7.

2) BUFLEN can be used for 0. 1. Though purists might object, default settings/states would presumably allow it. (Since I never use serial vs. Kermit transfers, anything other than 0. 1. never occurs for me anyway. Moreover given Gene’s method of judging, he would never know the difference.)

3) Reverting to my previous SWAP OVER * UNROT for * SWAP 1. ALOG in the digit-reversal routine is measurably faster.

Any marginal reduction in speed from either (1) or (2) is more than compensated for by the 2.5-byte saving from each (if bytes*time were being used to judge).

The resulting program (#C51Bh, 125.5) follows:

Code:

<< -1. 0 ROT R->I DO + DUP2 6 ALOG SQ < SWAP 7 SQ ≤ AND ROT 1. + OVER * UNROT * DUP BUFLEN PICK3 R->I SIZE START 1. ALOG SWAP OVER * UNROT IDIV2 ROT + NEXT NIP DUP2 SAME UNTIL END DROP >>

Regards,

Bill

Roger Hill on 13 October 2022 Wrote:Hi Bill,

Thanks for your message. I did not know that the result of a comparison (like <) would be an integer if at least one of the arguments is an integer! (Actually only the 7. has to be replaced by 7 because the other comparison involved the input number which is an integer the first time around.) I had been trying to get rid of that pesky R->I!

Also, I seem to remember there being some trick to give 0. 1. In 2.5 bytes but I couldn’t remember what it was.

As has been said before, the contest is not only fun but a learning experience!

All the best,

— Roger

Dave Hayden on 14 October 2022 Wrote:Roger and Bill,

The internal format of a complex number uses two reals, minus the prologs, so there's no way to use integers, at least not directly.

I'd love to post this email thread in the HP museum thread for the contest. It's that okay with you guys?

Thanks,
Dave