Threaded Mode | Linear Mode

DavidM · 09-15-2022, 03:27 PM

(09-15-2022 01:07 PM)Gerson W. Barbosa Wrote: Here’s a version of your program with the subroutine on the stack, like David Hayden’s above:

Code:

@ # 92C9h, 171.5 bytes « { "" WHILE OVER REPEAT SWAP 10 IDIV2 ROT SWAP + END NIP STR→ } 0 ROT DO DUP 4 PICK EVAL + SWAP 1 + SWAP UNTIL OVER 50 > OVER 1.E12 ≥ OR { DROP2 0 DUP 1 } { DUPDUP 5 PICK EVAL == } IFTE END ROT DROP »

Thanks, Gerson! Saved me the trouble. Smile

C.Ret · (This post was last modified: 09-16-2022 12:32 PM by C.Ret.)

Hi there,

At the moment, I'm not parting with my SHARP EL-5150 calculator, and so here's what I would have returned to Gene if I had been able to attend this year's meeting in person.

[attachment=11116]

Of course, I would have been immediately disqualified, it's not even an American machine.

Here is the code it would have contained:
I have deliberately added spaces and line breaks to facilitate reading and explanations.

[attachment=11115]

(09-15-2022 03:01 PM)Werner Wrote:
(09-15-2022 02:22 PM)David Hayden Wrote: Has anyone determined if the check for iterations>50 is necessary? In other words, are there any numbers that hit 50 iterations before overflowing 10 or 12 digits?
Adding a number to its reverse doubles the number, 'on average' ;-)
2^50 > 1e15, so I guess not.

I am of Werner's opinion, especially since I have not found any integers that would contradict his assumption. So I shortened the previous code which now becomes:

[attachment=11114]

Finally, here is how the jury could have verified the correct operation of this expression:

Find the expression HHC2022 among the multitude of expressions in reserve by typing the beginning of the name and pressing, possibly several times, the green TITLE key until 24:HHC2022 is matched.
Activate this expression by pressing the green COMP key.
Immediately the calculator asks for the value of the argument by displaying N=?. Cursor blinking on question mark.
Enter the desired value and confirm by pressing the green COMP key.
The answer is displayed without too much delay (although this strongly depends on the number of iterations necessary for the calculations).
The second result is obtained immediately by pressing a second time on COMP.

The responses carry the labels ANS 1= and ANS 2= which correspond respectively to registers 1: and 2: (RPL) or X: and Y: (RPN).

Code:

▌                        ▐  OFF --> COMP

▌COMP MODE               ▐  .

▌                  0.    ▐  H H C

▌HHC_                    ▐  TITLE

▌24:HHC2022              ▐  COMP

▌N=?                     ▐  51

▌N=51_                   ▐  COMP

▌ANS 1=           66.    ▐  COMP

▌ANS 2=            1.    ▐  COMP

▌N=?                     ▐  88

▌N=88_                   ▐  COMP

▌ANS 1=        44044.    ▐  COMP

▌ANS 2=            6.    ▐  COMP

▌N=?                     ▐  188

▌N=188_                  ▐  COMP

▌ANS 1=       233332.    ▐  COMP

▌ANS 2=            7.    ▐  COMP

▌N=?                     ▐  98

▌N=98_                   ▐  COMP

▌ANS 1=            0.    ▐  COMP

▌ANS 2=            0.    ▐  COMP

▌N=?                     ▐  99899

▌N=99899_                ▐  COMP

▌ANS 1=   2217777122.    ▐  COMP

▌ANS 2=           10.    ▐  COMP

▌N=?                     ▐  9338

▌N=9338_                 ▐  COMP

▌ANS 1=            0.    ▐  COMP

▌ANS 2=            0.    ▐

David Hayden · 09-16-2022, 01:25 PM

(09-15-2022 03:01 PM)Werner Wrote:
(09-15-2022 02:22 PM)David Hayden Wrote: Has anyone determined if the check for iterations>50 is necessary? In other words, are there any numbers that hit 50 iterations before overflowing 10 or 12 digits?

Adding a number to its reverse doubles the number, 'on average' ;-)
2^50 > 1e15, so I guess not.

Cheers, Werner

On the other hand, the worst case is a number that starts with 9 and ends with 1, which grows by about 11%. (10/9)^50 is only 194.

I ran a C++ program to search for numbers that get 50+ iterations first and it didn't find any in the first few million.

Based on the C++ program, I considered removing that check from my program, but decided against it. I figured that the only way I would beat Roger Hill was if he missed one of these edge cases.

Dave

**Gene** · 09-24-2022, 09:49 PM

My apologies to Valentin Albillo, as I had intended to make sure this was posted a couple of weeks ago.

The HHC Programming challenge is very similar to the 2006 Short & Sweet Math Challenge #14: Cooking Conjectures !, Conjecture 3: rare.

This is the link to the thread: SSMC #14

I did not remember this challenge when coming up with the contest problem and found the idea independently, and as it had been 16 years since the SSMC #14, decided to let it run through the indicated period.

However, I did NOT intend to delay pointing interested readers to Valentin's earlier challenge for solutions, ideas, etc.

Apologies.

As to the questions sometimes asked about which machines are eligible, since at the conference we are judging the shortest solution or length x execution time for the "best" routine, we do have to limit which machines are used for submissions. For nearly 40 years, we have had an RPN contest and since the 48SX days an RPL contest. I don't believe HHC has ever had another type of contest. So for the in person contest, that's what we do.

Forum members are more than welcome to post whatever solutions using whatever machines they wish here, of course! Comparability with the conference is the reason RPN and RPL are usually listed in the requirements...which do not apply really to the forum participants.

So please go to Valentin's SSMC #14 and see what you think vs. what was done here.

And thanks to Valentin for the enjoyment these bring.
Gene

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