Advents of Code (programming challenges)

[pier4r]

Some challenges (if the input can be shoehorned in the calculator memory), can be done also with the glorious calculator languages or calculators

https://adventofcode.com/

(in the archives there are the challenges from 2015 onwards)

[DavidM]

Thanks for posting this, Pier. I've completed the 2022 puzzles that have been posted so far for the 50g -- they have been well-suited for list processing, so it's been an enjoyable exercise for me.

Nice find!

[pier4r]

Yes! I am happy someone else enjoys them.

I mean I know that starting from 2010 (or around it) different websites started to collect programming challenges, but I really like the "only in a season" approach (further one can solve past challenges as well), instead of the "every day a new problem". Moreover those on AoC aren't too hard neither too easy. One Valentin Problem I think would match the entire AoC calendar.

I have to say that at the moment I am not using userRPL and the glorious ListExt also because the 50g is busy computing something else (for 7 days already, it is a summation but apparently I underestimated things and I am not even using LongFloat).

Thus I am trying to solve the thing in a DSL declarative language where I cannot reassign variables (more here). Most likely - if I find the time - I will come back to it with the trusty hp 50g (or solve pre 2022 problems). Possibly other candidates are HPPL and newRPL (but again, time is short).

If anyone wants, I am at least in one private leaderboard (where I am getting butchered) that can be joined using this link: https://adventofcode.com/2022/leaderboard/private with the id: 2389790-6b70ade4 .

[pier4r]

DavidM will you post the code somewhen?
It would be always interesting (and a possibility for learning) but especially some days are tricky (parsing, of all things).

For example Day 7 is interesting, as AFAIK RPL doesn't have trees but neither associative arrays.

[DavidM]

(12-07-2022 08:50 PM)pier4r Wrote:  DavidM will you post the code somewhen?
It would be always interesting (and a possibility for learning) but especially some days are tricky (parsing, of all things).

For example Day 7 is interesting, as AFAIK RPL doesn't have trees but neither associative arrays.

Yes, I looked at Day 7 briefly and thought that the sample was probably doable on a 50g, but I haven't tried it yet and believe that the memory requirements (and possibly runtime) using the final data they provide may be beyond what the calculator could manage. Given that the problems generally get more complex with each passing day, today may be the end of the line for what the 50g could reasonably handle.

I was able to complete days 1-6 on the 50g so far (all of them using ListExt, which has been a good fit). For the first 4 day's puzzles, I simply stored the given data in the same directory as the code as a string variable. The code then loads it and converts it to a list for processing.

Starting with day 5, I decided to go a different route with the input due to the time it was taking to load/convert it every time I would do a trial run. I basically create the list structure independent of the main program and store it as a hex string. Converting it into the needed list can then be done with H-> from library 256. It's a little more involved than that (mostly in dealing with linefeeds), but it streamlines using the given data for testing.

I'll post a couple of days puzzles if there's interest.

[DavidM]

This first day's project, as all the rest, has a much longer and far more creative description than I'll give here (see the link from the original post in this thread). Each day has a part 1 and part 2 puzzle to solve.

I'll paraphrase the descriptions just so that you can get some idea what the programs do here. This first pair is quite simple, and there's actually more comments than code in the programs I used here. I suspect they choose the first couple problems as "easy winners" to get people interested.

Part 1:

Find the largest sum of the grouped integers given as input. Group boundaries are given as blank lines (or the end of input) for the given input string. See the example input below for the actual format of the data.

Code:

@ %%HP2: T(3)A(R)F(.)M(=)C(R)B(H);
@ Name: 'D1P1'
@ Size: 124.0 bytes, CRC: 03A4h
@ 12/07/22 05:30:00P
@ Libraries used:
@   1423: ListExt Commands
@ 
\<<
   @ place input string on stack
   D1dat
   
   @ format input string to create a list of sublists
   { 10 10 } NL\->S "}{" SREPL DROP
   10 CHR " " SREPL DROP
   "{{" SWAP + "}}" +
   
   @ convert re-formatted string to list of sublists
   STR\->
   
   @ create a list of subtotals
   ::LSUM LMAP
   
   @ find the largest subtotal
   LMAX
\>>

The bulk of the above code is in formatting the input as a string in the proper format for a list of lists. Once formatted, the string is converted to an actual list, then each subgroup is summed and the largest sum is the result (left on stack level 1 here).



