HHC 2015 RPN programming Contest is now open
|
09-29-2015, 06:16 AM
Post: #41
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
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 |
|||
09-29-2015, 06:16 AM
Post: #42
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
43 Bytes including LBL and END, stack only
Code:
Cheers, Werner 41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE,DM15L,12C,16CE |
|||
09-29-2015, 09:25 AM
(This post was last modified: 10-16-2015 10:52 AM by Werner.)
Post: #43
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
Managed to squeeze off a byte:
42 bytes Code: 01>LBL"RR" 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 41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE,DM15L,12C,16CE |
|||
09-29-2015, 02:53 PM
Post: #44
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
(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 routinesI'm assuming that this means, among other things, flags initially cleared. Gene? |
|||
09-29-2015, 03:48 PM
(This post was last modified: 09-29-2015 07:42 PM by David Hayden.)
Post: #45
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
[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 |
|||
09-29-2015, 05:40 PM
Post: #46
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
Clever.
I count 45 bytes, however - that would be 47 with END i.o. RTN. 41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE,DM15L,12C,16CE |
|||
09-30-2015, 10:13 AM
(This post was last modified: 09-30-2015 10:27 AM by Egan Ford.)
Post: #47
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
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:
|
|||
09-30-2015, 11:12 AM
Post: #48
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
I thought about coding using the product of primes but didn't follow it far....
Pauli |
|||
09-30-2015, 12:23 PM
Post: #49
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
(09-29-2015 09:25 AM)Werner Wrote: Managed to squeeze off a byte: 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... |
|||
09-30-2015, 01:54 PM
Post: #50
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
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 |
|||
09-30-2015, 03:42 PM
(This post was last modified: 09-30-2015 03:51 PM by Gerson W. Barbosa.)
Post: #51
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
(09-30-2015 01:54 PM)Csaba Tizedes Wrote: Bytes, bytes everybody talks about bytes... 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:
Quoting from your code comments: Quote: Yes, only one step. Six bytes, though. Regards, Gerson. |
|||
09-30-2015, 07:09 PM
Post: #52
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open | |||
09-30-2015, 07:29 PM
Post: #53
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
Not packed.
|
|||
09-30-2015, 08:23 PM
Post: #54
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open | |||
09-30-2015, 08:40 PM
(This post was last modified: 09-30-2015 08:44 PM by Gerson W. Barbosa.)
Post: #55
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open | |||
09-30-2015, 10:42 PM
Post: #56
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
Gerson, thanks, I never knew it was that bad.
|
|||
10-01-2015, 05:44 AM
Post: #57
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
Gene: I would be honoured!
Werner 41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE,DM15L,12C,16CE |
|||
10-01-2015, 05:51 AM
Post: #58
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
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 41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE,DM15L,12C,16CE |
|||
10-01-2015, 07:23 AM
Post: #59
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open | |||
10-01-2015, 10:38 AM
Post: #60
|
|||
|
|||
RE: HHC 2015 RPN programming Contest is now open
(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! |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: