HHC 2018 Programming Contests
|
10-06-2018, 12:48 PM
Post: #81
|
|||
|
|||
RE: HHC 2018 Programming Contests
(10-06-2018 11:42 AM)Gerson W. Barbosa Wrote: This saves 47 bytes overall. We can also use Werner's remark: (10-01-2018 01:42 PM)Werner Wrote: The period for 23x28 and 28x33 days is also halved to 322 and 462, respectively. Code: \<< RCLF RAD Meanwhile I came up with something between your and 3298's solution: Code: « But I consider 3298's idea to calculate the difference, then the remainder, flatten the lists and only then sort the result more elegant. Only drawback is the use of: Code: 1. + Kind regards Thomas |
|||
10-06-2018, 03:15 PM
(This post was last modified: 10-06-2018 03:17 PM by Eddie W. Shore.)
Post: #82
|
|||
|
|||
RE: HHC 2018 Programming Contests
(10-05-2018 09:32 PM)Joe Horn Wrote: Here is Eddie Shore's winning PPL entry: Good catch. I had the "Find Your Fate." on the input screen, and I forgot to change the help text when I changed the input from YYYY.DDMM to entering the year, day, and month separately. The contest wanting elegance inspired me to do the splash screen and the more user friendly input/output. |
|||
10-06-2018, 03:57 PM
Post: #83
|
|||
|
|||
RE: HHC 2018 Programming Contests
(10-06-2018 12:48 PM)Thomas Klemm Wrote: Meanwhile I came up with something between your and 3298's solution: I was getting wrong biorhythm results until I noticed my angle mode was set to RAD. Preserving the user’s settings and forcing DEG mode makes your program 367 bytes long, which is quite an improvement over mine. Well done! Code:
Gerson. |
|||
10-06-2018, 04:21 PM
Post: #84
|
|||
|
|||
RE: HHC 2018 Programming Contests
(10-06-2018 12:48 PM)Thomas Klemm Wrote: But I consider 3298's idea to calculate the difference, then the remainder, flatten the lists and only then sort the result more elegant.Thank you very much. (10-06-2018 12:48 PM)Thomas Klemm Wrote: Only drawback is the use of:If those shall go entirely, try replacing the inner program Code: \<< - SWAP MOD \>> Code: \<< I've taken inspiration from Gerson's program here, he thought of using comparisons for list processing first. This variant is 5 bytes longer though. Another bit that could make all of our programs more elegant would be using units in the function values calculation to avoid that mode switching madness. (By the way, Thomas, your mashup program blindly assumes DEG mode and failed to return correct results on my calculator for that reason.) There are dedicated units for angles, and when SIN gets an input tagged with one of these, the unit overrides the current angle mode. Unfortunately unit objects are pretty heavy, adding 13.5 bytes to the number they are attached to (that number is for single-symbol units like degrees and radians; longer units take even more). That's more than what we spend for the mode switching (12.5 bytes in my program). Next discovery: exploding a sublist inside DOLIST (e.g. with an EVAL at the end of the program passed to DOLIST) causes all elements of the sublist to be added to the result list, no more flattening needed. That means, adding an EVAL at the end of the subprogram lets me remove the EVAL + + after the DOLIST. That's 5 bytes saved with no negative impact on elegance (if anything, it's more elegant afterwards). And then there's a rare and kind of amusing bug. If my program (or the one by Thomas that's partially based on mine) runs during midnight, there's a chance the DATE calls happen on different sides of midnight and therefore return different values. That causes the calculated extrema date to be off by one. The function values remain correct though. I've corrected this in the revised "elegant" version below. But before we come to that let's do something different, trying to get my program as short as possible. Of course that means doing exactly what I just criticized Thomas' program for, blindly assuming that the angle mode is radians (because that's what matches a freshly reset calculator, which the challenge demands programs to be compatible with). The midnight bug stays in. No pretty tagging either. Please enter in exact mode because some numbers are exact integers on purpose (those tend to be shorter when the reals aren't compiled to 2.5-byte pointers into ROM, but not everybody likes to use them because they are also slower). The list of weird numbers between 0 and 1 is precalculated like this: 2. \pi * { 23 28 33 } / Code: \<< And the revised "elegant" program (\^o is the official encoding for the degrees symbol, enter via the units menu or Alpha Rightshift-hold 6): Code: \<< |
|||
10-06-2018, 06:38 PM
Post: #85
|
|||
|
|||
RE: HHC 2018 Programming Contests
(10-06-2018 03:57 PM)Gerson W. Barbosa Wrote: I was getting wrong biorhythm results until I noticed my angle mode was set to RAD. Please excuse my sloppiness. (10-06-2018 04:21 PM)3298 Wrote: Next discovery: exploding a sublist inside DOLIST (e.g. with an EVAL at the end of the program passed to DOLIST) causes all elements of the sublist to be added to the result list, no more flattening needed. That's something I didn't consider. Here's a program that uses it: Code: « Both your 1 + trick and Gerson's masking trick are nice but distract from the problem. Maybe that's only me but it took me a while to figure out why you had to do that. I tried to avoid this. Quote:There are dedicated units for angles, and when SIN gets an input tagged with one of these, the unit overrides the current angle mode. That's a nice solution I wasn't aware of. Of course we could also use Didier's 0 ACOS trick. Quote:And then there's a rare and kind of amusing bug. Though I was aware of the issue I didn't consider it a problem. It's also present in my HP-41CX program. Otherwise I would have needed to use a register to save the date. Kind regards Thomas |
|||
10-07-2018, 01:46 PM
Post: #86
|
|||
|
|||
RE: HHC 2018 Programming Contests
Here's a cleaned up version of my previous post.
Code: @ THIS IS NOT MY CONFERENCE ENTRY. |
|||
10-09-2018, 04:48 AM
Post: #87
|
|||
|
|||
RE: HHC 2018 Programming Contests
(10-07-2018 01:46 PM)David Hayden Wrote: Stealing this idea I managed to combine filtering and sorting into a single reducing: Code: « Cheers Thomas |
|||
06-25-2019, 01:27 AM
(This post was last modified: 06-25-2019 01:29 AM by Craig Bladow.)
Post: #88
|
|||
|
|||
RE: HHC 2018 Programming Contests
(10-05-2018 12:00 AM)Joe Horn Wrote: Craig Bladow's RPN contest entry can be downloaded from HERE. Thank you for judging this, Joe! I've had a chance to review my solution and it does get right answers, just not all of them! ![]() The following is a corrected program: Code:
Try CC41! |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)