HHC 2015 RPN programming Contest is now open

[DanM]

Here is my entry, from the conference. I think if Gene bothered to look as far down the entry list as this, I may have won the Max-Byte Bloatware prize, the Inelegant Effort prize, the Spaghetti prize or all of those. But it works. And it was difficult to focus on programming during the conference, at least it was for me.

It would've been 73 bytes without the unnecessary XEQ RR at the end, and 69 bytes if I had been clever enough to think of using DSE instead of ISG. Ahhhh, re-learning how to program on calculators, what could be more fun?

Very interesting entries and different approaches to the problem. Many thanks to Gene for sending this problem out to the world. And many congratulations to Gunter for the elegant and brilliant winning solution at the conference!

Line 42s bytes 77
01 LBL RR
02 XEQ SORT
03 CLX
04 STO 08
05 1.004
06 STO 06
07 IP
08 STO 07
09 CF 05
10 LBL 04
11 1
12 STO+ 07
13 RCL IND 07
14 RCL IND 06
15 -
16 X<=y? check step is it 1? (not a big step)
17 GTO 01 it is 1, OK go to add 1, isg, loop
18 2 it is big step is It 1st step? 2 is compare criteria
19 RCL 06 isg value
20 X<Y? if it is not 1st check, then is it last step? (3)
21 GTO 02 go to regular error, not 1st step but check for last step
22 4
23 X>Y? if it is not last check, then regular error (05)
24 GTO 05 go to regular error, not 1st step and not last step
25 GTO 02 if it is 1st check or last check, don't mark error, and go back
26 LBL 05
27 SF 05 set big step flag
28 LBL 01 Add it to 08, isg, loop
29 STO+ 08
30 LBL 02
31 ISG 06 check for finish
32 GTO 04 if not finsihed loop again
33 3 finishing, check total
34 RCL 08 finishing, check total
35 - finishing, check total
36 X<=0? if (08) is 4 or 3, it could be good, otherwise it is smaller
37 CLST
38 FS?C 05 if it is bad something other than 0
39 2
40 STOP
41 XEQ RR
42 END

[Werner]

43 Bytes including LBL and END, stack only

Code:


01>LBL"RR"
02 4
03 RCL 05
04 10^X
05>LBL 01
06 RCL IND Y
07 10^X
08 +
09 DSE Y
10 GTO 01
11 X<>Y

12>LBL 02
13 CLX
14 10
15 /
16 RCL X
17 1111
18 X>Y?
19 GTO 00
20 -
21 LOG
22 FRC
23 X#0?
24 GTO 02

25>LBL 00
26 END

Cheers, Werner

[Werner]

Managed to squeeze off a byte:
42 bytes

Code:

01>LBL"RR"
02 4
03 RCL 05
04 10^X
05>LBL 01
06 RCL IND Y
07 10^X
08 +
09 DSE Y
10 GTO 01
11 X<>Y

12>LBL 02
13 SIGN
14 10^X
15 /
16 RCL X
17 1111
18 X>Y?
19 GTO 00
20 -
21 LOG
22 FRC
23 X#0?
24 GTO 02

25>LBL 00
26 END

Method: sum up all the dice values, well all 10^x of the dice values, and then a small straight is 1111(0)(0) + 10^y, or one power of 10 removed from 1111 followed by 0-2 0's. Subtracting 1111 and taking the LOG should thus produce an integer, or FP=0.
My first attempt looped 3 times explicitly, and that was 1 byte longer or so - but of course 1111 + 10^y > 1111, and that can be used as loop terminator.

Cheers, Werner

[David Hayden]

(09-28-2015 02:21 AM)Bill (Smithville NJ) Wrote:  Is this loop assuming the flags are initialized to clear? What happens if they aren't? Or am I missing something here.

Rule #13:

Quote:Assume default machine settings. Your program must stop with the default settings in place, unless they are changed by the provided sorting routines

I'm assuming that this means, among other things, flags initially cleared. Gene?

[David Hayden]

[EDIT: Fixed the byte count - Thanks Werner]

Okay, here is a version that seems to work. It uses the stack and flags 01-06. The code assumes that the flags are cleared at the start (my interpretation of the "assume default settings" rule) and it clears them at the end (as required for multiple runs). There is no call to SORT. In my experience, the only time you really need to sort data is for human consumption.

23 steps and 45 bytes, assuming that I can get away with a RTN at the end instead of an END.

Code:

01 LBL RR

# Set flags 1-6 corresponding to the contents of registers 1-5
# e.g., if R01 contains 5, set flag 05
02 5        # 1 byte
03 LBL 01    # 1 byte
04 RCL IND X    # 2 bytes
05 SF IND X    # 2 bytes?
06 X<>Y     # 1 byte
07 DSE X    # 2 bytesG
08 GTO 01    # 2 bytes
# Note that X=0 when you exit this loop. If there's a short
# straight, I'll leave it.

# Now compute the result into flag 03, clear the flags along the way
# You have a short straight if F3 & F4 & (F1&F2 | F2&F5 | F5&F6)
# Which is the same as  F3 & F4 & (F2 & (F1 | F5) | F5&F6)

09 FC?C 04
10 CF 03    # F3 = F3&F4
11 FS? 05
12 SF 01    # F1 = F1|F5
13 FC?C 01
14 CF 02    # F2 = F2&(F1|F5)
15 FC?C 06
16 CF 05    # F5 = F5&F6
17 FS?C 05
18 SF 02    # F2 = F2&(F1|F5) | F5&F6
19 FC?C 02
20 CF 03    # F3 = F3&F4 & F2&(F1|F5) | F5&F6

# X contains 0.0 as noted above. Change it to 1 if
# F03 is clear
21 FC?C 03
22 1
23 RTN

[Werner]

Clever.
I count 45 bytes, however - that would be 47 with END i.o. RTN.

[Egan Ford]

All stack, 58 bytes (yeah, not even close to my last attempt (42 bytes), but just a different way to solve that none have posted, unless I missed it)

Code:


  1 LBL RR                  
  2 5           ; loop over 5 dice
  3 1
  4 LBL 00
  5 RCL IND Y   ; map to prime number
  6 X^2         ; x^2 - x + 11, x = 0-10 prime
  7 LASTx
  8 -
  9 11
 10 +
 11 *           ; multiply primes
 12 DSE Y
 13 GTO 00
 14 ENTER
 15 ENTER
 16 ENTER
 17 55913       ; check for 1,2,3,4
 18 MOD
 19 X=0?
 20 GTO 01
 21 Rv
 22 157573      ; check for 2,3,4,5
 23 MOD
 24 X=0?
 25 GTO 01
 26 Rv
 27 496961      ; check for 3,4,5,6
 28 MOD
 29 LBL 01
 30 END

[Paul Dale]

I thought about coding using the product of primes but didn't follow it far....


Pauli

[Gene]

(09-29-2015 09:25 AM)Werner Wrote:  Managed to squeeze off a byte:
42 bytes

Code:

01>LBL"RR"
02 4
03 RCL 05
04 10^X
05>LBL 01
...

Cheers, Werner

Gene: Werner, of all the code posted so far, yours is the one I like the best. It is short and disturbs other aspects of the machine the least. If you don't mind, I'd like to incorporate some modification of your approach into my Yahtzee game for the funstuff rom?

Nearly *every* posting here is shorter than my efforts, which is why I posed this as the programming contest problem. :-)

I will post my version and Gunter's version from the conference later today if at all possible.

thanks all...

[Csaba Tizedes]

Bytes, bytes everybody talks about bytes...
Can somebody check my beloved HP15C 53 steps solution is how many byte costs on a pure 41???

Thanks!
Csaba

[Gerson W. Barbosa]

(09-30-2015 01:54 PM)Csaba Tizedes Wrote:  Bytes, bytes everybody talks about bytes...
Can somebody check my beloved HP15C 53 steps solution is how many byte costs on a pure 41???

Thanks!
Csaba

Hello Csaba,

Your program is 45-step long and takes up 84 bytes on the HP-42S, but you can save a few bytes by using HP-41C specific instructions. Also, CLX instead of 0 takes up only one byte instead of two. END instead of the final RTN saves you another byte.

Code:


00 { 84-Byte Prgm }
01>LBL "RR"
02 9
03 STO 06
04 XEQ "SORT"
05 1.005
06 STO 08
07>LBL 00
08 RCL 08
09 RCL IND 08
10 STO 08
11 RCL IND 08
12 ABS
13 +/-
14 STO IND 08
15 Rv
16 Rv
17 STO 08
18 ISG 08
19 GTO 00
20 1.006
21 STO 08
22 0
23 STO 00
24>LBL 01
25 RCL IND 08
26 X>0?
27 GTO 02
28 1
29 STO+ 00
30 RCL 00
31 3
32 X<Y?
33 GTO 03
34>LBL 09
35 ISG 08
36 GTO 01
37 9
38 RTN
39>LBL 02
40 0
41 STO 00
42 GTO 09
43>LBL 03
44 0
45 RTN

Quoting from your code comments:

Quote:

Code:


1       005-       1     |
.       006-      48     |
0       007-       0     |   Maybe this is only one step on 41C
0       008-       0     |
5       009-       5     |

Yes, only one step. Six bytes, though.

Regards,

Gerson.

[Egan Ford]

(09-30-2015 03:42 PM)Gerson W. Barbosa Wrote:  Yes, only one step. Six bytes, though.

I was wondering about that, is each digit on the 41 a byte? Or is it packed somehow?

[Gene]

Not packed.

[Egan Ford]

(09-30-2015 07:29 PM)Gene Wrote:  Not packed.

Just to be clear, if a program has "123456", that is 6 bytes of storage?

[Gerson W. Barbosa]

H

(09-30-2015 08:23 PM)Egan Ford Wrote:  

(09-30-2015 07:29 PM)Gene Wrote:  Not packed.

Just to be clear, if a program has "123456", that is 6 bytes of storage?

123456: 7
1: 2
12: 3
1.2: 4
123456789: 10
-12: 4
-1.2: 5
2E5: 4
1.2E34: 7
-5.6E-78: 9

[Egan Ford]

Gerson, thanks, I never knew it was that bad.

[Werner]

Gene: I would be honoured!

Werner

[Werner]

Gerson: on the 41, numeric values take up as many bytes as the digits and/or extra chars. So 123456 takes up 6 bytes and -1 E-3 takes up 5.

There is one exception: when the previous line contains a number, too, an invisible 'null' is inserted between the two, to separate the numbers. That takes up an extra byte.
On the 42S, this invisible null is present in all number entry lines, whether they are preceded by another number or not. And so the byte count for programs with number entry lines is different between the 41 and 42.

Cheers, Werner

[Csaba Tizedes]

(09-30-2015 03:42 PM)Gerson W. Barbosa Wrote:  Your program is 45-step long and takes up 84 bytes on the HP-42S

Hi, Gerson, thank you for your checking - I'll try to find an emulator to check your (and others) solutions - or I'll "translate" these solutions to 15C for better understanding.

Csaba

[Gerson W. Barbosa]

(09-30-2015 10:42 PM)Egan Ford Wrote:  Gerson, thanks, I never knew it was that bad.

Egan, I should have mentioned I was using a 42S to check the byte counts. I assumed the counts would be the same on the 41, but I was wrong (see Werner's post above) -- 123456 is indeed 6 bytes long, not seven, so things are slightly less bad on the 41. Sorry for the confusing!