Part 2:

Using the same data as above, find the top 3 largest sums and add them up for the final result.

Code:

@ %%HP2: T(3)A(R)F(.)M(=)C(R)B(H);
@ Name: 'D1P2'
@ Size: 137.5 bytes, CRC: E22Bh
@ 12/07/22 05:30:00P
@ Libraries used:
@   1423: ListExt Commands
@ 
\<<
   @ place input string on stack
   D1dat
   
   @ format input string to create a list of sublists
   { 10 10 } NL\->S "}{" SREPL DROP
   10 CHR " " SREPL DROP
   "{{" SWAP + "}}" +
   
   @ convert re-formatted string to list of sublists
   STR\->
   
   @ create a list of subtotals
   ::LSUM LMAP
   
    @ sort
    @ (use LSORT if you have it -- which you should!)
    SORT
    
    @ take last three ( top 3 quantities )
    -3 LTAKE
    
    @ sum the top 3
    LSUM
\>>

This one is very similar to the first, and the first 4 code sections are exactly the same. At that point, there is a list of group totals on the stack, which is then sorted, and finally the top 3 are isolated and summed. As before, the final result is left in stack level 1.

Here's the sample data provided by the site for testing purposes:

D1dat
@ sample
"1000
2000
3000

4000

5000
6000

7000
8000
9000

10000"

Using the above sample data, the final result for part 1 is 24000, and the final result for part 2 is 45000.

The final data supplied by the site is 2244 lines of numbers and blanks, and I won't include it here. Feel free to go to the site and take a look! Registration may be required, which can be done as "anonymous" if desired.

[pier4r]

(12-07-2022 09:52 PM)DavidM Wrote:  I'll post a couple of days puzzles if there's interest.

I am always interested in solving code (whether I get it is another story).

[floppy]

(12-01-2022 05:44 PM)pier4r Wrote:  Some challenges (if the input can be shoehorned in the calculator memory), can be done also with the glorious calculator languages or calculators

https://adventofcode.com/

(in the archives there are the challenges from 2015 onwards)

Interesting.
Personally, I am a fan of the tasks/challenges in https://rosettacode.org/wiki/Rosetta_Code

[DavidM]

OK. So here's my version of Day 2 (parts 1 and 2). This didn't have to be solved using a list-based approach, of course, but it's more fun for me to do it that way so I did.

Part 1

The description of the problem needs to be read from the site. Suffice it to say that it is based on the "Rock-Paper-Scissors" game that most probably already know about.

The sample case for this problem is too short to be meaningful (IMHO). The "real" data is 2500 lines of input, and takes a while for even an emulated 50g to solve. So for purposes of this post, I've used only the first 100 lines of the real data provided.

Commentary about part 1:

I found it easier to visualize the data if I first converted A, B, and C to R, P, and S. Likewise with X, Y, and Z. So that conversion is first in my solution.

The data needed to be in list form (of course), so the next 2 blocks of code use a similar process to day 1's to get the data in that form.

To provide the requested result, I then convert each "round" to a score, followed by summing each round's result.

Instead of just typing in all of the possible outcomes for the scoring ({ { R R } { R P } { R S } { P R } { P P } { P S } { S R } { S P } { S S } }), I used LCPRD (List Cartesian Product) to build the list:

{R P S} DUP 2 →LIST LCPRD

The actual scores are just constants as specified in the problem description.

Here's what I came up with for part 1:

Code:

@ %%HP2: T(3)A(R)F(.)M(=)C(R)B(H);
@ Name: 'D2P1'
@ Size: 256.5 bytes, CRC: 2F2Ch
@ 12/08/22 11:00:00A
@ Libraries used:
@   1423: ListExt Commands
@ 
\<<
    @ place input on the stack
    D2dat
    
    @ convert codes to "R P S"
    "A" "R" SREPL DROP
    "X" "R" SREPL DROP
    "B" "P" SREPL DROP
    "Y" "P" SREPL DROP
    "C" "S" SREPL DROP
    "Z" "S" SREPL DROP
    
    @ convert input to list of rounds string
    10 CHR "}{" SREPL DROP
    "{{" SWAP +
    "}}" +

    @ convert re-formatted string to list of sublists
    STR\->
    
    @ obtain cartesian product of {R P S} against itself
    {R P S} DUP 2 \->LIST LCPRD
    
    @ scores for each paired element
    {4 8 3 1 5 9 7 2 6} LREPL
    
    @ sum the scores
    LSUM
\>>



D2dat
"C Y
C Z
B Z
A Z
A Z
A Y
A Z
C Y
C Z
A Y
A Y
B X
A Y
C Z
C Z
B X
C Z
A Z
B Y
C Z
A Y
C X
B Y
A Z
B Y
C Z
B Z
B Y
C Z
A Z
A Z
B Z
C Z
A X
B X
C Y
C Z
C Z
C Z
A Y
C Z
C Z
C Z
C X
A Z
A Z
C Y
A Z
C Z
C Z
C Z
A Z
B Y
C Z
A Z
B Z
A Z
A Y
B X
B X
C Z
C X
C Z
C Z
A Z
B Z
B X
B X
B Y
C X
C Y
A Y
C Z
A Y
C Z
A X
B X
B X
C X
B X
B X
A Y
B Y
C Y
A Z
C Y
B Y
B X
B X
B Z
B X
B Z
A Z
B Y
C Z
B Z
B Z
B Y
A Y
C Z"

Part 2

Part 2 is essentially a correction to the incorrect assumption stated in the Part 1 problem description.

Having been provided with the real meaning of the "strategy guide", the approach is similar to part 1 but with a different disposition for each round. In particular, the "X Y Z" meanings have changed. The scoring is still the same, though. So a different replacement scheme is created, while still using the same scores as before:

Code:

@ %%HP2: T(3)A(R)F(.)M(=)C(R)B(H);
@ Name: 'D2P2'
@ Size: 320.5 bytes, CRC: 9274h
@ 12/08/22 11:00:00A
@ Libraries used:
@   1423: ListExt Commands
@ 
\<<
    @ place input on the stack
    D2dat
    
    @ convert input to list of rounds
    10 CHR "}{" SREPL DROP
    "{{" SWAP +
    "}}" +
    
    @ convert re-formatted string to list of sublists
    STR\->
    
    @ convert input to pairs
    {{A B C}{X Y Z}} LCPRD
    {{R S}{R R}{R P}{P R}{P P}{P S}{S P}{S S}{S R}}
    LREPL
    
    @ obtain cartesian product of {R P S} against itself
    {R P S} DUP 2 \->LIST LCPRD
    
    @ scores for each paired element
    {4 8 3 1 5 9 7 2 6} LREPL
    
    @ sum the scores
    LSUM        
\>>

The same data is used for both parts 1 and 2. Using the abbreviated data (which is included in the part 1 code listing), the results are as follows:

Part 1: 494
Part 2: 557

[pier4r]

Quote:The sample case for this problem is too short to be meaningful (IMHO). The "real" data is 2500 lines of input, and takes a while for even an emulated 50g to solve. So for purposes of this post, I've used only the first 100 lines of the real data provided.

Agree. The sample data sometimes doesn't cover problems that are in the full input (and I discovered that the input is different for each participant, neat!) and some 100-200 lines of the full input are enough.

Unless one builds a "paging" solution to read chunk of data from the SD or the internal flash memory. (I am not even sure that it is always possible)

[DavidM]

(12-09-2022 10:07 AM)pier4r Wrote:  Unless one builds a "paging" solution to read chunk of data from the SD or the internal flash memory. (I am not even sure that it is always possible)

I'm not aware of any way to read a partial stream from an object residing on the SD card (using built-in tools or otherwise). Hopefully someone can share if they know of a way to do that. All of the built-in tools I know of expect to retrieve (or save) only complete objects.

That doesn't stop us from storing things on the card in "chunks", of course, through some sort of manual process. It just requires a coordinated approach to make sure the programs can keep track of the chunks appropriately.

[pier4r]

semi OT regarding the Ram, there is someone solving the problems on an apple 2c

https://github.com/colinleroy/aoc2022 (using basic)

Seemingly the thing has the same ram available (to the user) like the HP 50g, if not less.

Quote:Now that's complicated. Memory's limited and I can't use as many arrays as I want to. DIM A(100,100) directly gives an OUT OF MEMORY ERROR.

DIM A$(100,100) is OK so we're going to use ASC() and CHR$ a lot.

First try failed because accessing memory is slower the further you are in the array, and I missed starts of lines sent via serial. Didn't want to do multiple runs to find out minimal safe delay.

Second try failed : I dumped the contents to floppy using lingest.basic and ascii-xfr with a 5s inter-line delay. Then tried to OPEN and READ the file from BASIC, but things got REAL slow (1 char every 10s), probably due to memory usage.

Third try, reading line by line and splitting into two-dimensional TREE$ array during reading, got too slow after a few lines too.

Fourth try is one more loop, first reading all data, not building a bidimensional array but instead making use of MID$, then iterating twice on that (from top-left, then from bottom-right), then one last time to count visible trees. It failed with an OUT OF MEMORY ERROR.

Figured out about INTEGER variables, DIM TREE%(100,100) for example. Back to reading char by char, but this time reading everything first THEN doing the job. Less elegant, but this one worked in a reasonable timeframe (2 hours for the beautiful O(4n²) algorithm of part 1).

In one reddit thread the author says "I have between 30 and 35kB of memory available." (I think 30kb available is way too low, but surely if the system has the basic 128kb, then the remaining user memory shouldn't be much)

[DavidM]

(12-10-2022 11:38 AM)pier4r Wrote:  In one reddit thread the author says "I have between 30 and 35kB of memory available." (I think 30kb available is way too low, but surely if the system has the basic 128kb, then the remaining user memory shouldn't be much)

Yes, 30-35K of memory isn't much with the sizes of the datasets being provided with these problems. I haven't had much time to devote to this in the last few days, so I'm afraid I'm falling behind. Fortunately, it appears that the problems are left on the site indefinitely (at least for now).

The reference to the //c brought back some memories for me, as I distinctly recall making some mental comparisons between the 48sx and the Apple 2 products when I first acquired the 48 in 1990 (I worked at Apple at the time). Lots of memories from those days!

[pier4r]

Cool tidbits!

And yes as long as the website is accessible, no worries, no need to keep solving one per day (beside for private leaderboards or whatever). For this I say "I hope to come back with userRPL / newRPL" - but I love too much ListExt so I guess I will keep trying with userRPL.

edit: update, it seems that there are two users solving AoC on Apple II. https://github.com/tcsullivan/advent-of-code

[pier4r]

Day 13 could be pretty tedious to debug because again the sample input is not covering all cases.

A reference with one long input (there are multiple inputs for each day, so participants are not spoiled by one answer) is the following post: https://www.reddit.com/r/adventofcode/co...i/j0i9dc0/

[DavidM]

It's a busy time of the year to be working on these puzzles...

I'm currently working on day 8 (part 2). Part 1 was quite simple, but the processing time required for part 2 has me thinking that I'll have to create a Saturn code object for the testing subroutine. I think with that it will process in a reasonable timeframe, but I just need to find the time to write a chunk of Saturn code.

I've been able to use the 50g for all of 2022 days 1-8. I don't think I'll be able to maintain that, though. I also started working through 2021's puzzles, and have gotten through day 8 as well. Had to use an alternative for day 5, but all the rest were done on the 50g.

At the current rate, I might be able to get through this year's puzzles by 2030 or so. No promises on sticking with the 50g, though. I think I'm borderline as it is with being able to do the current ones in RPL. Some parts are amazingly simple, but then with others I run out of memory or time with the given data.

[pier4r]

yes! Further no stress! (although you did both 2021 and 2022, talking about pressure).
In puppet, that is actually a configuration language and was not meant for too many manipulations the variables are very hard to manipulate (indeed the variables there are practically constants), I am having quite some headache. Therefore after day 13 part 2 - on which I am working slowly, everyone has his own pace and obligations beside having fun, - I will put it aside to go around with RPL. I will need to terminate the current work that is going on since the 1st of Dec but that's life.

I may revisit day 1-13 with RPL but at first I will try to do day 14-25. I mean manipulating lists in userRPL is a piece of cake compared to puppet. Puppet is great to read and execute but not to manipulate. In RPL of course many facilities (functions or read/store this or that) may be missing, but could also be that they exists already and I need to find them.

Also an info: from the stats I could see, the problems that are a bit hard are in the middle of the month: 12-18 (max up to the 20th). Then, as a sort of dessert, there are again easy problems. Thus one could also skip the hard parts for later and try the easier ones first.

If I also fail with RPL I am not sure what I can do. What is left then? The TI/Casio side with Basic/Lua - but those may have even less helpful functions than RPL. Further in terms of memory the 9860 is not as well equipped as the 50g, while the nspire has plenty.
Maybe HPPPL/microPython on the Prime but that is a monster.

I was also intrigued by Plus42, although I am not sure that the formula language allows programming (if I understood, it should be more of a super solver like the HP 17B ).

[pier4r]

working slowly on the day 14.

My goodness! First and foremost it was good to pick again the RPL as I am super rusty. I wasn't good before, I am even worse now. I forgot many commands and I had to search through the 50g AUR once again (before browsing the index was enough). How quickly my brain forgets things, and that also because I often don't have time to play around with programs like I did in the past (I do use the systems, but mostly for simple equations or stopwatch function or the like).

Second. On other forums people were unhappy that in the competition some could use Github Copilot or GPT models to produce part of the code and speed up the solution.
Then someone argued "imagine if a person wants to use a vintage system with punch cards, what should we say if we use modern IDE or libraries?".
Well I completely forgot how long it takes - especially if one is rusty - to avoid all the syntax errors, every time sending the program to the calculator and to parse the input is already a (nice) challenge. Further there is no regexp whatsoever (unless I missed libraries). What could be a compact challenge solved in a few hours tends to take much longer, then no wonder one subconsciously puts the thing aside, unless the problem is small.

Anyway, it still feels easier than puppet in manipulating data structures. Further, if I am not wrong, I never really processed strings (although in the past I opened a thread about it) or (ab)used formats like complex numbers or conversions (hex and others), so at least so far I am using functions I barely used in the past.

Hopefully I will have a working code soon, then I can post it (while the calc computes the result, hopefully the pre test on the emulator will be enough*).

Further I fear that a like Day13 on the calculator is very unlikely to be solved, due to the debugging difficulties.

*: I used to do everything on the calc, but due to lack of time, as many said in the past, the emulator really helps to speed up things. Only the emulator lets the laptop fan really work a lot - especially old laptops. Therefore for the big work the calc is still the best (if one can wait) as it is silently computing everything overnight or during the week if one has time only at the end of it.

[DavidM]

You're still way ahead of me, Pier. I just now finished part 1 of day 9. The basic algorithm for determining the "tail" position at each step wasn't so difficult, but the mass of data (11448 "steps" with the data provided) that had to be sifted through was a bit of a headache.

It's unfortunate that the site-generated datasets are so large, because most all of the puzzles I've seen so far are nicely applicable to the 50g. Some of them just have much larger volumes of data than are typically used on a calculator platform.

I can't imagine approaching these on anything other than an emulator, though. The speed of processing and how that affects debugging and testing would be painful on a real 50g. I'd estimate my day 9.1 solution would take close to 3 hours to complete on a real 50g. When working on this, I would "hit the wall" on memory issues at the very end of the processing cycle. So each iterative debugging step would have taken significant time to test.

[pier4r]

I am ahead of you only because I used a more comfortable language for day 1-13 (well, day 12 and 13 were a pain). I still have to redo day 1-13 with the 50g, so actually in terms of problem solved with the 50g you are ahead. And if one counts also day 1-8 of 2021 (that I never solved so far), you did already 32 parts on the 50g (16 days, 2 parts each), while I am still at zero. Although of course not every problem has the same difficulty.

And yes I think the site is more geared towards "nice compact but not too easy challenges for people with modern systems and modern languages". Thus languages with regex and that can use modern CPUs (even from 2005 and after that). Maybe something like GWBasic, powerbasic or other languages on the 200LX could be also easier, I am not sure.

I completely agree on the processing time. With modern sytems a bad or a good solution termine more or less in acceptable time thanks to the plentiful processing power. In a constrained system, only the good solutions survive and the rest is too slow (if one doesn't have plenty of time). Although I suspect that with platforms like newRPL the 50g could execute good solutions (not the bad ones) real fast, only I don't have the setup for newRPL at the moment (maybe someone else could participate with newRPL).

For the 3 hour estimate. I don't find it bad, if one can wait (say, overnight or let it run in the middle of the day, then do something else). If one is in an hurry, yes, it is hard to be faster.
At the end I always remember that systems like the 50g have a similar computational power than early supercomputers, like the CDC 6600 (1 , 2), and on those systems a lot was done (and likely more difficult than what I solve), therefore I should do at least a fraction of that too.