Yet Another Cycling Forum

General Category => The Knowledge => Ctrl-Alt-Del => Topic started by: Afasoas on 10 December, 2015, 08:09:29 pm

Title: Advent of Code
Post by: Afasoas on 10 December, 2015, 08:09:29 pm

10 days late discovering this, but what a little gem it is.
A Christmas themed two-part puzzle to be solved in code for each day of advent.

http://adventofcode.com/

I've had a crack at day 1 and 2 in PowerShell.
https://github.com/biscuitNinja/AdventOfCode

You can do it in any language of your choice.

Title: Re: Advent of Code
Post by: Ben T on 10 December, 2015, 09:57:02 pm

made a bit of a meal of that  ;)
https://github.com/bjtaylor1/AdventOfCode/blob/master/Day1.ps1

Title: Re: Advent of Code
Post by: David Martin on 10 December, 2015, 10:25:14 pm

Done days 1-3 so far. Straightforward if you read the instructions. I misread day 3 as 'more than 1 present'.

Title: Re: Advent of Code
Post by: David Martin on 10 December, 2015, 10:53:26 pm

4b is nasty. It is taking a while to bruteforce.

Title: Re: Advent of Code
Post by: Afasoas on 10 December, 2015, 10:58:04 pm

Ben T, if we were Golfing (https://en.wikipedia.org/wiki/Code_golf) you'd have beaten me on day 1 :)
I've just seen a version of Day 3 done as a one liner in PERL.

Day 4 looks interesting ... "AdventCoins"

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 12:10:36 am

What was the one liner? I'm fairly sure I can see how to do it but it is probably somewhat obfuscated.

4b is still running. Maybe I was unlucky.

Title: Re: Advent of Code
Post by: Afasoas on 11 December, 2015, 07:27:36 am

Quote from: David Martin on 11 December, 2015, 12:10:36 am

What was the one liner? I'm fairly sure I can see how to do it but it is probably somewhat obfuscated.

https://www.reddit.com/r/adventofcode/comments/3v8roh/day_3_solutions/cxmc1h2

Quote from: David Martin on 11 December, 2015, 12:10:36 am

4b is still running. Maybe I was unlucky.

Still crunching away with this too. It's only using 15% CPU .. I'm wondering if a parallel foreach might have been better...

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 08:50:30 am

Quote from: Afasoas on 11 December, 2015, 07:27:36 am

Quote from: David Martin on 11 December, 2015, 12:10:36 am

What was the one liner? I'm fairly sure I can see how to do it but it is probably somewhat obfuscated.

https://www.reddit.com/r/adventofcode/comments/3v8roh/day_3_solutions/cxmc1h2

That's not really a one-liner. It's about as much as I wrote in Python.

Ready to have a crack at 7, the rest have been straightforward.

Title: Re: Advent of Code
Post by: Ben T on 11 December, 2015, 09:06:14 am

Quote from: David Martin on 10 December, 2015, 10:53:26 pm

4b is nasty. It is taking a while to bruteforce.

Do you know for a fact that bruteforce is the only way?

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 10:18:21 am

It takes a very long time if you have a silly bug in your code :embarassed: Done.

Title: Re: Advent of Code
Post by: Pingu on 11 December, 2015, 10:56:52 am

Did 1a & 1b with javascript  :P

Title: Re: Advent of Code
Post by: Ben T on 11 December, 2015, 11:38:09 am

It appears day 3 can be solved  by munging a 2D space into a 1D one using prime numbers :)
https://github.com/bjtaylor1/AdventOfCode/blob/master/Day3.ps1

Title: Re: Advent of Code
Post by: red marley on 11 December, 2015, 11:55:24 am

For those of us who have come to this late (and thanks Afasoas for point to it), can specific approaches to the solutions be put in spoiler tags please?

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 12:15:58 pm

Quote from: Ben T on 11 December, 2015, 11:38:09 am

It appears day 3 can be solved  by munging a 2D space into a 1D one using prime numbers :)
https://github.com/bjtaylor1/AdventOfCode/blob/master/Day3.ps1

(click to show/hide)

Not got a clue what you are trying to achieve there. The usual thing is to generate a unique hash from the address (x,y) and then count the number of unique addresses at the end. My first mistake was misreading the question as 'more than 1 present'

Title: Re: Advent of Code
Post by: Mr Larrington on 11 December, 2015, 12:28:48 pm

I no longer have access to a VMS Fortran compiler so that's me stuffed ;D

Title: Re: Advent of Code
Post by: Pancho on 11 December, 2015, 12:31:40 pm

Quick - recommend me a programming language (and tools) that an old duffer can use!

A few years back (on another computer) I think I installed python (IIRC - could have been something else) and actually managed to get it to interact with Openstreetmap to draw a map with a particular bus route. IIRC, it was surprisingly easy.

Firstly, a really stupid question - how can I tell if I've already got python installed (Ubuntu is the operating sys and I've found "Terminal" gives me a Ye Olde terminal)?

VMT

Title: Re: Advent of Code
Post by: Ben T on 11 December, 2015, 12:42:08 pm

Quote from: David Martin on 11 December, 2015, 12:15:58 pm

Quote from: Ben T on 11 December, 2015, 11:38:09 am

It appears day 3 can be solved  by munging a 2D space into a 1D one using prime numbers :)
https://github.com/bjtaylor1/AdventOfCode/blob/master/Day3.ps1

(click to show/hide)

Not got a clue what you are trying to achieve there. The usual thing is to generate a unique hash from the address (x,y) and then count the number of unique addresses at the end. My first mistake was misreading the question as 'more than 1 present'

(click to show/hide)

Well that's essentially what I have done, except the unique hash is just a single integer and the hash function is f(x,y) = x + y.
Such a trivial hash  function would normally be unacceptable  due to the prevalence of hash collisions but avoids them by x and y being (multiples of) prime numbers.
it works anyway :)

Title: Re: Advent of Code
Post by: Afasoas on 11 December, 2015, 12:44:26 pm

If you're using Windows, PowerShell is readily available. You could use Python, perl, ruby - the problem is choosing a language.
If you want an IDE you could try Microsoft's Code and then relevant plugin's for your language of choice.

The second link in the OP are my feeble attempts thus far.

Title: Re: Advent of Code
Post by: Pancho on 11 December, 2015, 12:56:54 pm

Quote from: Pancho on 11 December, 2015, 12:31:40 pm

Quick - recommend me a programming language (and tools) that an old duffer can use!

A few years back (on another computer) I think I installed python (IIRC - could have been something else) and actually managed to get it to interact with Openstreetmap to draw a map with a particular bus route. IIRC, it was surprisingly easy.

Firstly, a really stupid question - how can I tell if I've already got python installed (Ubuntu is the operating sys and I've found "Terminal" gives me a Ye Olde terminal)?

VMT

Maybe it wasn't python. Maybe it was perl - I've found I've managed to get a perl manual up on this machine so I prob have it installed already!

Think I'll have a coffee and then set about learning how compiling and running works these days. Then I'll try and learn perl. Then I'll try and do December 1st.

Title: Re: Advent of Code
Post by: Afasoas on 11 December, 2015, 01:04:01 pm

Just running "python -V" will give you the version number.

Code: [Select]

user@cinelli ~ $ python -V
Python 2.7.6


Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 01:35:12 pm

Quote from: Ben T on 11 December, 2015, 12:42:08 pm

(click to show/hide)

Well that's essentially what I have done, except the unique hash is just a single integer and the hash function is f(x,y) = x + y.
Such a trivial hash  function would normally be unacceptable  due to the prevalence of hash collisions but avoids them by x and y being (multiples of) prime numbers.
it works anyway :)

(click to show/hide)

You were lucky. The' x+y is unique if x,y E prime numbers' is a fallacy that is disprovable by the presence of multiple prime pairs. [1]

I just created a simple "x,y" hash myself.

[1] came across this in a PhD thesis once. It was the cornerstone of his algorithm. He failed. [2]
[2] 5+13 == 7+11.
 

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 01:37:42 pm

Dec 1st is extremely simple and should be achievable after lesson 1 of a python course (if they start with string manipulation)
1b could be optimised if you think about how far away you are from where you want to be.

Title: Re: Advent of Code
Post by: red marley on 11 December, 2015, 02:56:45 pm

I like the fact that the second part of each day is not revealed until submitting an answer to the first. That way we are encouraged to think about solutions that might be a little more generalisable.

However for Day 3...

(click to show/hide)

I incorrectly anticipated that part 2 would ask something about the number of presents in each house (e.g. what is the maximum number of presents any one house receives?). I therefore used, in anticipation, a hash map rather than hash set with the key being the location hash and the value being number of presents.

Title: Re: Advent of Code
Post by: Pancho on 11 December, 2015, 03:25:03 pm

Well, I haven't even figured out how to bring a file in a character at a time yet!

Title: Re: Advent of Code
Post by: Ben T on 11 December, 2015, 03:27:09 pm

Quote from: jo on 11 December, 2015, 02:56:45 pm

I like the fact that the second part of each day is not revealed until submitting an answer to the first. That way we are encouraged to think about solutions that might be a little more generalisable.

However for Day 3...

(click to show/hide)

I incorrectly anticipated that part 2 would ask something about the number of presents in each house (e.g. what is the maximum number of presents any one house receives?). I therefore used, in anticipation, a hash map rather than hash set with the key being the location hash and the value being number of presents.

Rule of agile: do as little work as possible. ;)

I didn't even know an extra  bit appeared.... but hardly any modification required however: https://github.com/bjtaylor1/AdventOfCode/blob/master/Day3b.ps1

Title: Re: Advent of Code
Post by: Ben T on 11 December, 2015, 03:34:28 pm

Quote from: David Martin on 11 December, 2015, 01:35:12 pm

Quote from: Ben T on 11 December, 2015, 12:42:08 pm

(click to show/hide)

Well that's essentially what I have done, except the unique hash is just a single integer and the hash function is f(x,y) = x + y.
Such a trivial hash  function would normally be unacceptable  due to the prevalence of hash collisions but avoids them by x and y being (multiples of) prime numbers.
it works anyway :)

(click to show/hide)

You were lucky. The' x+y is unique if x,y E prime numbers' is a fallacy that is disprovable by the presence of multiple prime pairs. [1]

I just created a simple "x,y" hash myself.

[1] came across this in a PhD thesis once. It was the cornerstone of his algorithm. He failed. [2]
[2] 5+13 == 7+11.
 

I agree ;) , but, is there not a condition you could place on the primes  to guarantee it?
My initial 'hunch' was that that condition would be
p1>n AND p2 > n
I have absolutely no idea how to prove that however.
Thinking about it however
would
p1 > p2  x n AND p2 > n
not guarantee it?
Again, no idea how to prove, just a hunch

Can you disprove it?
so if, say,  n = 10, I would choose primes 11 and 113...
i.e. 11 > 10 and 113 > 10* 11.
what moves (values of m1 and m2) would cause a hash collision i.e. such that
m1 * p1 = m2 * p2
where
m1 <= 10
m2 <= 10
p1 = 11
p2 = 113
?
How to prove there are no such values of m1 and m2?
If  I place  that condition do they even need to be prime?

Title: Re: Advent of Code
Post by: Afasoas on 11 December, 2015, 03:42:41 pm

Quote from: Pancho on 11 December, 2015, 03:25:03 pm

Well, I haven't even figured out how to bring a file in a character at a time yet!

http://code.activestate.com/recipes/65118-processing-a-string-one-character-at-a-time/

Title: Re: Advent of Code
Post by: Pancho on 11 December, 2015, 04:48:09 pm

YES!!! YES!!! YES!!!

I've done Day 1! Learned about command line again. Learned about Linux commands. Found "perl", got it running. Tried, tried, and tried again.

And got this (the most shockingly skanky code ever written - but it works!):

(click to show/hide)

#!/usr/bin/perl

use warnings;

$mycounter = 0;
$character;

open DATA, "day1input";

while ($character = getc DATA)

{
if($character eq "("){
   $mycounter = $mycounter + 1;

}elsif ($character eq ")"){
   $mycounter = $mycounter - 1;
}

print $character;
print " ";
print $mycounter;
print " ";


}
print "\n";

print $mycounter;

print "\n";

close

Title: Re: Advent of Code
Post by: Pancho on 11 December, 2015, 04:50:08 pm

Whoops.

It seems I've only done Part 1 of Day 1. Back to the grindstone.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 05:09:14 pm

Invigilating a 3 hour exam allowed the time to get through days 7, 8 and 9.

7 was the hardest, 8 was tricky, 9 easy to bruteforce.

To solve 7:

(click to show/hide)

To understand the solution to 7, first you must understand the solution to 7

I may steal some of these for interview questions.

Title: Re: Advent of Code
Post by: Pingu on 11 December, 2015, 06:48:03 pm

Day 2 done in a spreadsheet  :demon:

Title: Re: Advent of Code
Post by: JonBuoy on 11 December, 2015, 07:11:18 pm

Part 1 of Day 1 done in a word processor   :demon:

Title: Re: Advent of Code
Post by: Pingu on 11 December, 2015, 07:22:24 pm

Day 3 done (javascript).

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 07:37:48 pm

Waiting for 10b to finish running.

Title: Re: Advent of Code
Post by: Pancho on 11 December, 2015, 08:33:06 pm

Still trying to work out how to do arrays.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 10:34:50 pm

10b finished. I was pondering on how best to write the code for 11 but ended up solving both parts by inspection (and only one failed attempt out of 3)

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 10:37:14 pm

Quote from: Pancho on 11 December, 2015, 08:33:06 pm

Still trying to work out how to do arrays.

In perl? Clues to a solution included.

(click to show/hide)

@array=(2,1,3);
@sortedaray = sort @array;
$productoftwosmallestvalues=$sortedarray[0]*$sortedarray[1];

That should be sufficient to help

Title: Re: Advent of Code
Post by: red marley on 11 December, 2015, 11:23:40 pm

Quote from: Afasoas on 11 December, 2015, 07:27:36 am

Quote from: David Martin on 11 December, 2015, 12:10:36 am

4b is still running. Maybe I was unlucky.

Still crunching away with this too. It's only using 15% CPU .. I'm wondering if a parallel foreach might have been better...

Day 4 (MD5)

(click to show/hide)

I guess the keys we get given are random so it might vary a bit for each of us, but my result (9,958,218) only took less than ten seconds to compute. And the code for part b is simpler than part a as an even number of hex digits means you only have to search for three 0 bytes without hex conversion.

Title: Re: Advent of Code
Post by: Pingu on 11 December, 2015, 11:34:09 pm

Day 4 done. It helps when you search for the correct string. "000000" has six characters  :facepalm:

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 11:35:58 pm

Quote from: jo on 11 December, 2015, 11:23:40 pm

Quote from: Afasoas on 11 December, 2015, 07:27:36 am

Quote from: David Martin on 11 December, 2015, 12:10:36 am

4b is still running. Maybe I was unlucky.

Still crunching away with this too. It's only using 15% CPU .. I'm wondering if a parallel foreach might have been better...

Day 4 (MD5)

(click to show/hide)

I guess the keys we get given are random so it might vary a bit for each of us, but my result (9,958,218) only took less than ten seconds to compute. And the code for part b is simpler than part a as an even number of hex digits means you only have to search for three 0 bytes without hex conversion.

(click to show/hide)

My delay was a cockup on my part. The key part was not changing a 5 to a 6 in a comparison

Code: [Select]

string[:5]=='000000' was an infinite condition.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2015, 11:36:45 pm

Quote from: Pingu on 11 December, 2015, 11:34:09 pm

Day 4 done. It helps when you search for the correct string. "000000" has six characters  :facepalm:

You and me both..

Title: Re: Advent of Code
Post by: Oaky on 12 December, 2015, 12:35:33 am

Just started this today.  I did 1 and 2 (chose Python, mainly because I learnt it fairly recently, but it fell into disuse and I wanted to blow some cobwebs away).

Was particularly chuffed with (2) because the approach I took fro part a turned out to be trivially extensible for part b.  The meat of which is this:-

(click to show/hide)

Code: [Select]

print "paper", sum(map(paper,presents))
print "ribbon", sum(map(ribbon,presents))


the full code (including a few test cases) is here:-

(click to show/hide)

Code: [Select]

#!/usr/bin/env python2

# get the input
fd = open("input.txt", 'r')
input_data = fd.read()
fd.close()

presents = input_data.split()

def paper(present):
    (l, w, h)=sorted(map(int, present.split('x')))
    return 3*l*w + 2*l*h + 2*w*h

def ribbon(present):
    (l, w, h)=sorted(map(int, present.split('x')))
    return 2*(l+w) + l*w*h

#tests:-
print "test cases - dimensions, paper, ribbon"
print "2x3x4 ",paper('2x3x4'),ribbon('2x3x4')
print "4x3x2 ",paper('4x3x2'),ribbon('4x3x2')
print "1x1x10 ",paper('1x1x10'),ribbon('1x1x10')

print ""
print "paper", sum(map(paper,presents))
print "ribbon", sum(map(ribbon,presents))


Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 09:43:24 am

OK, I really didn't want to ask for help - but I'm really stumped. Still on Day 2 Part 1!

In my defence, I am learning everything on the job - from command line linux, use of editors, through to the actual language itself. Solving the problems, as you can see, are a long way down the line.

Anyway, I've done this (please excuse all the comments (I'd get lost without them) and the "print" diagnostics (don't have a debugger)):

(click to show/hide)

Code: [Select]

#!/usr/bin/perl

use warnings;

# Title: Advent Day 2 - Wrapping Paper Calculation
#
# Strategy: 1. Load 3 arrays (Length, Width, Height) from data file using "split" within a "while" loop
# 2. Use a "while" loop to go through arrays and caclutate paper needed for each parcel.
# 2b. Store results for each parcel in 2 further arrays (Wrap and Slack) in case needed in future.
# 3. Sum it all up and print result.


# Section : Variable Declarations
#
# Comment: Not sure if necessary with Perl but useful to see what I'm using

$InputLine; # Load one line at a time from input file into here for processing
$ParcelCount; # A counter for loops and pointer to arrays
@ParcelLength; # Array of parcel lengths - from input file
@ParcelWidth; # Array of parcel widths - from input file
@ParcelHeight; # Array of parcel heights - from input file
@ParcelArea; # Array of parcel areas - calculated
@ParcelSlack; # Array of slack wrapper needed - calculated
@InputParcelDimensions; # Temporary array used to split out data from line-by-line input
@ParcelSidesSorted; # Temporary array used to allow "sort" function to work out smallest side
$TotalMainWrap; # Cumulative total of main wrap requirement
$TotalSlackWrap; # Cumulative total of slack wrap requirement
$TotalWrap; # Sum of main and slack wrap requirements
$SackSize = 100; # Set to 1000 for full dataset or 100 for diagnostics (to examine printed output manageably)

# Section : Data load-in from input file
#
# Comment: Use "split" to break into parts using "x" as the splitting character

open (FILE, day2input);

$ParcelCount = 0; # Perl arrays start at 0

while (<FILE>)
{
$InputLine = $_; # "$_" is the input from file, line by line. I think.

chomp ($InputLine); # Removes any line break characters. Not sure if necessary

@InputParcelDimensions = split /x/, $InputLine; # from, say, "12x34x2" creates a 1 x 3 array of 12, 34, 2.

print "$InputParcelDimensions[0] $InputParcelDimensions[1] $InputParcelDimensions[2]";
print "\n";

$ParcelLength[$ParcelCount] = $InputParcelDimensions[0]; # load from temporary array into main array
$ParcelWidth[$ParcelCount] = $InputParcelDimensions[1]; # load from temporary array into main array
$ParcelHeight[$ParcelCount] = $InputParcelDimensions[2]; # load from temporary array into main array

$ParcelCount = $ParcelCount = $ParcelCount + 1; # increment counter
}


print "Array Loaded with $ParcelCount \n";


# Section : Calculate Wrap Required
#
# Comment: Loop through all parcels and caculate and store wrap and slack area for each.
# Also, keep a running total of wrap and slack and total at end for result.
# Array of individual measurements may (or may not) save time in Part 2.
# Area = 2*l*w + 2*w*h + 2*h*l
# Slack = area of smallest side (ie find two smallest of l, w, h and multiply)

$ParcelCount = 0;
$TotalMainWrap = 0;
$TotalSlackWrap = 0;
$TotalWrap = 0;

while ($ParcelCount < $SackSize)
{

$ParcelArea[$ParcelCount] = (2*$ParcelLength[$ParcelCount]*$ParcelWidth[$ParcelCount])+(2*$ParcelWidth[$ParcelCount]*$ParcelHeight[$ParcelCount])+(2*$ParcelHeight[$ParcelCount]*$ParcelLength[$ParcelCount]);

# Notes on sort function:
# It doesn't sort numbers unless you include { $a <=> $b }
# No, I don't know why but I found the advice on google

@ParcelSidesSorted = sort{ $a <=> $b }($ParcelLength[$ParcelCount],$ParcelWidth[$ParcelCount],$ParcelHeight[$ParcelCount]);

print "$ParcelSidesSorted[0] $ParcelSidesSorted[1] $ParcelSidesSorted[2] \n";

$ParcelSlack[$ParcelCount] = $ParcelSidesSorted[0]*$ParcelSidesSorted[1];

$TotalMainWrap = $TotalMainWrap + $ParcelArea[$ParcelCount];
$TotalSlackWrap = $TotalSlackWrap + $ParcelSlack[$ParcelCount];

# print "(Parcel : $ParcelCount   ";
# print "L: $ParcelLength[$ParcelCount] ";
# print "W: $ParcelWidth[$ParcelCount] ";
# print "H: $ParcelHeight[$ParcelCount] ";
# print "A: $ParcelArea[$ParcelCount] ";
# print "S: $ParcelSlack[$ParcelCount]";
# print $TotalMainWrap;
# print ") \n";

$ParcelCount = $ParcelCount = $ParcelCount + 1;
}

Everything seems to work except my calculation of the "slack" paper needed. The sort function works (well, now it does - apparently it doesn't sort numbers without that bit of extra code - took me a long time to work that out) and I take the two lowest and multiply them together - and get guff!

Maybe it's confusing text and numbers? But why does it work for the other instances of multiplication?

Baffled and stuck - help required!

VMT.

Title: Re: Advent of Code
Post by: red marley on 12 December, 2015, 09:56:13 am

Pancho, I don't know much about Perl so can't help you there, but here's a hint on the algorithm...

(click to show/hide)

You don't need to sort the dimensions to find the two smallest out of three. Finding the max() of the three dimensions makes things simpler.

Title: Re: Advent of Code
Post by: David Martin on 12 December, 2015, 10:07:00 am

The code seems to run for me (once the filename is changed) and seems to give a credible answer. It is going round the houses a long way, looping through the data twice.

Title: Re: Advent of Code
Post by: David Martin on 12 December, 2015, 10:14:42 am

Day 12 first part is trivial for a unix hacker. The second part means the quick solution to part A is not extensible but you have to have a proper parser.

Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 10:21:01 am

Quote

The code seems to run for me (once the filename is changed) and seems to give a credible answer. It is going round the houses a long way, looping through the data twice.

The reason for going round the houses is simply because I have to test everything step by step as I've no idea how things (even loops) actually work. It took me a long time to work out how to load in data so I got that working first. Then I had to work out how to manipulate arrays - but didn't want to muck up the bit I'd got working!

Also, it feels tidier to do things in chunks. Set up some arrays. Load them from a file. Do stuff with them. If you mung all that together, it gets terribly confusing terribly rapidly (well, to an old codger like me).

I spent a long time down a dead-end route. Tried to set up a multi-dimensional array to hold everything but multi-dimensional arrays seemed to be unnecessarily complex so gave up. But I'd still rather have all the data for Parcel x held in ParcelData (ParcelID, Length, Width, Height, Area, Slack).

Anyway, if it broadly works for you, WTF does it tell me:

 (Parcel : 0   L: 3 W: 11 H: 24 A: 738 S: 33738) ?

Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 10:37:31 am

And yet, when I sum up all the Slacks, it gives a believable answer?

Which turns out to be the correct answer.

Must be something to do with my diagnostic print statements. But I'm stuffed if I know what.

Anyway, on to Day 2, Part 2.

Title: Re: Advent of Code
Post by: Afasoas on 12 December, 2015, 11:48:15 am

Quote from: David Martin on 11 December, 2015, 11:36:45 pm

Quote from: Pingu on 11 December, 2015, 11:34:09 pm

Day 4 done. It helps when you search for the correct string. "000000" has six characters  :facepalm:

You and me both..

+1 .. :/

Title: Re: Advent of Code
Post by: Pingu on 12 December, 2015, 12:15:37 pm

Quote from: Afasoas on 12 December, 2015, 11:48:15 am

Quote from: David Martin on 11 December, 2015, 11:36:45 pm

Quote from: Pingu on 11 December, 2015, 11:34:09 pm

Day 4 done. It helps when you search for the correct string. "000000" has six characters  :facepalm:

You and me both..

+1 .. :/

Is that some sort of regex?

Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 12:28:51 pm

Day 3 has got me puzzling. There must be a quicker way of doing it than just moving around a virtual x and y grid. Something to do with summing up all the moves or something.

But it's beyond my brain to figure it out.

So, I'm sticking with trekking a counter around a virtual board. Which will take me long enough to actually programme - it's taken me this long to work out how to get hold of one character at a time.

Title: Re: Advent of Code
Post by: red marley on 12 December, 2015, 12:37:57 pm

Day 3 hint

(click to show/hide)

You don't need to store an entire grid or use a grid structure. Just store a list of coordinate pairs visited and only add to that list if the current position is not already in contained within it.

Title: Re: Advent of Code
Post by: David Martin on 12 December, 2015, 12:38:29 pm

Day 3. I think you have to remember where you have been.

(click to show/hide)

Create a unique address for each house - a perl hash is ideal for this. I made one based on the cartesian coordinates.

Title: Re: Advent of Code
Post by: Pingu on 12 December, 2015, 01:31:24 pm

(click to show/hide)

For each step add the new coordinate to an array. Then check if coordinate is already in the array. This was in Javascript, it may be easier in other languages.

Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 01:50:03 pm

Cracked Day 3 Part 1:

(click to show/hide)

Code: [Select]

#!/usr/bin/perl

use warnings;

# note on initialisation of arrays
# the "= (0) x @houses" bits are an attempt to initialise the arrays
# not sure it's worked as I get shedfuls of warnings
# warnings may be due to some sort of scope issues but what do I know?

@houses = (0) x @houses; # array of locations
@input = (" ") x @input; # load the input file into this array
$xpos=7000; # start way high as I don't know how -ves are handled
$ypos=7000;
$luckybastards = 1; # parcel delivered at start point

open (FILE, day3input) or die; #change filename when testing complete

while (<FILE>)
{

$houses[$xpos][$ypos] = 1; # mark that I've been to house at ground zero

@input = split //; # load in input file to array

for $input(@input) # loop through input array of directions
{

if ($input eq "<") # change coords iaw with next direction instruction
{
$xpos=$xpos-1;
}
elsif ($input eq ">")
{
$xpos=$xpos+1;
}
elsif ($input eq "^")
{
$ypos=$ypos+1;
}
else
{
$ypos=$ypos-1;
}

print "X: $xpos Y: $ypos Previous: $houses[$xpos][$ypos]\n";

if ($houses[$xpos][$ypos] == 0) # check whether I've been here before
{
$luckybastards = $luckybastards + 1; # if not then increment the counter
}

$houses[$xpos][$ypos] = 1; # mark that I have been here before
}

}

print "\nLucky Bastards: $luckybastards \n";

It works but I get shedloads of warnings about unitialised values. I've tried to stop that but failed.

Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 01:51:48 pm

I'd deliberately not looked at the hints until now as I wasn't fully stuck.

I think I've sort of done what you describe - but differently.

Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 02:11:14 pm

3b's in the bag - and I've done my first subroutines (santamove, and robomove!).

Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 02:39:33 pm

I don't even understand the question for Day 4. Well, I do a bit - I vaguely remember some of the jargon.

I'll spend some time on google - that usually cures all ignorance.

But, at first glance, it's either stupidly difficult (write code to do MD5 hashing (whatever that is)) or just boring (keep chucking numbers into existing MD5 functions until you get one back with the appropriate number of zeroes. It's possible I've misunderstood!

Title: Re: Advent of Code
Post by: red marley on 12 December, 2015, 03:04:33 pm

MD5 hashing isn't that different in principle to what you did for Day 3. Hashing is just a transformation of some collection of data (e.g. the row and column representing Santa's location) into a single number known as a hash. The key to making the hashing transformation useful is that you want to be pretty sure that the same original data always gives the same hash, and that data collections that are different give different hashes.

The MD5 and other cryptographic hash transformations have the additional property that given the hash, you cannot easily retrieve the original data. It is now known how to break the MD5 hashing such that you can retrieve the original data, but for the purposes of this advent exercise, that's not necessary.

(click to show/hide)

For Day 4, brute force is good enough. Indeed, this is exactly what real bitcoin mining involves. I wouldn't waste time coding up the MD5 hashing itself, but rely on an existing library to do that bit. The challenge code just needs to find a reasonably quick way of spotting those hashes with leading zeros.

Title: Re: Advent of Code
Post by: Afasoas on 12 December, 2015, 03:26:07 pm

Just catching up. Day 5 with some regular expressions.
A bit of regex solves anything :)

(click to show/hide)

Code: [Select]

("rthkunfaakmwmush
qxlnvjguikqcyfzt
sleaoasjspnjctqt
.
.
.
mfifrjamczjncuym
otmgvsykuuxrluky
oiuroieurpyejuvm").split("`n") | %{ `
    (([regex]::Matches($_, '(a|e|i|o|u)')).count -gt 2) -and `
    ($_ -match '(.)\1') -and `
    ($_ -notmatch '(ab|cd|pq|xy)') -and `
    $niceStrings1++
   
    ($_ -match '(..).*\1') -and `
    ($_ -match '(.).\1') -and `
    $niceStrings2++
    }| Out-Null ; Write-Host "Part 1: Nice Strings: $niceStrings1" ; Write-Host "Part 2: Nice Strings: $niceStrings2"

Answer:

(click to show/hide)

Part 1: Nice Strings: 258
Part 2: Nice Strings: 53

Title: Re: Advent of Code
Post by: Pingu on 12 December, 2015, 03:54:22 pm

Quote from: Afasoas on 12 December, 2015, 03:26:07 pm

Just catching up. Day 5 with some regular expressions.
A bit of regex solves anything :)

(click to show/hide)

Code: [Select]

("rthkunfaakmwmush
qxlnvjguikqcyfzt
sleaoasjspnjctqt
.
.
.
mfifrjamczjncuym
otmgvsykuuxrluky
oiuroieurpyejuvm").split("`n") | %{ `
    (([regex]::Matches($_, '(a|e|i|o|u)')).count -gt 2) -and `
    ($_ -match '(.)\1') -and `
    ($_ -notmatch '(ab|cd|pq|xy)') -and `
    $niceStrings1++
   
    ($_ -match '(..).*\1') -and `
    ($_ -match '(.).\1') -and `
    $niceStrings2++
    }| Out-Null ; Write-Host "Part 1: Nice Strings: $niceStrings1" ; Write-Host "Part 2: Nice Strings: $niceStrings2"

Answer:

(click to show/hide)

Part 1: Nice Strings: 258
Part 2: Nice Strings: 53

(click to show/hide)

Santa's a bit tough

Title: Re: Advent of Code
Post by: Pingu on 12 December, 2015, 03:55:35 pm

Day 5 done.

Title: Re: Advent of Code
Post by: red marley on 12 December, 2015, 04:13:25 pm

I've set up a 'private leaderboard' for YACF if anyone wishes to join it. The access code is 48462-ea506236

Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 04:26:22 pm

Quote from: jo on 12 December, 2015, 04:13:25 pm

I've set up a 'private leaderboard' for YACF if anyone wishes to join it. The access code is 48462-ea506236

I think I must have hit the anon login option as I have the memorable moniker of "anonymous user #49001".

Title: Re: Advent of Code
Post by: red marley on 12 December, 2015, 04:43:20 pm

Should you wish, you can change this to whatever name you use for authenticating access to the Advent site through the 'settings' option.

Title: Re: Advent of Code
Post by: red marley on 12 December, 2015, 04:45:14 pm

Not necessary for completing the task, but as I like drawing pictures this is the pattern of lights for my version of Day 6 part b:

(http://staff.city.ac.uk/~jwo/acf/adventLights.jpg)

Title: Re: Advent of Code
Post by: Pancho on 12 December, 2015, 05:42:59 pm

I've got to out now so can't do any more this eve :(

Also tomorrow's out as I'm picking up my daughter from the airport after 4 months away from home :)

Title: Re: Advent of Code
Post by: Diver300 on 12 December, 2015, 06:46:30 pm

Days 1 - 3 solved using spreadsheets.

It's not efficient and the computer struggles to run the spreadsheets.

Title: Re: Advent of Code
Post by: David Martin on 12 December, 2015, 10:48:12 pm

Quote from: Diver300 on 12 December, 2015, 06:46:30 pm

Days 1 - 3 solved using spreadsheets.

It's not efficient and the computer struggles to run the spreadsheets.

Tht sounds like masochism. Just becasue you can, doesn't mean you should. You may find Day 4 a bit hard to do on a spreadsheet.

Title: Re: Advent of Code
Post by: Kim on 12 December, 2015, 10:59:59 pm

I ended up simulating neural networks using speadsheets for my final year research project (because reasons).  I wouldn't recommend it, unless you specifically want to make Clippy cry, but it's amazing what you can abuse them for if you're sufficiently determined/desperate/masochistic.

Title: Re: Advent of Code
Post by: Diver300 on 13 December, 2015, 10:02:05 am

My reusability of code fell down flat.
Part 5a solved on a spreadsheet
Part 5b used javascipt

(click to show/hide)

Part 4 made soooo much easier went from nearly impossible to fairly trivial when I found that the php server that I can run code on has an MD5 function

Title: Re: Advent of Code
Post by: Diver300 on 13 December, 2015, 10:15:33 am

Quote from: jo on 12 December, 2015, 04:45:14 pm

Not necessary for completing the task, but as I like drawing pictures this is the pattern of lights for my version of Day 6 part b:

(http://staff.city.ac.uk/~jwo/acf/adventLights.jpg)

(click to show/hide)

If you had saved that as a .gif we could have counted the lit pixels

Title: Re: Advent of Code
Post by: red marley on 13 December, 2015, 10:19:25 am

Quote from: Diver300 on 13 December, 2015, 10:15:33 am

(click to show/hide)

If you had saved that as a .gif we could have counted the lit pixels

You could have, but I believe each dataset is unique to your ID, so it wouldn't have got you very far.

Title: Re: Advent of Code
Post by: Pingu on 13 December, 2015, 12:06:39 pm

I must be missing something obvious in 6a. It doesn't look that difficult, but I'm not getting the right answer. My code seems to work for small data sets, but fails for the full problem set.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2015, 01:23:10 pm

Quote from: Pingu on 13 December, 2015, 12:06:39 pm

I must be missing something obvious in 6a. It doesn't look that difficult, but I'm not getting the right answer. My code seems to work for small data sets, but fails for the full problem set.

Off by one error somewhere?

I reverted to building a 2D matrix in numpy

I couldn't readily work out an elegant way of solving 11, and by the time I had thought about how to solve it I already had by inspection.

..d

Title: Re: Advent of Code
Post by: Pingu on 13 December, 2015, 01:40:25 pm

Quote from: David Martin on 13 December, 2015, 01:23:10 pm

Quote from: Pingu on 13 December, 2015, 12:06:39 pm

I must be missing something obvious in 6a. It doesn't look that difficult, but I'm not getting the right answer. My code seems to work for small data sets, but fails for the full problem set.

Off by one error somewhere?

Maybe, but I can't see where.

Would someone who's done 6a like to try it with my data set and let me know what you get? Here's the set:

turn off 660,55 through 986,197
turn off 341,304 through 638,850
turn off 199,133 through 461,193
toggle 322,558 through 977,958
toggle 537,781 through 687,941
turn on 226,196 through 599,390
turn on 240,129 through 703,297
turn on 317,329 through 451,798
turn on 957,736 through 977,890
turn on 263,530 through 559,664
turn on 158,270 through 243,802
toggle 223,39 through 454,511
toggle 544,218 through 979,872
turn on 313,306 through 363,621
toggle 173,401 through 496,407
toggle 333,60 through 748,159
turn off 87,577 through 484,608
turn on 809,648 through 826,999
toggle 352,432 through 628,550
turn off 197,408 through 579,569
turn off 1,629 through 802,633
turn off 61,44 through 567,111
toggle 880,25 through 903,973
turn on 347,123 through 864,746
toggle 728,877 through 996,975
turn on 121,895 through 349,906
turn on 888,547 through 931,628
toggle 398,782 through 834,882
turn on 966,850 through 989,953
turn off 891,543 through 914,991
toggle 908,77 through 916,117
turn on 576,900 through 943,934
turn off 580,170 through 963,206
turn on 184,638 through 192,944
toggle 940,147 through 978,730
turn off 854,56 through 965,591
toggle 717,172 through 947,995
toggle 426,987 through 705,998
turn on 987,157 through 992,278
toggle 995,774 through 997,784
turn off 796,96 through 845,182
turn off 451,87 through 711,655
turn off 380,93 through 968,676
turn on 263,468 through 343,534
turn on 917,936 through 928,959
toggle 478,7 through 573,148
turn off 428,339 through 603,624
turn off 400,880 through 914,953
toggle 679,428 through 752,779
turn off 697,981 through 709,986
toggle 482,566 through 505,725
turn off 956,368 through 993,516
toggle 735,823 through 783,883
turn off 48,487 through 892,496
turn off 116,680 through 564,819
turn on 633,865 through 729,930
turn off 314,618 through 571,922
toggle 138,166 through 936,266
turn on 444,732 through 664,960
turn off 109,337 through 972,497
turn off 51,432 through 77,996
turn off 259,297 through 366,744
toggle 801,130 through 917,544
toggle 767,982 through 847,996
turn on 216,507 through 863,885
turn off 61,441 through 465,731
turn on 849,970 through 944,987
toggle 845,76 through 852,951
toggle 732,615 through 851,936
toggle 251,128 through 454,778
turn on 324,429 through 352,539
toggle 52,450 through 932,863
turn off 449,379 through 789,490
turn on 317,319 through 936,449
toggle 887,670 through 957,838
toggle 671,613 through 856,664
turn off 186,648 through 985,991
turn off 471,689 through 731,717
toggle 91,331 through 750,758
toggle 201,73 through 956,524
toggle 82,614 through 520,686
toggle 84,287 through 467,734
turn off 132,367 through 208,838
toggle 558,684 through 663,920
turn on 237,952 through 265,997
turn on 694,713 through 714,754
turn on 632,523 through 862,827
turn on 918,780 through 948,916
turn on 349,586 through 663,976
toggle 231,29 through 257,589
toggle 886,428 through 902,993
turn on 106,353 through 236,374
turn on 734,577 through 759,684
turn off 347,843 through 696,912
turn on 286,699 through 964,883
turn on 605,875 through 960,987
turn off 328,286 through 869,461
turn off 472,569 through 980,848
toggle 673,573 through 702,884
turn off 398,284 through 738,332
turn on 158,50 through 284,411
turn off 390,284 through 585,663
turn on 156,579 through 646,581
turn on 875,493 through 989,980
toggle 486,391 through 924,539
turn on 236,722 through 272,964
toggle 228,282 through 470,581
toggle 584,389 through 750,761
turn off 899,516 through 900,925
turn on 105,229 through 822,846
turn off 253,77 through 371,877
turn on 826,987 through 906,992
turn off 13,152 through 615,931
turn on 835,320 through 942,399
turn on 463,504 through 536,720
toggle 746,942 through 786,998
turn off 867,333 through 965,403
turn on 591,477 through 743,692
turn off 403,437 through 508,908
turn on 26,723 through 368,814
turn on 409,485 through 799,809
turn on 115,630 through 704,705
turn off 228,183 through 317,220
toggle 300,649 through 382,842
turn off 495,365 through 745,562
turn on 698,346 through 744,873
turn on 822,932 through 951,934
toggle 805,30 through 925,421
toggle 441,152 through 653,274
toggle 160,81 through 257,587
turn off 350,781 through 532,917
toggle 40,583 through 348,636
turn on 280,306 through 483,395
toggle 392,936 through 880,955
toggle 496,591 through 851,934
turn off 780,887 through 946,994
turn off 205,735 through 281,863
toggle 100,876 through 937,915
turn on 392,393 through 702,878
turn on 956,374 through 976,636
toggle 478,262 through 894,775
turn off 279,65 through 451,677
turn on 397,541 through 809,847
turn on 444,291 through 451,586
toggle 721,408 through 861,598
turn on 275,365 through 609,382
turn on 736,24 through 839,72
turn off 86,492 through 582,712
turn on 676,676 through 709,703
turn off 105,710 through 374,817
toggle 328,748 through 845,757
toggle 335,79 through 394,326
toggle 193,157 through 633,885
turn on 227,48 through 769,743
toggle 148,333 through 614,568
toggle 22,30 through 436,263
toggle 547,447 through 688,969
toggle 576,621 through 987,740
turn on 711,334 through 799,515
turn on 541,448 through 654,951
toggle 792,199 through 798,990
turn on 89,956 through 609,960
toggle 724,433 through 929,630
toggle 144,895 through 201,916
toggle 226,730 through 632,871
turn off 760,819 through 828,974
toggle 887,180 through 940,310
toggle 222,327 through 805,590
turn off 630,824 through 885,963
turn on 940,740 through 954,946
turn on 193,373 through 779,515
toggle 304,955 through 469,975
turn off 405,480 through 546,960
turn on 662,123 through 690,669
turn off 615,238 through 750,714
turn on 423,220 through 930,353
turn on 329,769 through 358,970
toggle 590,151 through 704,722
turn off 884,539 through 894,671
toggle 449,241 through 984,549
toggle 449,260 through 496,464
turn off 306,448 through 602,924
turn on 286,805 through 555,901
toggle 722,177 through 922,298
toggle 491,554 through 723,753
turn on 80,849 through 174,996
turn off 296,561 through 530,856
toggle 653,10 through 972,284
toggle 529,236 through 672,614
toggle 791,598 through 989,695
turn on 19,45 through 575,757
toggle 111,55 through 880,871
turn off 197,897 through 943,982
turn on 912,336 through 977,605
toggle 101,221 through 537,450
turn on 101,104 through 969,447
toggle 71,527 through 587,717
toggle 336,445 through 593,889
toggle 214,179 through 575,699
turn on 86,313 through 96,674
toggle 566,427 through 906,888
turn off 641,597 through 850,845
turn on 606,524 through 883,704
turn on 835,775 through 867,887
toggle 547,301 through 897,515
toggle 289,930 through 413,979
turn on 361,122 through 457,226
turn on 162,187 through 374,746
turn on 348,461 through 454,675
turn off 966,532 through 985,537
turn on 172,354 through 630,606
turn off 501,880 through 680,993
turn off 8,70 through 566,592
toggle 433,73 through 690,651
toggle 840,798 through 902,971
toggle 822,204 through 893,760
turn off 453,496 through 649,795
turn off 969,549 through 990,942
turn off 789,28 through 930,267
toggle 880,98 through 932,434
toggle 568,674 through 669,753
turn on 686,228 through 903,271
turn on 263,995 through 478,999
toggle 534,675 through 687,955
turn off 342,434 through 592,986
toggle 404,768 through 677,867
toggle 126,723 through 978,987
toggle 749,675 through 978,959
turn off 445,330 through 446,885
turn off 463,205 through 924,815
turn off 417,430 through 915,472
turn on 544,990 through 912,999
turn off 201,255 through 834,789
turn off 261,142 through 537,862
turn off 562,934 through 832,984
turn off 459,978 through 691,980
turn off 73,911 through 971,972
turn on 560,448 through 723,810
turn on 204,630 through 217,854
turn off 91,259 through 611,607
turn on 877,32 through 978,815
turn off 950,438 through 974,746
toggle 426,30 through 609,917
toggle 696,37 through 859,201
toggle 242,417 through 682,572
turn off 388,401 through 979,528
turn off 79,345 through 848,685
turn off 98,91 through 800,434
toggle 650,700 through 972,843
turn off 530,450 through 538,926
turn on 428,559 through 962,909
turn on 78,138 through 92,940
toggle 194,117 through 867,157
toggle 785,355 through 860,617
turn off 379,441 through 935,708
turn off 605,133 through 644,911
toggle 10,963 through 484,975
turn off 359,988 through 525,991
turn off 509,138 through 787,411
toggle 556,467 through 562,773
turn on 119,486 through 246,900
turn on 445,561 through 794,673
turn off 598,681 through 978,921
turn off 974,230 through 995,641
turn off 760,75 through 800,275
toggle 441,215 through 528,680
turn off 701,636 through 928,877
turn on 165,753 through 202,780
toggle 501,412 through 998,516
toggle 161,105 through 657,395
turn on 113,340 through 472,972
toggle 384,994 through 663,999
turn on 969,994 through 983,997
turn on 519,600 through 750,615
turn off 363,899 through 948,935
turn on 271,845 through 454,882
turn off 376,528 through 779,640
toggle 767,98 through 854,853
toggle 107,322 through 378,688
turn off 235,899 through 818,932
turn on 445,611 through 532,705
toggle 629,387 through 814,577
toggle 112,414 through 387,421
toggle 319,184 through 382,203
turn on 627,796 through 973,940
toggle 602,45 through 763,151
turn off 441,375 through 974,545
toggle 871,952 through 989,998
turn on 717,272 through 850,817
toggle 475,711 through 921,882
toggle 66,191 through 757,481
turn off 50,197 through 733,656
toggle 83,575 through 915,728
turn on 777,812 through 837,912
turn on 20,984 through 571,994
turn off 446,432 through 458,648
turn on 715,871 through 722,890
toggle 424,675 through 740,862
toggle 580,592 through 671,900
toggle 296,687 through 906,775

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2015, 01:44:06 pm

Sorry, I had a power failure and lost my scratch file with the code in.

Title: Re: Advent of Code
Post by: red marley on 13 December, 2015, 02:06:39 pm

Pingu, with your light instructions, I get 400410 left on.

Which looks like this:

(http://staff.city.ac.uk/~jwo/acf/adventLightsPingu.png)

and for part b, like this:

(http://staff.city.ac.uk/~jwo/acf/adventLights2Pingu.jpg)

(which clearly shows an image of Jesus imprinted on it, so you must have a very special set of instructions)

Title: Re: Advent of Code
Post by: red marley on 13 December, 2015, 04:50:12 pm

Quote from: David Martin on 11 December, 2015, 07:37:48 pm

Waiting for 10b to finish running.

(click to show/hide)

In what environment are you computing the answer? When I ran 10b in Java, it took less than a second (starting sequence '1113122113' leading to a string of length 5,103,798).

Title: Re: Advent of Code
Post by: Pancho on 13 December, 2015, 04:59:44 pm

Waiting for 4b to spit out an answer. (4a turned out to be the trivially boring case).

Title: Re: Advent of Code
Post by: Pingu on 13 December, 2015, 05:39:35 pm

Quote from: jo on 13 December, 2015, 02:06:39 pm

Pingu, with your light instructions, I get 400410 left on.

Thanks jo  :thumbsup:

Title: Re: Advent of Code
Post by: red marley on 13 December, 2015, 05:46:57 pm

Does that mean you spotted the reason why you were not getting the correct result? One of the difficult aspects of that particular challenge is that is a hard one to debug.

Title: Re: Advent of Code
Post by: Pingu on 13 December, 2015, 05:57:27 pm

It was thanks for trying my data with your solution  :)

I have found the reason why my code didn't work. It was because it extracted strings rather than numbers for the coordinates from the instructions  :facepalm: One day I will learn  ::-)

6a completed.

Title: Re: Advent of Code
Post by: Pingu on 13 December, 2015, 05:59:19 pm

Quote from: jo on 13 December, 2015, 02:06:39 pm

(http://staff.city.ac.uk/~jwo/acf/adventLights2Pingu.jpg)

(which clearly shows an image of Jesus imprinted on it, so you must have a very special set of instructions)

I thought yours looked a bit like Bender.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2015, 06:32:24 pm

Quote from: jo on 13 December, 2015, 04:50:12 pm

Quote from: David Martin on 11 December, 2015, 07:37:48 pm

Waiting for 10b to finish running.

(click to show/hide)

In what environment are you computing the answer? When I ran 10b in Java, it took less than a second (starting sequence '1113122113' leading to a string of length 5,103,798).

Python on an aging mac. It took a little while, probably my fault for writing stupidly inefficient code. (Couple of minutes? - didn't matter as I was half way through a rather tedious exam invigilation).

Title: Re: Advent of Code
Post by: Pingu on 13 December, 2015, 06:57:49 pm

Quote from: Pingu on 13 December, 2015, 05:57:27 pm

It was thanks for trying my data with your solution  :)

I have found the reason why my code didn't work. It was because it extracted strings rather than numbers for the coordinates from the instructions  :facepalm: One day I will learn  ::-)

6a completed.

And so 6b took about 5 minutes.

Title: Re: Advent of Code
Post by: red marley on 13 December, 2015, 09:08:07 pm

I'm finding Day 12 (JSON parsing) rather frustrating.

(click to show/hide)

Part A can be trivially found with a simple regex that splits by non-numeric characters. But Part B seems to need a JSON parser. The one that I normally use doesn't like the JSON provided by the challenge, and I don't really want to waste time writing my own. This is the first of the questions I am tempted to skip although the completionist in me will inevitably tempt me back to it.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2015, 09:35:05 pm

You could do it with a stream parser, though I tried it and my code didn't work so reverted to a json parser and a recursive tree walker function to do the addition.
Did you write code for 11? I started to think about how I would code it but had solved it by inspection before I worked out how I would code it.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2015, 09:37:18 pm

Day 13

(click to show/hide)

Simple permutation chcking, though it could be done more optimally if you remember that it is symmetrical and circular. I took n*n/2 times more time than I needed to.

Title: Re: Advent of Code
Post by: Afasoas on 13 December, 2015, 11:50:11 pm

Really excited by the number of people taking part. Unfortunately I've not had much weekend time to catch up.. 7 days behind  :-\

Title: Re: Advent of Code
Post by: tonycollinet on 14 December, 2015, 06:04:13 am

I've just done days one and two in a spreadsheet. Not gonna work for day 3.


So can anyone suggest a mac based easy to setup and use programming environment. I used to do C a long time ago. Not worried about (re)learning to code, but could do without the pain of learning a clunky environment.

Something with instant feedback would be good. Along the lines of

Print "Hello World"
Run
Hello World

Would be great :-)

Title: Re: Advent of Code
Post by: red marley on 14 December, 2015, 07:08:26 am

http://processing.org

It's based on Java, so shares a C like syntax, but with a lower barrier to entry. I've used it to answer the first 12 days' advent questions so far.

println("hello world!");

works straight out of the box.

Loading text files is easy (loadStrings()), as is conversion to character arrays (.toCharArray()) and regular expressions, all of which are helpful for the challenge.

Title: Re: Advent of Code
Post by: Pancho on 14 December, 2015, 09:02:19 am

@tonycollinet: from a background of non-coder scared of incomprehensible IDEs, I'm using perl that I found was already on my computer. I just use an ascii text editor to write code, save it, then use perl to compile and run. I think Macs have perl onboard by default. Type perl -v to find version.

Title: Re: Advent of Code
Post by: Oaky on 14 December, 2015, 11:26:02 am

I completed day 7 last night.  It took me a lot longer than I'd anticipated.

(click to show/hide)

Initially, I thought I may have a bug in my code that was hitting an endless loop for the actual problem data whilst workign fine on the example in the instructions.  After an hour of running, it was still going, and I had no way of knowing what it was doing, or whether it was jumping back and forth between nodes (or traversing a loop or something).

Whilst working out how to instrument my code so I could visualise the depth of recursion (which incidentally indicated that it was in fact doing the right thing - or at least it wasn't OBVIOUSLY stuck in a rut) I spotted a trivial perfromance enhancement which lead to an almost instant answer (initially I didn't cache the output for any particular node, so it was always recalculated recursively.  Adding a cache for each value gave an immense speedup.  Ironically,  I was going to do that initially, but decided against it because I thought that it wasn't going to make much difference.  The speedup is so big that I still don't know how much it sped me up by since I never waited long enough for the un-optimised code to finish running.

Title: Re: Advent of Code
Post by: red marley on 14 December, 2015, 12:08:23 pm

Day 7

(click to show/hide)

Oaky - That's exactly what I experienced - on the fly calculation never completed, but caching the results as they propagate through the network gave the answer in a fraction of a second. I'm not sure why it appears to get stuck without caching as the instructions claim that any one wire only ever feeds into one other and there cannot be any loops otherwise it would never be solved even with caching.

I do love the elegance of recursion, but hate having to debug things when recursion behaves unexpectedly.

Title: Re: Advent of Code
Post by: Pingu on 14 December, 2015, 06:02:05 pm

I've skipped day 7* and done day 8.




*Javascript does the bitwise operations on 32-bit.

Title: Re: Advent of Code
Post by: red marley on 14 December, 2015, 06:21:19 pm

Quote from: Pingu on 14 December, 2015, 06:02:05 pm

I've skipped day 7* and done day 8.

*Javascript does the bitwise operations on 32-bit.

(click to show/hide)

Just mask each 32 bit number with bitwise AND 0x0000ffff to keep things 16 bit friendly.

Title: Re: Advent of Code
Post by: tonycollinet on 14 December, 2015, 07:16:18 pm

processing.org seems to fit the bill

Thanks jo.

Will play after my trip to Germany.


(Thanks also Pancho for the perl suggestion.)

Title: Re: Advent of Code
Post by: Oaky on 14 December, 2015, 07:42:59 pm

Quote from: David Martin on 13 December, 2015, 09:35:05 pm

Did you write code for 11? I started to think about how I would code it but had solved it by inspection before I worked out how I would code it.

I can see the answer to my day 11, also by inspection.  I wrote code but it is still running, though, despite applying some optimisations:-

(click to show/hide)

specifically, jumping ahead whenever an 'i', 'l' or 'o' appears.

I suspect that it will require further logic (perhaps jumping to place runs of consecutive letters in the number etc.) and optimisations before it runs in reasonable time though  :-\

I'm not sure I want to try to code the "by inspection" logic though.

I might re-think the use of the alphabetical string representation of the password, and maybe move to a purely numerical one in the hope of speeding things up a bit.

as an aside, I've been using this as an excuse to start playing around in test-driven development using the Python unittest framework

Code: [Select]

class TestIt(unittest.TestCase):
    # Part 1 tests
       
    def test_01(self):
        self.assertEqual(incr('aa'), 'ab')
 
    def test_02(self):
        self.assertEqual(incr('az'), 'ba')
 
    def test_03(self):
        self.assertEqual(incr('zz'), 'aaa') # my own assumption - not mentioned in TEH RULZ

    def test_04(self):
        self.assertFalse(pwOK('hijklmmn'))

    def test_05(self):
        self.assertFalse(pwOK('abbceffg'))

    def test_06(self):
        self.assertFalse(pwOK('abbcegjk'))

    def test_07(self):
        self.assertTrue(pwOK('abcdffaa'))

    def test_08(self):
        self.assertTrue(pwOK('ghjaabcc'))

(I've hidden some tests as they give a clue to some of the stuff I mention in the spoiler above):-

(click to show/hide)

Code: [Select]

    def test_09(self):
        self.assertEqual(jumpPW('abcdi'), 'abcdj')

    def test_10(self):
        self.assertEqual(jumpPW('obcde'), 'paaaa')

    def test_11(self):
        self.assertEqual(jumpPW('ablde'), 'abmaa')

and the next two are currently commented out because they were taking so long to run, and all of the tests are running before my "production" question gets asked ;)

Code: [Select]

    #def test_12(self):
    #    self.assertEqual(nextPW('abcdefgh'), 'abcdffaa')

    #def test_13(self):
    #    self.assertEqual(nextPW('ghijklmn'), 'ghjaabcc')


Title: Re: Advent of Code
Post by: Oaky on 14 December, 2015, 08:14:59 pm

Re: my Day 11 woes...

As an alternative to looking for optimisations,  I could always just fix the bug that had it spinning in a tight loop going nowhere  :facepalm:

runs in under a second now  ::-)

I am an idiot!

Title: Re: Advent of Code
Post by: red marley on 14 December, 2015, 11:14:57 pm

Finally found an answer to Day 12b (JSON parsing)

(click to show/hide)

Kludged the Processing JSON parser to work with the sample json file. Most parsers seem to be designed to work with a schema where you know what elements / objects / arrays to expect. Since this challenge involves navigating nested arrays and objects with a random structure and set of keys, I had to try for each type and do lots of exception catching when, for example, I tried to read an object when an array was found or integer when a String was found. Not very elegant, but it did find the solution in under a second.

Title: Re: Advent of Code
Post by: David Martin on 14 December, 2015, 11:23:47 pm

Quote from: tonycollinet (recently Andustar) on 14 December, 2015, 07:16:18 pm

processing.org seems to fit the bill

Thanks jo.

Will play after my trip to Germany.


(Thanks also Pancho for the perl suggestion.)

An alternative is the python Anaconda distribution and the Spyder IDE (which is what I have done most of mine in.)

Title: Re: Advent of Code
Post by: David Martin on 14 December, 2015, 11:27:17 pm

Quote from: jo on 14 December, 2015, 11:14:57 pm

Finally found an answer to Day 12b (JSON parsing)

(click to show/hide)

Kludged the Processing JSON parser to work with the sample json file. Most parsers seem to be designed to work with a schema where you know what elements / objects / arrays to expect. Since this challenge involves navigating nested arrays and objects with a random structure and set of keys, I had to try for each type and do lots of exception catching when, for example, I tried to read an object when an array was found or integer when a String was found. Not very elegant, but it did find the solution in under a second.

(click to show/hide)

That is more or less what I did. The python stock json parser provides a list of objects. I wrote a recursive function that would test the type of the object it had been given. If it was an int it would return that value, if a list it would call itself on each element of the list, adding the values up and returning those, and likewise for an object - first check to see if it has a value of 'red' and return 0 if so, else iterate through the values and call the function on each one, adding the result.

Title: Re: Advent of Code
Post by: David Martin on 14 December, 2015, 11:31:31 pm

Quote from: jo on 14 December, 2015, 12:08:23 pm

Day 7

(click to show/hide)

Oaky - That's exactly what I experienced - on the fly calculation never completed, but caching the results as they propagate through the network gave the answer in a fraction of a second. I'm not sure why it appears to get stuck without caching as the instructions claim that any one wire only ever feeds into one other and there cannot be any loops otherwise it would never be solved even with caching.

I do love the elegance of recursion, but hate having to debug things when recursion behaves unexpectedly.

(click to show/hide)

On the fly calculation becomes exponential.
A cache for the instructions for each node works (hash/dictionary with the target as the key) and a hash to contain the value of each node.
Then a recursive function (I seem to like those) that when called with a node name, retrieves the instructions for that node name and calculates them from the cached values. If there were no cached value for a node  then it calls itself on the missing value node name to retrieve the value. And so it propagates and runs in a very short time.

Title: Re: Advent of Code
Post by: Oaky on 15 December, 2015, 12:12:05 am

yay! finally up to date (well, at least until the next puzzle is released at 5 a.m  ;D).

Title: Re: Advent of Code
Post by: Oaky on 15 December, 2015, 12:22:53 am

Quote from: David Martin on 14 December, 2015, 11:27:17 pm

Quote from: jo on 14 December, 2015, 11:14:57 pm

Finally found an answer to Day 12b (JSON parsing)

(click to show/hide)

Kludged the Processing JSON parser to work with the sample json file. Most parsers seem to be designed to work with a schema where you know what elements / objects / arrays to expect. Since this challenge involves navigating nested arrays and objects with a random structure and set of keys, I had to try for each type and do lots of exception catching when, for example, I tried to read an object when an array was found or integer when a String was found. Not very elegant, but it did find the solution in under a second.

(click to show/hide)

That is more or less what I did. The python stock json parser provides a list of objects. I wrote a recursive function that would test the type of the object it had been given. If it was an int it would return that value, if a list it would call itself on each element of the list, adding the values up and returning those, and likewise for an object - first check to see if it has a value of 'red' and return 0 if so, else iterate through the values and call the function on each one, adding the result.

(click to show/hide)

I also used the stock Python JSON parser with a recursive function for part (2).  (I sneaked part (1) using a regexp, but I wrote my json processor to handle part (1) as well).

Instead of testing for type, I tried type-specific operations in carefully chosen order and handled the exceptions (following the "better to ask for forgiveness than permission" principle):-

Code: [Select]

def summing_walk(jsondata, part, depth):
    #print '>'*depth
    total = 0
    # is it a dict (object)?
    try:
        keys = jsondata.keys()
        # process values here to look for red
        process_this_one = True
        if part == 2:
            for i in keys:
                if jsondata[i] == 'red':
                    process_this_one = False
        if process_this_one:
            for i in keys:
                total += summing_walk(jsondata[i], part, depth + 1)
    except AttributeError:
        # OK this wasn't a dict
        # is it a list?
        try:
            jsondata.append('MNO')
            jsondata.pop() # remove it again if we succeeded
            # process list
            for i in jsondata:
                total += summing_walk(i, part, depth + 1)
        except AttributeError:
            # not a list either - must be string (ignore)
            # or int (add to total)
            try:
                total += jsondata
            except TypeError:
                # it was a string
                pass
    return total



Title: Re: Advent of Code
Post by: red marley on 15 December, 2015, 02:36:29 am

Have just completed days 13 and 14, which seemed a bit easier than some of the earlier ones.

Day 13 (Table planning)

(click to show/hide)

Is pretty much the same as Day 9 (route planning), except it is a digraph (A->B not necessarily equal to B->A). Part B was a trivially simple addition of an extra row and column of zeros to the edge matrix.

Title: Re: Advent of Code
Post by: David Martin on 15 December, 2015, 01:16:08 pm

Quote from: jo on 15 December, 2015, 02:36:29 am

Have just completed days 13 and 14, which seemed a bit easier than some of the earlier ones.

Day 13 (Table planning)

(click to show/hide)

Is pretty much the same as Day 9 (route planning), except it is a digraph (A->B not necessarily equal to B->A). Part B was a trivially simple addition of an extra row and column of zeros to the edge matrix.

I had a search for a more elegant way than my brute force approach but couldn't find a suitable one. My matrix math is not up to it and your graph theory is probably far better than mine.

Title: Re: Advent of Code
Post by: David Martin on 15 December, 2015, 05:30:16 pm

Really not happy with my solution to day 15.

(click to show/hide)

It looked initially like a linear algebra puzzle which should be solvable with matrices, except that the score is a product of the terms with a floor function. So I was stuck on an elegant solution as my matrix fu only goes so far.
generated 10 million random matrices for the ingredient proportions, did matrix multiplication of the ingredients to get a score matrix which I could then apply the pmax function to row wise and then calculate the final cumulative product for each row. Then select the max of those. Repeat several times till I got a candidate best.
Sample the space around the best candidate to check it was a maximum. That gave a heuristic answer for part a which was correct.
Simple matrix multiplication to get the calories for each recipe, then select the max score where calories==500 (my target). That heuristic also worked.

Why don't I like it? Because it doesn't guarantee to give the right answer. I may just be lucky (but the more I try the luckier I get :) )

Title: Re: Advent of Code
Post by: red marley on 15 December, 2015, 05:57:44 pm

Day 15:

(click to show/hide)

I thought this would make a good linear programming problem initially, but opted for a procedural approach in the end. But surely you don't need so many random matrices? For 4 ingredients together summing to 100 units, there are only 156849 possible combinations. This can be found iteratively:

for (a=1 TO 100)
  for (b=1 TO 100-a)
    for (c=1 TO 100-a-b)

or recursively (which makes it easier to generalise to any number of ingredients and any total, permute(4,100) used for this challenge):

array spoons[numberOfIngredients]

permute(spoonsToFind, total)
  if (spoonsToFind==1)
    spoons[0] = total   // Set of proportions found.
    return
 
  for  (i=1 TO total-spoonsToFind)
      spoons[spoonsToFind-1] = i     
      permute(spoonsToFind-1, total-i)

Title: Re: Advent of Code
Post by: David Martin on 15 December, 2015, 06:06:48 pm

You are correct - I was doing it in a bit of a rush between invigilation and marking.. Only 300 more scripts to go before then end of term.

Title: Re: Advent of Code
Post by: Oaky on 15 December, 2015, 09:13:00 pm

(click to show/hide)

I took the same iterative approach as jo spelled out (except that I initially forgot the last parameter was completely constrained, and still searched the range all the way up to the value it finally had to have.  :facepalm:  This actually got the correct aswer for part 1.  I only noticed it when running part 2 - I got the wrong answer then noticed that my ingredients added up to less than 100 spoons. d'oh!

I wondered for a while how best to add the calorie constraint into it, but decided that just having my score function return 0 for cookies which didn't have 500 calories would be quickest.

It was only while reading jo's spoiler above that I realised that my permutation generator was set up specifically for 4 ingredients which sent me scurrying back to the code to try to work out how it still managed to get the correct answer for the example case with two ingredients.

Title: Re: Advent of Code
Post by: Pingu on 15 December, 2015, 09:39:50 pm

Day 9a done eventually followed by 9b two minutes later.

Title: Re: Advent of Code
Post by: David Martin on 15 December, 2015, 09:55:59 pm

Quote from: Oaky on 15 December, 2015, 09:13:00 pm

(click to show/hide)

I wondered for a while how best to add the calorie constraint into it, but decided that just having my score function return 0 for cookies which didn't have 500 calories would be quickest.

(click to show/hide)

I recognised a nice matrix based problem so set my ingredients up as a 5x4 matrix, then calculating the scores for each combination was a matrix multiplication of all permutations (as an n*4 matrix) with the ingredient parameters (except calories) to give an n*4 matrix of total parameter scores for each permutation. Applying a row wise function (set every value below 0 to 0, then multiply the row) gave me a n*1 matrix in which it is trivial to find the max value. Having this as a base I could then do the same multiplication as previously but calculate the calories by multiplying the permutation with the fifth column. Then filter the scores by calories==500 and take the max. That was actually a few seconds work to do the extension.

Title: Re: Advent of Code
Post by: Pingu on 15 December, 2015, 10:28:35 pm

Day 10 done. What a contrast with day 9.

Title: Re: Advent of Code
Post by: red marley on 16 December, 2015, 08:40:07 am

Day 16

(click to show/hide)

A fairly straightforward challenge this one - filtering a list based on a subset of attributes.

According to Eric Wastl (the Advent of Code author), today was the last of the "easy" ones.

Title: Re: Advent of Code
Post by: Oaky on 16 December, 2015, 10:41:53 am

Quote from: jo on 16 December, 2015, 08:40:07 am

Day 16

(click to show/hide)

A fairly straightforward challenge this one - filtering a list based on a subset of attributes.

According to Eric Wastl (the Advent of Code author), today was the last of the "easy" ones.

(click to show/hide)

I anticipated the change in the comparison while coding for part1, so had already written my Sue class's match method to accept a comparison function as a parameter.  I hadn't anticipated a type-dependent one though, so had to add an argument to pass in the type to the comparison function.

Of course,  I'd written it in such a way that I couldn't immediately decide whether my func shoudl use less or greater than in each of the two given cases!  Carefully tracing an example through the function (and through a few "not"s) decided it in the end.

Title: Re: Advent of Code
Post by: David Martin on 16 December, 2015, 09:33:34 pm

(click to show/hide)

I parsed it as I read it in with a set of rejection criteria. If it passed those it got added to my list of possible sues.
This should end up with just one entry (which it did).

Today was very easy. I dread tomorrow.

Title: Re: Advent of Code
Post by: red marley on 16 December, 2015, 10:05:37 pm

David, that's a more elegant approach than mine. My instinct tends towards 'grab all the data and structure it, then start processing'. I think this comes from my usual need to visualise data. But it makes much more sense in this context to follow your approach.

As with almost all of the puzzles so far, in practice the data volumes involved mean that inefficient storage or processing hungry algorithms can be tolerated. I suspect this will change from the 17th onwards.

I am trying to resist the temptation to come up with a speedy answer early in the morning to get posted on the leader board (mostly because I am not speedy enough). But I do wonder whether anyone is going to be spending an antisocial Christmas morning coding in order to make it to the head of the final leader board (I certainly won't be).

Title: Re: Advent of Code
Post by: David Martin on 16 December, 2015, 10:10:19 pm

Only if you can get up early enough :)

Your line of work is based around visualising all the data - a lot of mine is stream parsing and quality filtering. I took the view that filtering out what I didn't want and seeing what was left would be the easier option.

Anyhow, tomorrow will be a toss up between marking stats reports, planning next semester's course (don't ask why it is so late) and doing the Advent of Code.

Being less than elegant I hard-coded the parse rules.

(click to show/hide)

Code: [Select]

ifh=open('input.txt')
mysue={
'children': 3,
'cats': 7,
'samoyeds': 2,
'pomeranians': 3,
'akitas': 0,
'vizslas': 0,
'goldfish': 5,
'trees': 3,
'cars': 2,
'perfumes': 1
}

sues=[]
for line in ifh.readlines():
    try:
        f=line.strip().split()
        thissue={f[2][:-1]:int(f[3][:-1]),f[4][:-1]:int(f[5][:-1]),f[6][:-1]:int(f[7])}
        wrongsue=True
        for k in thissue.keys():
            if k=='cats' or k=='trees':
                if mysue[k]>=thissue[k]:
                    wrongsue=False
            elif k in ('pomeranians', 'goldfish'):
                if mysue[k]<=thissue[k]:
                    wrongsue=False
            else:   
                if mysue[k]!=thissue[k]:
                    wrongsue=False
        thissue[f[0]]=int(f[1][:-1])
        if wrongsue:
            sues.append(thissue)
    except:
        print(line)       

The check the value of sues at the end.

Title: Re: Advent of Code
Post by: David Martin on 17 December, 2015, 08:07:35 am

Day 17 required some thought but very few lines of code.

(click to show/hide)

It is a simple branch and bound algorithm so you don't enumerate every possibility, only those that have the potential to have a correct solution.

Title: Re: Advent of Code
Post by: Oaky on 17 December, 2015, 09:56:39 am

Quote from: David Martin on 17 December, 2015, 08:07:35 am

Day 17 required some thought but very few lines of code.

(click to show/hide)

It is a simple branch and bound algorithm so you don't enumerate every possibility, only those that have the potential to have a correct solution.

(click to show/hide)

A quick back of the envelope calc told me that brute force and ignorance would probably be fine, so I simply counted up from 1, turning that into a bitmask of the same length as the list.  I applied the mask to the list of inputs, throwing away any combinations that didn't sum to the total.

Title: Re: Advent of Code
Post by: David Martin on 17 December, 2015, 11:20:14 am

That was one option. I just happen to like recursion. It took a few seconds to ru, if that. (longer to write than to run).

Title: Re: Advent of Code
Post by: Feanor on 17 December, 2015, 11:32:34 am

Elegant as it is, you need to be careful with recursion because every time you re-enter a subroutine, the previous context is pushed onto the stack.

The stack will build and build as you recurse down, and only when (if!) you reach the bottom of the rabbit-hole and start returning do you begin to pop stuff off the stack.

So unless you know there's a limit on how deeply you will be recursing, you run a risk of stack overflow.
It's a fairly small risk with modern OSes, as the stack allocation is usually quite generous, but it is a limit to be aware of.

Title: Re: Advent of Code
Post by: David Martin on 17 December, 2015, 11:49:56 am

In this case the recursion limit is the tree depth which is the length of the list. So not a problem. If it was an optimisation I'd have some convergence criteria.

Title: Re: Advent of Code
Post by: David Martin on 18 December, 2015, 07:49:13 am

Day 18, those blinking lights again.
I didn't use recursion. Fortunately my approach meant that part B required minimal extra coding

(click to show/hide)

It runs very much easier if you add a border of always off lights around the edge to give an [n+2,m+2] grid, then there is no need to worry about boundary conditions. Just iterate over [2,2] to [n+1,m+1].
The minor change is to hard code the change in the resulting grid for the broken lights. Any sensible solution would be scalable to a different sized grid. I was expecting it to be harder, with the time of a bulb staying on being more than an individual iteration.

Title: Re: Advent of Code
Post by: Oaky on 18 December, 2015, 10:29:12 am

Quote from: David Martin on 18 December, 2015, 07:49:13 am

Day 18, those blinking lights again.
I didn't use recursion. Fortunately my approach meant that part B required minimal extra coding

(click to show/hide)

It runs very much easier if you add a border of always off lights around the edge to give an [n+2,m+2] grid, then there is no need to worry about boundary conditions. Just iterate over [2,2] to [n+1,m+1].
The minor change is to hard code the change in the resulting grid for the broken lights. Any sensible solution would be scalable to a different sized grid. I was expecting it to be harder, with the time of a bulb staying on being more than an individual iteration.

(click to show/hide)

I initially planned to add the always off border, but decided in the end not to, and instead to avoid having to bounds check by just trying to reference outside the bounds and catching IndexError.  This, failed because Python is perfectly happy with an index of [-1] in a list or string  so I had to add a bounds check for the index < 0 case.  :facepalm:  :-[

I decided to do part 2 by subclassing my part 1 answer, so the additional code was just:

Code: [Select]

class LightArray2(LightArray):
    def __init__(self, str):
        LightArray.__init__(self, str)
        self.lightCorners()

    def lightCorners(self):
        self.elements[0]= '#'+self.elements[0][1:-1]+'#'
        self.elements[-1]= '#'+self.elements[-1][1:-1]+'#'

    def evolve(self, steps):
        for i in range(steps):
            LightArray.evolve(self, 1)
            self.lightCorners()
        return self

Which of course makes use of the [-1] index behaviour  that I fell foul of earlier.

Title: Re: Advent of Code
Post by: David Martin on 18 December, 2015, 10:12:41 pm

As Mr Wall says: TMTOWTDI
It was pleasantly easy. I was expecting something like 'if the bulb has been on for 10 iterations continuously it burns out and is permanently off'

Title: Re: Advent of Code
Post by: Oaky on 19 December, 2015, 12:28:33 am

Indeed,  the part 2 variation was less taxing than I expected.

I was doing a bit of self-searching about which days i found hardest so far, and from memory the hardest two were

1. day 8 (the string storage thing)

(click to show/hide)

I got a bit of a headache trying to construct the code to test for some of the substrings for escape characters, when I had to escape the strings in the code.  Particularly the difficulty in specifying a string literal in Python win an odd number of "\" chars at the end.

2. day 7 (the circuit thing)

(click to show/hide)

.mainly because I'd never really thought about recursing through a structure like that before.

In terms of raw amounts of code (stripping comments), they rank as follows:-

Code: [Select]

oaky@jarlsberg ~/Dropbox/AdventOfCode $ for i in */s*.py; do echo `grep -v '^[ ]*#' $i |  wc -l` $i;done | sort -n
22 1/s1.py
26 2/s2.py
32 4/s4.py
48 17/s17.py
51 8/s8b.py
55 10/s10.py
58 12/s12.py
62 8/s8.py
71 14/s14.py
77 16/s16.py
82 3/s3.py
91 15/s15.py
95 13/s13.py
99 9/s9.py
100 6/s6.py
104 11/s11.py
137 5/s5.py
150 18/s18.py
173 7/s7.py

although it's skewed somewhat since after the first couple of days I started using a unit test framework for varying levels of testing within the script itself (some of the lmid to ater ones were more than 50% test code).

Title: Re: Advent of Code
Post by: Oaky on 19 December, 2015, 12:31:45 am

from twitter earlier:-

Quote

Eric Wastl ‏@ericwastl 3h3 hours ago

If #AdventOfCode were a roller coaster, we're about to reach the corkscrews and loops and the part where it takes your picture.

Title: Re: Advent of Code
Post by: red marley on 19 December, 2015, 06:12:14 am

Today's is right up David Martin's street.

Part two feels like a proper workout for me at least. I'm impressed that the highest entry on the leaderboard managed both parts within 18 minutes of the puzzle being released.

Title: Re: Advent of Code
Post by: David Martin on 19 December, 2015, 09:51:49 am

I've just done part one which was easy. I'm thinking about part 2.

(click to show/hide)

It looks like you build the graph of all possible routes then seek the shortest path from e to alphabet soup. However there will only be one e => something transition in there, so you are looking for end points that match.
I have to invert my data structure for part 1 and then start at the end. I'll recurse through keeping track of the number of steps to get to a point in an e=> transition and note the smallest. At each step in the recursion I will stop if I get to a compound I have previously made and will add on it's fewest steps to the end. It is straightforward but may take a few mins to run.

Title: Re: Advent of Code
Post by: Pingu on 19 December, 2015, 12:04:45 pm

Took a couple of days off. Just finished day 11. The concept wasn't difficult, but it took me a while to sort out the letter incrementing business.

Title: Re: Advent of Code
Post by: David Martin on 19 December, 2015, 04:18:13 pm

Well that doesn't work for day 19 as the time/space required is too big. This requires more thought.

Title: Re: Advent of Code
Post by: Pingu on 19 December, 2015, 07:20:57 pm

Quote from: David Martin on 14 December, 2015, 11:27:17 pm

Quote from: jo on 14 December, 2015, 11:14:57 pm

Finally found an answer to Day 12b (JSON parsing)

(click to show/hide)

Kludged the Processing JSON parser to work with the sample json file. Most parsers seem to be designed to work with a schema where you know what elements / objects / arrays to expect. Since this challenge involves navigating nested arrays and objects with a random structure and set of keys, I had to try for each type and do lots of exception catching when, for example, I tried to read an object when an array was found or integer when a String was found. Not very elegant, but it did find the solution in under a second.

(click to show/hide)

That is more or less what I did. The python stock json parser provides a list of objects. I wrote a recursive function that would test the type of the object it had been given. If it was an int it would return that value, if a list it would call itself on each element of the list, adding the values up and returning those, and likewise for an object - first check to see if it has a value of 'red' and return 0 if so, else iterate through the values and call the function on each one, adding the result.

I'm on 12b now. It's a bit of a bastard. I've not opened the spoilers (yet).

Title: Re: Advent of Code
Post by: David Martin on 19 December, 2015, 09:19:20 pm

I had a look at a spoiler for 19

(click to show/hide)

The pattern is not random. Look at what can only appear but never be changed..

Title: Re: Advent of Code
Post by: Oaky on 20 December, 2015, 01:30:06 am

19b is eluding me for now, although I'm sure my BFI (brute force and ignorance) approach isn't the best.

I'm going to leave the BFI job running overnight, since it's not apparently consuming exponential memory, but in the morning, I am going to try a different approach:

(click to show/hide)

I'm going to run rules backwards from the target instead of forwards from e

It may not help, but it beats abusing the company AWS account to do an expensive massively parallel brute force search ;)

Title: Re: Advent of Code
Post by: David Martin on 20 December, 2015, 11:10:47 am

I think your revised approach is by far the most sensible (which is why I started with that. Still haven't managed a suitable solution though I think I know how to find one.

(click to show/hide)

There are two classes of process, and you can replace some elements with appropriate delimiters. Count the number of each element and look at how they can be converted.

Title: Re: Advent of Code
Post by: red marley on 20 December, 2015, 05:30:21 pm

Still working on an efficient way of reducing the search space for day 19b.

Day 20 is much easier...

(click to show/hide)

especially when you realise this is just about finding the factors of each house number and the factors of n can be found by testing just 2 to sqrt(n) inclusive.

Title: Re: Advent of Code
Post by: David Martin on 20 December, 2015, 08:38:03 pm

I haven't had a chance to look at 20 as my laptop has decided to overheat and kill the graphics every hour or so.

(click to show/hide)

Sussed the sum of factors thing but haven't done anything with it.

Title: Re: Advent of Code
Post by: Afasoas on 21 December, 2015, 09:23:39 am

I took a look at day 7 yesterday and found myself in a perpetual state of confusion.

I might try and take another look at it tonight.

Title: Re: Advent of Code
Post by: red marley on 21 December, 2015, 11:43:03 am

I now have a solution for 19b, Kicking myself I didn't get it earlier.

(click to show/hide)

If you get the algorithm right (and it's really quite simple), the answer can be found in milliseconds. The number of substitutions required is remarkably small (and I suspect for everyone's particular pattern).

Title: Re: Advent of Code
Post by: Afasoas on 21 December, 2015, 05:31:47 pm

For 7b, I found someone elses explanation of the problem and now I think I understand it.
I've also found out where the bitwise operators are in PowerShell*.


*I'm learning C and Ruby, I've a smattering of experience with Python, PHP and C#. But I'm nowhere near as proficient in those as I am with PowerShell. I figure if I find time to complete all the chellanges in PowerShell, I can try porting my solutions to other languages.

Title: Re: Advent of Code
Post by: David Martin on 21 December, 2015, 05:49:16 pm

Laptop was taken to laptop hospital and I really must finish my coursework marking before getting on with AoC.

Title: Re: Advent of Code
Post by: Afasoas on 21 December, 2015, 09:13:49 pm

Still stuck on day 7. I think my logic is sound.
I'm either hitting PowerShells limitations or I'm using it wrong.

Code: [Select]

[uint16]$foo = 1
[Uint16]$bar = $foo -shl 2
[Uint16]$car = $foo -shl 15
[Uint16]$har = $foo -shl 16
write-host "foo: $foo"
write-host "bar: $bar"
write-host "car: $car"
write-host "har: $har"
Output:

Code: [Select]

foo: 1
bar: 4
car: 32768
har: 0

On Edit: I'm being dufus. "shl" and "shr" are working as expected. ... **goes back, stares at code**

Title: Re: Advent of Code
Post by: Pingu on 22 December, 2015, 09:29:28 pm

Quote from: Pingu on 19 December, 2015, 07:20:57 pm

Quote from: David Martin on 14 December, 2015, 11:27:17 pm

Quote from: jo on 14 December, 2015, 11:14:57 pm

Finally found an answer to Day 12b (JSON parsing)

(click to show/hide)

Kludged the Processing JSON parser to work with the sample json file. Most parsers seem to be designed to work with a schema where you know what elements / objects / arrays to expect. Since this challenge involves navigating nested arrays and objects with a random structure and set of keys, I had to try for each type and do lots of exception catching when, for example, I tried to read an object when an array was found or integer when a String was found. Not very elegant, but it did find the solution in under a second.

(click to show/hide)

That is more or less what I did. The python stock json parser provides a list of objects. I wrote a recursive function that would test the type of the object it had been given. If it was an int it would return that value, if a list it would call itself on each element of the list, adding the values up and returning those, and likewise for an object - first check to see if it has a value of 'red' and return 0 if so, else iterate through the values and call the function on each one, adding the result.

I'm on 12b now. It's a bit of a bastard. I've not opened the spoilers (yet).

12b done at last (without spoilers)!  :thumbsup:

Title: Re: Advent of Code
Post by: Pingu on 23 December, 2015, 11:35:32 pm

Day 13 completed via a mix of Javascript and spreadsheet. Very much like day 9.

Title: Re: Advent of Code
Post by: Pickled Onion on 24 December, 2015, 06:30:48 pm

Yikes, made a bit of meal out of day 9, but quite happy with what I ended up with.

Title: Re: Advent of Code
Post by: Pickled Onion on 24 December, 2015, 07:47:17 pm

Quite pleased with this for day 10

(click to show/hide)

Code: [Select]

$input =~ s/((.)\2*)/length($1) . $2/gexms for 1..40;

Title: Re: Advent of Code
Post by: Diver300 on 25 December, 2015, 06:34:52 am

In 12b, does "red" after an object mean that the object is ignored?

e.g. { 1, 2, {3, 4} , red }

Should that be 7 or 0?

Title: Re: Advent of Code
Post by: Oaky on 25 December, 2015, 10:53:40 am

Quote from: Diver300 on 25 December, 2015, 06:34:52 am

...

ETA: the spoiler below doesn't contain any info about the solution to the question, but does reveal something about part (b) of the question.

(click to show/hide)

What you have above isn't an object.  Objects are lists of key: value pairs  (with a colon separating the key and value) in curlies {}.  The instruction in part (b) is to ignore an object if any of its values are "red" so e.g.this:

{"one": 1, "two": "red", "foo": [1,2,3,4]}

would be ignored because the value corresponding to the key "two" is "red"

Title: Re: Advent of Code
Post by: Pingu on 25 December, 2015, 11:36:21 pm

Day 14 done.

Title: Re: Advent of Code
Post by: Pingu on 25 December, 2015, 11:43:06 pm

Quote from: Oaky on 25 December, 2015, 10:53:40 am

Quote from: Diver300 on 25 December, 2015, 06:34:52 am

...

ETA: the spoiler below doesn't contain any info about the solution to the question, but does reveal something about part (b) of the question.

(click to show/hide)

What you have above isn't an object.  Objects are lists of key: value pairs  (with a colon separating the key and value) in curlies {}.  The instruction in part (b) is to ignore an object if any of its values are "red" so e.g.this:

{"one": 1, "two": "red", "foo": [1,2,3,4]}

would be ignored because the value corresponding to the key "two" is "red"

(click to show/hide)

As Oaky says { 1, 2, {3, 4} , red } would look more like { "a":"1", "b":"2", "c":{"d":"3", "e":"4"} ,"f": "red" } in the puzzle and would have a value of 0.

Title: Re: Advent of Code
Post by: Diver300 on 26 December, 2015, 06:45:05 am

Quote from: Pingu on 25 December, 2015, 11:43:06 pm

Quote from: Oaky on 25 December, 2015, 10:53:40 am

Quote from: Diver300 on 25 December, 2015, 06:34:52 am

...

ETA: the spoiler below doesn't contain any info about the solution to the question, but does reveal something about part (b) of the question.

(click to show/hide)

What you have above isn't an object.  Objects are lists of key: value pairs  (with a colon separating the key and value) in curlies {}.  The instruction in part (b) is to ignore an object if any of its values are "red" so e.g.this:

{"one": 1, "two": "red", "foo": [1,2,3,4]}

would be ignored because the value corresponding to the key "two" is "red"

(click to show/hide)

As Oaky says { 1, 2, {3, 4} , red } would look more like { "a":"1", "b":"2", "c":{"d":"3", "e":"4"} ,"f": "red" } in the puzzle and would have a value of 0.

(click to show/hide)

I had abbreviated the example as only the numbers are needed for the solution.
I found that my code was inadvertently ignoring instances of "red" that came after arrays.

Title: Re: Advent of Code
Post by: Pingu on 26 December, 2015, 03:00:19 pm

Quote from: Diver300 on 26 December, 2015, 06:45:05 am

Quote from: Pingu on 25 December, 2015, 11:43:06 pm

Quote from: Oaky on 25 December, 2015, 10:53:40 am

Quote from: Diver300 on 25 December, 2015, 06:34:52 am

...

ETA: the spoiler below doesn't contain any info about the solution to the question, but does reveal something about part (b) of the question.

(click to show/hide)

What you have above isn't an object.  Objects are lists of key: value pairs  (with a colon separating the key and value) in curlies {}.  The instruction in part (b) is to ignore an object if any of its values are "red" so e.g.this:

{"one": 1, "two": "red", "foo": [1,2,3,4]}

would be ignored because the value corresponding to the key "two" is "red"

(click to show/hide)

As Oaky says { 1, 2, {3, 4} , red } would look more like { "a":"1", "b":"2", "c":{"d":"3", "e":"4"} ,"f": "red" } in the puzzle and would have a value of 0.

(click to show/hide)

I had abbreviated the example as only the numbers are needed for the solution.
I found that my code was inadvertently ignoring instances of "red" that came after arrays.

 :thumbsup:

Title: Re: Advent of Code
Post by: Pingu on 26 December, 2015, 03:26:46 pm

Day 15 done. Not too difficult compared with some of the previous.

Title: Re: Advent of Code
Post by: Pingu on 26 December, 2015, 05:39:22 pm

Day 16 done entirely by the dreaded spreadsheet.

Title: Re: Advent of Code
Post by: Pingu on 27 December, 2015, 12:38:51 am

Day 17 done with judicious googling*  :-X

(click to show/hide)

http://stackoverflow.com/questions/5752002/find-all-possible-subset-combos-in-an-array

Title: Re: Advent of Code
Post by: red marley on 27 December, 2015, 04:00:08 pm

Day 21 was one of the easier ones. But I did enjoy Day 22 because

(click to show/hide)

while it superficially looks like a minor variation of Day 21, it requires quite a different solution. This felt like one that was well suited to an object-oriented approach which is my preferred way to conceptualise problems.

Title: Re: Advent of Code
Post by: red marley on 27 December, 2015, 04:08:44 pm

Day 23. Another relatively easy one to compute but with a gotcha in part 2.

(click to show/hide)

While any compiler could be modelled with a Turing machine, I was hoping this one might have involved being able to change the instructions directly, not just via the contents of two registers.

Part b looked at first like it would be trivially simple to adapt with a different initialisation of register a. But this led to the wrong answer which for a while I couldn't explain. When I traced the contents of the two registers, the repeated tpl commands produced an uncaught overflow when storing the values as floats. Changing the registers to 64 bit integers solved the problem.

Title: Re: Advent of Code
Post by: red marley on 27 December, 2015, 04:18:09 pm

Day 24. Interesting.

(click to show/hide)

This was the only one where I went for a brute force approach that took a few minutes to compute. That suggests to me there is a more efficient way of finding the answer. It's a subset sum problem (https://en.wikipedia.org/wiki/Subset_sum_problem) which can be reliably approximated in polynomial time, although I was only able to detect whether it was solvable in polynomial time rather than provide the actual set of present weights and their QE. The full solution was exponential for me, taking about 3 minutes to compute.

I wonder if the fact that all the present weights are primes (and with a 1)would allow a more efficient solution to  be found than the more general case of any positive integers.

Title: Re: Advent of Code
Post by: red marley on 27 December, 2015, 04:24:43 pm

Day 25. A nice finish to the challenge.

(click to show/hide)

I'm used to converting between a row-prime 2d grid and a 2d list using integer division and modulus, but haven't done this for a diagonally ordered one. The advantage of the diagonal ordering is that it does not require knowledge of the number of grid columns to compute (and hence works with an infinite grid). The disadvantage is that (as far as I am aware) requires an iterative solution to do the conversion. This took me surprising long to work out despite the conversion being pretty simple (triangular numbers with a row-based offset).

Title: Re: Advent of Code
Post by: Pickled Onion on 28 December, 2015, 01:11:06 pm

Day 19 - part 2.

(click to show/hide)

Working backwards was clearly the only sensible thing. Still managed to

Code: [Select]

Deep recursion on subroutine "main::recurse" at ./day19b.pl line 42, <DATA> line 45.
Ooopps  :-[

Still managed to converge on the solution pretty quickly  :thumbsup:

Title: Re: Advent of Code
Post by: Pingu on 30 December, 2015, 12:31:01 pm

Day 18 done. Plodding on  :thumbsup:

Title: Re: Advent of Code
Post by: Pickled Onion on 02 January, 2016, 10:34:22 am

Day 22. What a wind-up. This is the only one where the examples don't give an expected result, just an example of the steps. So all my tests passed but the answer was wrong.

(click to show/hide)

Forgot to code for: "However, effects can be started on the same turn they end."  :facepalm:

Title: Re: Advent of Code
Post by: Pickled Onion on 02 January, 2016, 10:45:21 am

Quote from: jo on 27 December, 2015, 04:24:43 pm

Day 25. A nice finish to the challenge.

Thanks for posting this Afasoas, it was fun.

Slight quibble - advent calendars normally have 24 windows, don't they?

Now off to solve waste more time with http://www.gchq.gov.uk/press_and_media/news_and_features/Pages/Directors-Christmas-puzzle-2015.aspx

Title: Re: Advent of Code
Post by: Oaky on 05 January, 2016, 09:16:30 am

Quote from: Pickled Onion on 02 January, 2016, 10:34:22 am

Day 22. What a wind-up. This is the only one where the examples don't give an expected result, just an example of the steps. So all my tests passed but the answer was wrong.

(click to show/hide)

Forgot to code for: "However, effects can be started on the same turn they end."  :facepalm:

(click to show/hide)

I had a similar problem .. all my tests passed, but I got the wrong answer...

I hadn't missed the "effects can be started on the same turn they end" thing though - mine was a genuine bug, only found by poring over reams of debug output.

I had coded it as a walk down the tree of possibilities at each turn, but had made special provision to handle the effects of the immediate spells on the players turn, rather than at the start of the next boss turn with all of the others... the way I'd coded it meant that the hit points were not reset after the first of the immediate spells (magic missile) was tested fro, so the second immediate spell, Drain, (and subsequent spells) had the magic missile effects included on top of the Drain effects (i.e. two seplls in one turn).

Easily fixed by handline the immediate spells in exactly the same way that I handled the non-immediate ones (as I'd initially planned to do, but for some reason thought wouldn't work correctly).

Title: Re: Advent of Code
Post by: red marley on 05 January, 2016, 09:31:11 am

I think one of the consequences of the kind of problem you mention for Day 22 and many of the others in the challenge is how useful test driven development can be. I like the way the examples provide a gentle introduction to testing without ever mentioning unit tests and the like. I am considering how to incorporate these coding challenges into some of our undergraduate introductory programming teaching.

If anyone is feeling withdrawal symptoms with no more AoC, I recommend attempting the Synacor Challenge (https://challenge.synacor.com) also from Eric Wastl. It is immensely satisfying, very cleverly designed and rather challenging. But like the AoC, it leads you in gently so caters for a wide range of abilities. I'd also recommend not Googling for it as spoilers abound and one of the most satisfying elements of participating comes from what is revealed and the sense of achievement as you progress through the challenge.

Title: Re: Advent of Code
Post by: David Martin on 05 January, 2016, 10:01:22 am

I have to get back into it - haven't done any since the Mac died and Christmas took over.

Title: Re: Advent of Code
Post by: Oaky on 05 January, 2016, 10:17:03 am

(click to show/hide)

I completed day24, but wasn't happy with the performance of m solution so I went looking around for other folks' answers.

It turns out that many of the people who'd solved it made assumptions that are not in the problem description but happened to be true for their (and my!) input data e.g.

1. assumption that all of the weights are unique (not mentioned in the problem, but true for my input data and all of the ones I've seen).  I thought about using this fact to simplify my approach (coding using Python sets instead of lists), but decided against since there was no guarantee in the problem description that it would be the case, and I wanted to make a program that would work for any input, not just mine.

2. once you'd found a list of weights for the footwell bag, that the remaining presents would always be partitionable into the remaining bags with equal weight.  It's not at all clear to me that it would be true that for any choice of presents in bag0 (the footwell bag), the remaining presents are always evenly distributable between the remaining bags.  Perhaps there's a way to prove this (but you probably need to make assumptions about the weights that aren't spelled out in the problem description)

Assumption 2 in particular, makes a huge difference to the time to find the solutions.  My script which does test to make sure the remaining presents will partition evenly takes half an hour to find minimal solutions for parts 1 and 2 (most of this time is spent in part 1).  If I disable the checking of the partitions for the remaining bags, the same script only takes just over 1 second to find the same solutions.  (I'm still annoyed that I haven't been able to optimise my full script any more.  I suspect I'm missing a trick somewhere - perhaps using the same binary element mask trick I used for Day17 would be quicker than the list manipulations I settled on, or perhaps using the itertools combination generator rather than rolling my own.)

Title: Re: Advent of Code
Post by: red marley on 05 January, 2016, 11:26:41 am

Quote from: Oaky on 05 January, 2016, 10:17:03 am

(click to show/hide)

I completed day24, but wasn't happy with the performance of m solution so I went looking around for other folks' answers.

It turns out that many of the people who'd solved it made assumptions that are not in the problem description but happened to be true for their (and my!) input data e.g.

1. assumption that all of the weights are unique (not mentioned in the problem, but true for my input data and all of the ones I've seen).  I thought about using this fact to simplify my approach (coding using Python sets instead of lists), but decided against since there was no guarantee in the problem description that it would be the case, and I wanted to make a program that would work for any input, not just mine.

2. once you'd found a list of weights for the footwell bag, that the remaining presents would always be partitionable into the remaining bags with equal weight.  It's not at all clear to me that it would be true that for any choice of presents in bag0 (the footwell bag), the remaining presents are always evenly distributable between the remaining bags.  Perhaps there's a way to prove this (but you probably need to make assumptions about the weights that aren't spelled out in the problem description)

Assumption 2 in particular, makes a huge difference to the time to find the solutions.  My script which does test to make sure the remaining presents will partition evenly takes half an hour to find minimal solutions for parts 1 and 2 (most of this time is spent in part 1).  If I disable the checking of the partitions for the remaining bags, the same script only takes just over 1 second to find the same solutions.  (I'm still annoyed that I haven't been able to optimise my full script any more.  I suspect I'm missing a trick somewhere - perhaps using the same binary element mask trick I used for Day17 would be quicker than the list manipulations I settled on, or perhaps using the itertools combination generator rather than rolling my own.)

(click to show/hide)

For your point (1), one could incorporate into your algorithm a test to see if the numbers are unique and adapt your algorithm accordingly. I think that not only will they always be unique, but they seem to be a set of prime numbers plus 1 which I think has a bearing on possible approaches.

No need to make assumption 2, although I think it is in fact true. Testing that the remaining compartments once you've allocated the footwell need only progress to numCompartments-1. i.e. there is no need to test for the last compartment since if you've divided your weight totals by 3 and have allocated 2 of the 3 successfully, the final one must, by definition contain an equal weight. You can speed things up further in the testing compartment 2 because you don't have to find the actual set(s) of weights, but simply determine if there is at least one such set. An algorithm for that can be done in polynomial time rather than exponential with an appropriate approximation coefficient c: https://en.wikipedia.org/wiki/Subset_sum_problem#Polynomial_time_approximate_algorithm

I am no expert in number theory, but I suspect the fact that the weights are primes and one means you can take advantage of some kind of prime partition property that may prove that assumption 2 is in fact correct, but this is only a suspicion.

Title: Re: Advent of Code
Post by: Oaky on 11 January, 2016, 09:21:57 am

Quote from: jo on 05 January, 2016, 09:31:11 am

If anyone is feeling withdrawal symptoms with no more AoC, I recommend attempting the Synacor Challenge (https://challenge.synacor.com) also from Eric Wastl.

That thing is addictive.  I've got the first four codes now.

(click to show/hide)

The first three came very quickly, then it turned out that I had a bug in my VM's mod operator when operating on registers.  The bug hadn't shown up during the self test, and caused the subroutine @2001 (output a number in decimal notation) to be, as far as I could tell, non-terminating.  :facepalm: :-[

I only found that after (as I guess everyone doing the challenge does) writing a debugger and disassembler into the VM.

It's ages since I spent the wee small hours poring over disassembler output and single stepping through machine instructions without quite realising the time.

Title: Re: Advent of Code
Post by: Oaky on 01 February, 2016, 04:06:22 pm

Some additional stats from Advent of Code have been published:  http://hexatlas.com/entries/8

I like this quote: "I expected 70 users or so, maybe. By Day 2, almost 10,000 were signed up, which caused quite a bit of panic on the server capacity end of things."

Title: Re: Advent of Code
Post by: Oaky on 22 November, 2016, 12:23:01 pm

Advent of Code 2016 is imminent!  :thumbsup:

Looks like jo's private leaderboard from last year carries over to 2016 too.

Title: Re: Advent of Code
Post by: David Martin on 22 November, 2016, 01:22:59 pm

Oooh.. must do better this year.

Title: Re: Advent of Code
Post by: red marley on 22 November, 2016, 02:52:49 pm

Quote from: Oaky on 22 November, 2016, 12:23:01 pm

Advent of Code 2016 is imminent!  :thumbsup:

Looks like jo's private leaderboard from last year carries over to 2016 too.

In case it is not obvious to anyone new to the Advent of Code, the 'private leaderboard' allows you to view the number of completed challenge questions from YACF people who register. To join the board, simply enter the code 48462-ea506236 under 'leaderboard -> join private leaderboard'.

To enter the challenge at all you will need to log in to the site with one of the following credentials: twitter, Google, GitHub or Reddit. This is necessary as they are used to generate a (possibly) unique set of question variations and validation of your answers. No spamming is involved (as far as I am aware).

I'd really recommend the challenge to anyone with even a passing interest in coding. So far the challenges have been very well designed providing a manageable and satisfying learning curve over the 25 days. Whether you are a beginner wanting to develop skills in a new language (I'm going to attempt some in Elm (http://elm-lang.org) and possibly Racket (http://beautifulracket.com) this year) or are an expert programmer with a familiar language, there is something on offer.

Title: Re: Advent of Code
Post by: Oaky on 25 November, 2016, 11:57:08 am

from the Advent of Code author on Twitter:-

https://twitter.com/ericwastl/status/801715851510616064

 ;D

Title: Re: Advent of Code
Post by: red marley on 01 December, 2016, 11:56:51 am

I need to apologise as I have inadvertently given out the code for the YACF private leaderboard to colleagues at work (I thought I had generated a new code from a different account, but had passed the wrong one to colleagues). The upshot is that there may be a few others joining the YACF leaderboard this month. If that is a problem for anyone, now would be the time to start a new YACF one.

Title: Re: Advent of Code
Post by: David Martin on 01 December, 2016, 12:47:04 pm

I haven't done it yet but this is the approach I will take..

(click to show/hide)

Start at 0,0. Your direction is set by a number between 0 and 3 which indexes an array of 2d vectors. Turning left increments the number, turning right decrements. The vectors are (1,0), (0,1), (-1, 0), (0,-1)
For each step:
increment/decrement the index as appropriate and adjust to be in range.
Multiply the indexed vector by the number of steps and add to the current position.

Final result - sum the coordinates in the position vector.

Title: Re: Advent of Code
Post by: David Martin on 01 December, 2016, 01:03:54 pm

And then there is part 2

(click to show/hide)

Instead of adding the sum total of steps, increment one at a time and add the coordinates to a hash, checking to see if that position has already been seen.

Title: Re: Advent of Code
Post by: Diver300 on 01 December, 2016, 03:18:20 pm

Both parts of day 1

(click to show/hide)

That was solved as David said, and done in Excel.

An X-Y plot of the result showed the answer to the second part very quickly

Title: Re: Advent of Code
Post by: red marley on 01 December, 2016, 05:55:03 pm

Day 1: I did pretty much the same as David Martin. Quite similar to one of the problems last year.

Diver300 - Initially I though your quick solution to part b was rather elegant but...

(click to show/hide)

It does not guarantee you the correct answer for many configurations with multiple crossing points. e.g. a 'B' shape trajectory could have the first intersection at several points all producing the same trail.

Title: Re: Advent of Code
Post by: Diver300 on 01 December, 2016, 08:48:22 pm

Quote from: jo on 01 December, 2016, 05:55:03 pm

Day 1: I did pretty much the same as David Martin. Quite similar to one of the problems last year.

Diver300 - Initially I though your quick solution to part b was rather elegant but...

(click to show/hide)

It does not guarantee you the correct answer for many configurations with multiple crossing points. e.g. a 'B' shape trajectory could have the first intersection at several points all producing the same trail.

(click to show/hide)

I don't think so.
The trajectory starts at 0,0 but doesn't end there. Just follow the line from 0,0 until it crosses itself for the first time.
The only problem with my data set was that most steps were single digit numbers of blocks, but some were in the hundreds. The crossing of the long steps were easy to see, but when the chart is scaled out to see the whole route, the short steps were a complete jumble. However, it didn't take long to zoom in and I found that the short steps didn't cross.

Title: Re: Advent of Code
Post by: David Martin on 01 December, 2016, 08:51:54 pm

Quote from: Diver300 on 01 December, 2016, 08:48:22 pm

Quote from: jo on 01 December, 2016, 05:55:03 pm

Day 1: I did pretty much the same as David Martin. Quite similar to one of the problems last year.

Diver300 - Initially I though your quick solution to part b was rather elegant but...

(click to show/hide)

It does not guarantee you the correct answer for many configurations with multiple crossing points. e.g. a 'B' shape trajectory could have the first intersection at several points all producing the same trail.

(click to show/hide)

I don't think so.
The trajectory starts at 0,0 but doesn't end there. Just follow the line from 0,0 until it crosses itself for the first time.
The only problem with my data set was that most steps were single digit numbers of blocks, but some were in the hundreds. The crossing of the long steps were easy to see, but when the chart is scaled out to see the whole route, the short steps were a complete jumble. However, it didn't take long to zoom in and I found that the short steps didn't cross.

(click to show/hide)

You were fortunate you didn't come back through the origin or cross a second time closer to the origin. It is a heuristic but not exact method.

Title: Re: Advent of Code
Post by: tom_e on 01 December, 2016, 09:08:36 pm

Well, that was a bit disappointing.  I'd recommended this to mrs_e on the basis it started off really gently in last year's problems and only gradually picked up in intensity.  This was straight in with an equivalent of day 3 (2015) but with an extra level of complexity due to rotations.

Title: Re: Advent of Code
Post by: red marley on 02 December, 2016, 07:45:57 am

I think Day 2 is easier so mrs_e may have more joy today.

Day 2, my solution

(click to show/hide)

Rather than encode the grid layout of the pad in part a, I went for simple lookup arrays for each of the four directions where the index of the array is the current digit (or rather current digit-1 for 0 indexed arrays) and the value at that index is the next digit given a move in the given direction:

nextDigit(num, dir)
{
   up    = {1,2,3,1,2,3,4,5,6};
   down  = {4,5,6,7,8,9,7,8,9};
   left  = {1,1,2,4,4,5,7,7,8};
   right = {2,3,3,5,6,6,8,9,9};
      
   switch (dir)
   {
      case 'U':
         return up[num-1];
      case 'D':
         return down[num-1];
      case 'L':
         return left[num-1];
      case 'R':
         return right[num-1];
   }
}

There are more elegant algorithmic solutions, but the lookup approach turned out to be useful for part b where the arrangement is more complex. For part b I encoded buttons A, B, C and D as integers 10-13 so I could still use the array lookup approach.

Title: Re: Advent of Code
Post by: David Martin on 02 December, 2016, 08:39:42 am

Interesting. I took a slightly different approach, modelling the keypad more explicitly.

(click to show/hide)

I defined a function for each move that checked to see if it was at the edge of the pad, eg.

def U():
    ycoord = min(2, ycoord+1)

and call that via a lookup table

moves

()

It was then trivial to extend to lookup in a  list of dimensions for extending the problem

ycoord = min(maxima[xcoord], ycoord+1)

And then get the digit from a 2D array (or 1D array of text strings) that model the pad.

code:

(click to show/hide)

data='''...''' # input data
coords=[1,1]
minima=[2,1,0,1,2]
maxima=[2,3,4,3,2]
def U():
    coords[1]=min(maxima[coords[0]],coords[1]+1)
   
def D():
    coords[1]=max(minima[coords[0]],coords[1]-1)


def R():
    coords[0]=min(maxima[coords[1]],coords[0]+1)
   
def L():
    coords[0]=max(minima[coords[1]],coords[0]-1)

moves= {'U': U, 'D':D,'L':L,'R':R}   
keypad = ['  5  ',' A62 ','DB731',' C84 ','  9  ']

code =''
for press in data:
    for m in press:
        moves[m]()
    code = code+str(keypad[coords[0]][coords[1]])
print(code)

Title: Re: Advent of Code
Post by: Diver300 on 02 December, 2016, 08:56:50 am

(click to show/hide)

I used javascript this time.
I didn't encode the keypad at all. I did that manually at the end - it's only 5 numbers each time.

For the first half, I simply limited the x and y to 1 to 3

For the second half, I modelled the limits on x as a function of y and vice-versa:-

     
       if (digit == "U" && y + Math.abs(x-3) < 4.5 ) {y++;}
       if (digit == "D" && y - Math.abs(x-3) > 1.5 ) {y--;}
       if (digit == "R" && x + Math.abs(y-3) < 4.5 ) {x++;}
       if (digit == "L" && x - Math.abs(y-3) > 1.5 ) {x--;}

Title: Re: Advent of Code
Post by: tom_e on 02 December, 2016, 10:57:12 am

Quote from: jo on 02 December, 2016, 07:45:57 am

I think Day 2 is easier so mrs_e may have more joy today.

S'alright, she got there in the end with day 1 last night.  And while still in bed this morning she reported the same thing you have just said after reading day 2.  ;D

Title: Re: Advent of Code
Post by: David Martin on 02 December, 2016, 11:16:20 am

Gone back to day1 in R to force myself to think differently.

(click to show/hide)

Part 1;
data <-''
moves <- strsplit(data,', ')
steps <- as.integer(lapply(moves,substr,2,4)[[1]])
turns <- lapply(moves,substr,1,1)[[1]]
turns[turns=='R']<- 1
turns[turns=='L']<- -1
turns<- as.integer(turns)*c(1,-1)
cp<- cumprod(turns)
xsteps<-seq(1,length(steps),2)
ysteps<-seq(2,length(steps),2)
x <- sum(steps[xsteps]*cp[xsteps])
y <- sum(steps[ysteps]*cp[ysteps])
abs(x+y)

And now to think about part 2..

Title: Re: Advent of Code
Post by: Diver300 on 03 December, 2016, 07:35:46 am

Day 3 seemed simpler to me than either of the previous days.

(click to show/hide)

Excel again. The maths was easy. Data handling any other way would take me longer.
For the second half, I used ability of Excel to copy an area into a larger area, to repeat the pattern.

Title: Re: Advent of Code
Post by: David Martin on 03 December, 2016, 10:35:19 am

Agreed. Still trying to do Day 1 part 2 in R. It's very good for row level manipulations but doing all against all is taxing me a bit. I might try embedding an SQL query in the R code (because one can).

Title: Re: Advent of Code
Post by: red marley on 03 December, 2016, 03:52:27 pm

Day 3

Because I like drawing pictures, I thought I'd create some festive visualisations of my Day 3 answers. Here's part (a) with each green triangle being a 'real' triangle with edge lengths as provided and impossible ones shown as three pronged branches with the given lengths.

(http://staff.city.ac.uk/~jwo/aoc/aoc2016day3a.jpg)

And here is part b with the vertically derived triangles added in red.

(http://staff.city.ac.uk/~jwo/aoc/aoc2016day3b.jpg)

Title: Re: Advent of Code
Post by: David Martin on 04 December, 2016, 08:55:47 am

A bit lengthier to solve today but not hard - bit of regex processing and understanding ascii. Had to look up how to do nested sorts in python as I'd not done that before, otherwise pretty straightforward.

Title: Re: Advent of Code
Post by: Diver300 on 04 December, 2016, 09:58:17 am

I used Javascript again today but kept falling over my own programming inability, but got there in the end.

Title: Re: Advent of Code
Post by: Pingu on 04 December, 2016, 12:09:31 pm

Late starter  ::-)

Day 1 done, a bit harder than expected.

(https://c7.staticflickr.com/6/5576/31041094230_17449958cf_z.jpg) (https://flic.kr/p/PhZHRQ)
AoC_day_01 (https://flic.kr/p/PhZHRQ) by The Pingus (https://www.flickr.com/photos/the_pingus/), on Flickr

Title: Re: Advent of Code
Post by: Pickled Onion on 04 December, 2016, 03:48:07 pm

Quote from: David Martin on 04 December, 2016, 08:55:47 am

A bit lengthier to solve today but not hard - bit of regex processing and understanding ascii. Had to look up how to do nested sorts in python as I'd not done that before, otherwise pretty straightforward.

It was good to practice sort functions, but the best I could come up with for the checksum was

(click to show/hide)

sub checksum{
  my %letters;
  map {$letters{$_}++} split //, ( s/-//g, $_);
  my $ByFrequencyThenAlphabetically = sub {$letters{$b} <=> $letters{$a} or $a cmp $b };
  return substr((join '', sort $ByFrequencyThenAlphabetically keys %letters), 0, 5);
}

I'm sure there must be a way to create the hash anonymously on the fly, but it's eluding me.

Title: Re: Advent of Code
Post by: David Martin on 04 December, 2016, 04:32:48 pm

Quote from: Pickled Onion on 04 December, 2016, 03:48:07 pm

Quote from: David Martin on 04 December, 2016, 08:55:47 am

A bit lengthier to solve today but not hard - bit of regex processing and understanding ascii. Had to look up how to do nested sorts in python as I'd not done that before, otherwise pretty straightforward.

It was good to practice sort functions, but the best I could come up with for the checksum was

(click to show/hide)

sub checksum{
  my %letters;
  map {$letters{$_}++} split //, ( s/-//g, $_);
  my $ByFrequencyThenAlphabetically = sub {$letters{$b} <=> $letters{$a} or $a cmp $b };
  return substr((join '', sort $ByFrequencyThenAlphabetically keys %letters), 0, 5);
}

Would something like:

$data = <INPUT>;
$data=~m/([a-z-]+)(\n+)\[([a-z]+)\])/;
$name=$1
sort { $@{$name=~/$a/g} <=>$@{$name=~/$b/g} or $a cmp $b}  uniq split //, $name =~s/-//g;
be close to what you are looking for? Untested.
ETA: extra $$$$$ because it is perl and I haven't doen that for a while

I'm sure there must be a way to create the hash anonymously on the fly, but it's eluding me.

Title: Re: Advent of Code
Post by: Pickled Onion on 04 December, 2016, 05:05:52 pm

I see where you're going with that, but the wriggly problem is to keep track of the counts for each letter.

Looking forward to tomorrow's offering.

Title: Re: Advent of Code
Post by: David Martin on 04 December, 2016, 05:27:03 pm

Quote from: Pickled Onion on 04 December, 2016, 05:05:52 pm

I see where you're going with that, but the wriggly problem is to keep track of the counts for each letter.

Looking forward to tomorrow's offering.

It does that implicitly doesn't it? you are sorting on the letters and it is inefficient in that it runs the regex for every comparison. You don't need to keep track of the counts for each letter if they are readily recalculable.

Title: Re: Advent of Code
Post by: David Martin on 04 December, 2016, 06:55:46 pm

OK, there is no easy way to calculate the number of occurences of a substring in Perl so I had to craft a simple function for it.

(click to show/hide)

use List::MoreUtils qw(uniq);

sub count{
   $count=0;
   while ($_[0]=~/$_[1]/g){$count++;}
   return $count;
}


open FH, 'day4input.txt';
$scount=0;
while (<FH>){
    $_=~m/^([a-z-]+)([0-9]+)\[([a-z]+)\]/;
    $name=$1;
    $sid=$2;
    $code = $3;
    $name=~s/-//g;
    $chksum=substr (join ('', sort( { count($name, $b) <=> count($name,$a) or $a cmp $b} uniq split //, $name)), 0,5);
    if ($code eq $chksum){
        $scount+=int $sid;
        #print "$code\t$chksum\n";
    }
}
print "Count $scount\n";


This does away with needing any hashes at the expense of efficiency.

Title: Re: Advent of Code
Post by: red marley on 05 December, 2016, 06:10:01 am

Day 5:

(click to show/hide)

Very similar to Day 4 (https://yacf.co.uk/forum/index.php?topic=94710.msg1957846#msg1957846) a year ago. My input (YIMV) required about 7 seconds to compute the relevant hashes for both parts. Helps if your language of choice has access to an MD5 hash generator.

I rather like the challenge to produce a HollywoodOS version of the password decryption. Might have to have a go at that. Now where are those beeps...

Title: Re: Advent of Code
Post by: David Martin on 05 December, 2016, 08:11:13 am

Took mine nearly half a minute. I did have a text console holywood version.. ish.

Title: Re: Advent of Code
Post by: Diver300 on 05 December, 2016, 11:02:34 pm

The server that I ran the .php file on took about 45 seconds to do the second half.

(click to show/hide)

I didn't bother writing code to assemble the final answer. I gradually increased the number of results until I had the ones that I needed. I finished by getting it to stop when it found "00000n" when all I needed was the nth character.

Title: Re: Advent of Code
Post by: red marley on 06 December, 2016, 07:13:45 am

From the creator of Advent of Code this morning...

Quote from: Eric Wastl

I hope everyone has been enjoying #AdventOfCode! Today ends the warmup puzzles. It's uphill from here!

Title: Re: Advent of Code
Post by: Oaky on 06 December, 2016, 07:57:03 am

Quote from: jo on 06 December, 2016, 07:13:45 am

From the creator of Advent of Code this morning...

Quote from: Eric Wastl

I hope everyone has been enjoying #AdventOfCode! Today ends the warmup puzzles. It's uphill from here!

I was just about to post that the first six days felt like "limbering up", and I had a feeling that the difficult stuff was about to start.

Title: Re: Advent of Code
Post by: David Martin on 06 December, 2016, 09:38:02 am

Today was straightforward. I have then worked out how to do it in R without loops. One line to read the data in and one very long line to generate the answer.

(click to show/hide)

day6<-read.table('input.txt') #note this is a table with column header X1
paste(unlist(lapply(1:8, function(y){names(table(as.factor(unlist(lapply(day6$X1, function(x){unlist(strsplit(x, split=character(0)))[y]})))))[order(table(as.factor(unlist(lapply(day6$X1, function(x){unlist(strsplit(x, split=character(0)))[y]})))))][1]})), collapse="")

Title: Re: Advent of Code
Post by: Tim Hall on 06 December, 2016, 01:18:59 pm

The Boy, last night, informed me he's cracked 1-4 and was working on 5.   

Title: Re: Advent of Code
Post by: Oaky on 06 December, 2016, 06:15:18 pm

Quote from: David Martin on 06 December, 2016, 09:38:02 am

Today was straightforward. I have then worked out how to do it in R without loops. One line to read the data in and one very long line to generate the answer.

(click to show/hide)

day6<-read.table('input.txt') #note this is a table with column header X1
paste(unlist(lapply(1:8, function(y){names(table(as.factor(unlist(lapply(day6$X1, function(x){unlist(strsplit(x, split=character(0)))[y]})))))[order(table(as.factor(unlist(lapply(day6$X1, function(x){unlist(strsplit(x, split=character(0)))[y]})))))][1]})), collapse="")

(click to show/hide)

I did it initially in Python with the collections library, where the Counter() class makes it very simple.  (My default approach is to do these first in Python, adopting a test-driven approach with unittest, using whatever standard libraries suggest themselves.  If it looks amenable, I then have another go using Pandas.).

Since this looked amenable, I re-did it in Pandas...

Code: [Select]

import pandas as pd

input_l = []
with open('input.txt') as fd:
    for line in fd:
        input_l.append([c for c in line.rstrip('\n')])
       
data = pd.DataFrame(input_l)

part1 = part2 = ''
for col in data.columns:
    part1 += data[col].value_counts().index[0]
    part2 += data[col].value_counts().index[-1]

print 'Part 1 answer is: {}'.format(part1)
print 'Part 2 answer is: {}'.format(part2)

Then I saw David Martin's R version, so I scratched my head a bit and re-did it in Pandas with no loops...

Code: [Select]

import pandas as pd
df = pd.read_table('input.txt', header=None).apply(lambda x: pd.Series(list(x[0])), axis=1)
part1 = ''.join(df.apply(lambda x: x.value_counts().index[0]))
part2 = ''.join(df.apply(lambda x: x.value_counts().index[-1]))

print 'Message1 is: {}\nMessage2 is: {}'.format(part1, part2)


Title: Re: Advent of Code
Post by: David Martin on 06 December, 2016, 06:25:59 pm

My colleague has commented how he has learned so much in the last few days. I have too, and will certainly look at the bear bones of the Pandas implementation. Python seems to be my 'goto' to start off with (typically with a few sanity checks, not really tests, along the way). Then I might try something else for fun like R or the Perl from previous. I've not really looked at Pandas - I should do. Numpy is as close as I have got.

Looking forward to something a bit more stretching tomorrow.

Title: Re: Advent of Code
Post by: Oaky on 06 December, 2016, 06:34:19 pm

I did consider trying this year in something other than Python, but to be honest, up until now, my day job hasn't involved enough opportunity for data munging for me to have fully assimilated Python yet, despite learning it several years back. 

That's changing right now as I start to spend time with another team in $EMPLOYER, and one of the tools of choice in that team is pandas (plus Jupyter notebooks) so I'm sticking to Python and also playing with the Jupyter/pandas approach on some of these this year.

Title: Re: Advent of Code
Post by: David Martin on 06 December, 2016, 10:09:48 pm

I like the Jupyter notebooks approach to problem solving as you document each step along the way (or should).

Title: Re: Advent of Code
Post by: red marley on 07 December, 2016, 06:35:28 am

Day 7: (ABBA internet protocols)

Do'h. Couldn't work out why I was getting the wrong answer for part a. Spent ages slowly debugging but could not find any problems with the logic of my code. Finally redownloaded the input text to find that my first attempt to download it had missed the last few lines.

Good challenge today though with plenty of scope for creating efficient pattern matching.

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2016, 10:15:25 am

i'm sure there is an efficient and elegant way to do it. Spent far too long trying to vectorise it in R with moderate amounts of nearly success then gave up and brute-forced it in python.

(click to show/hide)

There were two efficiency things. 1. If you split into alternate parts (in/out etc) then calculate the cumulative product of the part numbers in which the pattern is found, then an odd/even test will let you know if it is valid or invalid.and 2. for the second I put all the patterns found for one address into odd or even bins, then checked each pattern in the even bin to see if the inverse was in the odd bin.

Title: Re: Advent of Code
Post by: Oaky on 07 December, 2016, 10:22:52 am

Quote from: David Martin on 07 December, 2016, 10:15:25 am

i'm sure there is an efficient and elegant way to do it. Spent far too long trying to vectorise it in R with moderate amounts of nearly success then gave up and brute-forced it in python.

(click to show/hide)

There were two efficiency things. 1. If you split into alternate parts (in/out etc) then calculate the cumulative product of the part numbers in which the pattern is found, then an odd/even test will let you know if it is valid or invalid.and 2. for the second I put all the patterns found for one address into odd or even bins, then checked each pattern in the even bin to see if the inverse was in the odd bin.

Brute force here too...

(click to show/hide)

for efficiency I created a look-up list of all ABBAs, (working from all distinct two letter itertools.combinations from string.ascii_lowercase) so that I could use "substr in ABBAs" as a test.

for part 2, I constructed two set()s one containing ABAs in the supernets and one containing the inverses of the BABs in the hypernets.  I could then use the set1.isdisjoint(set2) method to test for SSLness

Title: Re: Advent of Code
Post by: Pickled Onion on 07 December, 2016, 01:15:02 pm

Interesting approaches.

Regular expressions seemed the obvious approach...

(click to show/hide)

   
my $count;
map { ! /\[\w*(\w)(?!\1)(\w)(\2)(\1)\w*\]/      # not an ABBA in a hypernet
    and /(\w)(?!\1)(\w)(\2)(\1)/                # and an ABBA in a supernet
    and $count++ } <DATA>;                      # supports TLS
print $count;

Title: Re: Advent of Code
Post by: R_nger on 07 December, 2016, 01:41:03 pm

I'm using node.js and tried to use regular expressions as far as possible. Difficulties today due to not reading the instructions properly 😳

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2016, 02:12:01 pm

Quote from: Pickled Onion on 07 December, 2016, 01:15:02 pm

Interesting approaches.

Regular expressions seemed the obvious approach...

(click to show/hide)

   
my $count;
map { ! /\[\w*(\w)(?!\1)(\w)(\2)(\1)\w*\]/      # not an ABBA in a hypernet
    and /(\w)(?!\1)(\w)(\2)(\1)/                # and an ABBA in a supernet
    and $count++ } <DATA>;                      # supports TLS
print $count;

And I have just learned what a zero width look ahead assertion is. Strangely most of the pages on perl re don't cover that...

Title: Re: Advent of Code
Post by: Oaky on 07 December, 2016, 04:39:51 pm

checkout askalski's brute-force Perl regexp solutions over on the adventofcode subreddit (https://www.reddit.com/r/adventofcode/comments/5gy1f2/2016_day_7_solutions/)

And Eric Wastl's response:- ;)

Quote

[–]topaz2078(AoC creator) 13 points 10 hours ago

Did you do this just to make me cry? Because it worked.

 ;D

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2016, 04:43:46 pm

Did you look at Part 2 of that thread?

Title: Re: Advent of Code
Post by: Oaky on 07 December, 2016, 04:48:56 pm

Quote from: David Martin on 07 December, 2016, 04:43:46 pm

Did you look at Part 2 of that thread?

His Part 2 solution?  Yep!

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2016, 05:06:15 pm

There is some pretty rank coding on display there..

Title: Re: Advent of Code
Post by: R_nger on 07 December, 2016, 05:21:50 pm

Quote from: David Martin on 07 December, 2016, 05:06:15 pm

There is some pretty rank coding on display there..

yep, I'm glad I don't have to support some of that !  I'm not saying mine is pretty or elegant, but at least I'm not on a mission to minimise the line count (and ergo readability)!

Title: Re: Advent of Code
Post by: Ben T on 07 December, 2016, 05:46:37 pm

They put in a thing to deliberately confuse (some) regex parsing implementations, i.e.
zazbz
must match zaz and zbz.

not sure whether the challenge was to simply code in one that supports one match starting before another has ended?
or simply to realise that that is what was going on


https://github.com/bjtaylor1/AoC_2016

Title: Re: Advent of Code
Post by: red marley on 07 December, 2016, 06:23:45 pm

Quote from: R_nger on 07 December, 2016, 05:21:50 pm

Quote from: David Martin on 07 December, 2016, 05:06:15 pm

There is some pretty rank coding on display there..

yep, I'm glad I don't have to support some of that !  I'm not saying mine is pretty or elegant, but at least I'm not on a mission to minimise the line count (and ergo readability)!

Sure. Despite spending most of my career teaching people to prioritise clarity over brevity in programming, there is nevertheless something akin to magic when a 40 line block of procedural code can be replicated with

(click to show/hide)

grep -Pc '(.)(?!\1)(.)\1\w*(([][]\w*){2})*[][]\w*\2\1\2'

(an answer to Day 7 pt b from Reddit)

There's lots of geeky humour on that reddit with people deliberately choosing difficult languages (Brainfuck anyone? (http://www.muppetlabs.com/~breadbox/bf/)) so I'd take the one line solutions in that spirit. I've been impressed with the K language (http://archive.vector.org.uk/art10010830) that some have been using. Seems to produce concise and efficient functional expressions  with a limited vocabulary for the kinds of list processing that has been the main feature of the challenges so far.

Title: Re: Advent of Code
Post by: David Martin on 08 December, 2016, 09:11:21 am

Array index munging today. With a bit of input parsing thrown in.

Title: Re: Advent of Code
Post by: Oaky on 08 December, 2016, 12:13:24 pm

Quote from: David Martin on 07 December, 2016, 05:06:15 pm

There is some pretty rank coding on display there..

It is deliberately perverse,  this guy has form for it.  I believe it was the same person who posted a solution for one day of last years AoC using a Synacor challenge VM.

Title: Re: Advent of Code
Post by: David Martin on 08 December, 2016, 04:04:54 pm

I wasn't talking about the sheer brutality of the explicit regexs but some of the other code snippets that get posted.

Title: Re: Advent of Code
Post by: red marley on 08 December, 2016, 04:55:49 pm

One of the things I like about AoC is that it works with multiple levels of coding skill and experience and on multiple levels. I can use it with my first year computing students as well as get experienced computer science academic colleagues interested. Some solutions can be created with spreadsheets and even on paper, while others benefit from highly specialised languages. Inevitably there will be some pretty clumsy attempts being shared - but again, this is one of the rewarding educational aspects of the challenge, seeing how not to approach a problem as well as what works.

Title: Re: Advent of Code
Post by: Oaky on 08 December, 2016, 05:59:26 pm

Quote from: David Martin on 08 December, 2016, 04:04:54 pm

I wasn't talking about the sheer brutality of the explicit regexs but some of the other code snippets that get posted.

Ahhh,  I understand now.

I saw one solution posted in which I could see a clear bug (that I knew to be a bug because I initially did the same myself, but it was smoked out of my code by the unit tests I'd written).  The author was fessing up to that bug (and another one) which individually would have got him the wrong answer, but coincidentally conspired to cancel out.

Title: Re: Advent of Code
Post by: David Martin on 09 December, 2016, 08:05:10 am

Ah, definitely a step up. Part one done - straightforward once I remembered to

(click to show/hide)

strip the trailing newline

Part 2 is readily tractable but just need to think a little bit further.

Title: Re: Advent of Code
Post by: Pickled Onion on 09 December, 2016, 08:09:15 am

My computer is busted, trying to solve them on a phone would be a challenge too far. I'll have to catch up at the weekend   

Title: Re: Advent of Code
Post by: red marley on 09 December, 2016, 09:02:00 am

Day 9 (decompression)

(click to show/hide)

Initially I accumulated the processed string as I uncompressed it. This was largely for debugging and was fine for the first part. For the second just had to replace the string with a long* integer that kept track of the uncompressed length. Luckily for me, I had created a pure function to do the uncompressing for part 1 so it was easy to adapt to call recursively for part 2.

I suspect the bigger challenge would have been for Eric Wastl in generating the inputs for the challenge as it is very easy to create compressed sequences for part 2 that generate infinite length strings.

* had to be 64 bit as with my input at least, the resulting decompressed string was 10,780,403,063 characters long.

Title: Re: Advent of Code
Post by: David Martin on 09 December, 2016, 09:25:58 am

Quote from: jo on 09 December, 2016, 09:02:00 am

Day 9 (decompression)

(click to show/hide)

Initially I accumulated the processed string as I uncompressed it. This was largely for debugging and was fine for the first part. For the second just had to replace the string with a long* integer that kept track of the uncompressed length. Luckily for me, I had created a pure function to do the uncompressing for part 1 so it was easy to adapt to call recursively for part 2.

I suspect the bigger challenge would have been for Eric Wastl in generating the inputs for the challenge as it is very easy to create compressed sequences for part 2 that generate infinite length strings.

* had to be 64 bit as with my input at least, the resulting decompressed string was 10,780,403,063 characters long.

Is that not part of the challenge (dealing with integer overflows)? i fail to see how an infinite length string could be produced from finite input with that decompression method.

it was a straightforward recursive function to tot up the lengths and only match each pattern once.

Title: Re: Advent of Code
Post by: tom_e on 09 December, 2016, 09:49:07 am

Quote from: Pickled Onion on 09 December, 2016, 08:09:15 am

My computer is busted, trying to solve them on a phone would be a challenge too far. I'll have to catch up at the weekend

;D  I made the mistake of starting one on the phone because it looked pretty easy.  I did succeed, but it was quite painful.

Title: Re: Advent of Code
Post by: red marley on 09 December, 2016, 11:07:29 am

Quote from: David Martin on 09 December, 2016, 09:25:58 am

I fail to see how an infinite length string could be produced from finite input with that decompression method.

(click to show/hide)

An example of never completing:

(5x1)(5x1)ADVENT

will firstly consume the compression instruction (5x1) leading to the insertion of the next 5 characters which are also (5x1). So after the first decompression the string of remaining characters is exactly the same as the original string meaning the processing will never get to the end.

If you replace the above with

(5x2)(5x2)ADVENT

after each decompression, the remaining text to process will the same as the previous one but with an extra (5x2) at the start, so the string grows infinitely.

Title: Re: Advent of Code
Post by: David Martin on 09 December, 2016, 11:32:24 am

Quote from: jo on 09 December, 2016, 11:07:29 am

Quote from: David Martin on 09 December, 2016, 09:25:58 am

I fail to see how an infinite length string could be produced from finite input with that decompression method.

(click to show/hide)

An example of never completing:

(5x1)(5x1)ADVENT

will firstly consume the compression instruction (5x1) leading to the insertion of the next 5 characters which also (5x1) so after the first decompression the string of remaining characters is exactly the same as the original string so the processing will never get to the end.

If you replace the above with

(5x2)(5x2)ADVENT

after each decompression, the remaining text to process will the same as the previous one but with an extra (5x2) at the start, so the string grows infinitely.

OK, I see where you are going with that but you are wrong. given that a compressed string must be formed from an uncompressed string, and given the uncompressed string is [A-Z]+ the compressed string given in your example will never occur. I admit that an invalid string can break the algorithm, but a simple check that all processing instructions are complete (ie contain N characters after the instruction where the instruction is (NxY)) should suffice.

Title: Re: Advent of Code
Post by: red marley on 09 December, 2016, 11:49:30 am

I would agree if Eric Wastl was generating the potentially tens of thousands of compressed files used by this challenge by applying the compression algorithm to multi-gigabyte originals, that would be all you need to guarantee a 'good' compression sequence. But clearly, the scale of this means he will have been generating the compressed strings directly and algorithmically, and that was my point about his input generating challenge being a significant one.

Title: Re: Advent of Code
Post by: David Martin on 09 December, 2016, 12:06:00 pm

But all you need to do is generate a string of valid commands from other valid commands. it is straightforward. You don't need to start with the uncompressed file.

Title: Re: Advent of Code
Post by: red marley on 09 December, 2016, 12:17:42 pm

I'm probably digging myself into a hole here by failing to understand the elegance of your suggested approach to input generation, but :

(5x2)ADVENT generates a valid (finite) uncompressed sequence. And (5xn) is in principle a valid compression command, where n is any integer. But (5xn) applied to that valid sequence renders it invalid. What would be a simple way of detecting such invalid modifications (other than the trivial case of always inserting a non-compression sequence of at least 5 characters after a compression command)?

Title: Re: Advent of Code
Post by: David Martin on 09 December, 2016, 01:24:30 pm

You ensure that n is len(what follows the command) or greater.

So (5xn)ADVENT is fine but as (5xn)ADVENT is of length 10, the smallest thing that can be included is (10xn)(5xn)ADVENT. Anything less is invalid

So to generate the input you cna basically reverse the grammar definition


text := [Expansion]?[text][text]?

Expansion :=  (Zxlen{following text}) where Y is the length of the following [text] and Z >1

buildtext :
    text = null
    loop until break:
         text = text + random select:
             (random integer x length of)buildtext
             character in [A-Z]
            break
    return text

so text=buildtext will give you, for suitable random parameterisation, a valid compressed string.

• for given models of random

Title: Re: Advent of Code
Post by: red marley on 10 December, 2016, 07:39:01 am

^---- Nice. (I think, but I've become distracted by the day 10 challenge)

Title: Re: Advent of Code
Post by: red marley on 10 December, 2016, 07:52:57 am

Day 10 (bot dancing)

The challenges are getting more interesting, and finally varying a little more from the pattern matching that has dominated the first week or so. With the possible exception of the first day, I think the difficulty curve over time is better than last year as it feels more of a steady increase in effort.

As for today...

(click to show/hide)

I initially misinterpreted the challenge in assuming the instructions were issued serially, so wasted time not getting a workable answer.

Once I realised that you initialise all the bots with values or donation instructions then set them off to interact, this became more fun. It took me a while to work out, from the toy example, how the output registers related to the values held by bot 2 so wasn't sure how to provide the answer. When I finally realised that you don't use the output registers to answer part 1 at all, it became an easy task to query for the bot that held 61 and 17.

And because I had been mistakenly examining the output registers before I understood what part 1 required, the second part was trivial.

Title: Re: Advent of Code
Post by: David Martin on 10 December, 2016, 09:49:03 am

(click to show/hide)

It is a simple(ish) graph traversal of the sort I like. I split off the values and built the graph first of all.
I then initialised it with the values and let it run. Each bot waits till it has two values before trying to compare and pass on.
(it would have helped avoid some frustration if I had not inadvertently switched the high and low bots on initialisation and was wondering why I couldn't get the answer)
Part 2 was likewise a slight tweak to get the answer.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2016, 12:26:06 am

And a dotified version of the solution to today's

(https://c4.staticflickr.com/1/135/31561265035_e5c8dd1f31_k.jpg) (https://flic.kr/p/Q5XJvZ)dotfile (https://flic.kr/p/Q5XJvZ) by David Martin (https://www.flickr.com/photos/davidmam/), on Flickr

Title: Re: Advent of Code
Post by: Diver300 on 11 December, 2016, 08:14:49 am

Is the order of applications of the bot rules important?

I got the first part, once some of the chips end up at outputs, I've got 14 bots, each holding one chip, and nothing further happens.

Any suggestions?

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2016, 08:36:57 am

Yes, you have to give the bots the inputs and they only transfer when they have both chips to compare. The graph is acyclic.

(click to show/hide)

I built a simple class for the bot that included the rule for comparison and where the high and low values were. It had a method where it could receive a chip. WHne it received two chips it would compare them and pass them on to the relevant next step (bot or output).
Split the commands into bot and value ones, and runt he bot ones first to build up the network. Then feed the values in and see where they end up (the outputs).

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2016, 08:41:46 am

The first proper hard one today.

(click to show/hide)

It looks like a finite state machine with branch and bound to determine the routes but there are a lot of potential states.
I'm tempted to brute force tree walk through all valid moves, recording each state and the number of moves it took to get there.
There may be a better way as this is not an acyclic graph. Each move can be done in both directions and you may get to a state via multiple valid moves.
Still some thinking to do. That may be this afternoons challenge.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2016, 02:38:07 pm

There is a recursion depth issue. Still bruteforcing it. There may be a way to optimise the strategy but I haven't worked out how to do that yet. This is taking some time. maybe I should set a search order based on energy minimisation?

ETA: Part 1 done. Part 2 adds substantially and my approach may not be suitable. There has to be a smarter way of doing this but I don't see it.

As a measure of difficulty I should plot my leaderboard position against time. It might be quicker to do a binary search of the final answer, waiting a minute between each input than to calculate the answer using my 'crawl the whole net' approach.

ETA:
There is a smarter way.

(click to show/hide)

The problem is recursive in the same manner as towers of Hanoi or the classic Husbands and Wives. There are positions in H&W from which it is insoluble. The twist is having more than two positions and my brain cannot sort out more than that there is an algorithm behind it.

However, it still looks like a binary search on the correct answer is quicker than brute forcing it.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2016, 04:58:27 pm

Brute force mostly won the day. Got to a position that was a maximum of 6 off but wasn't sure if it was optimal. It wasn't. Iterated back through the odd numbers till I got the right one. There is a one then five then ten minute delay between answer submissions..

Title: Re: Advent of Code
Post by: red marley on 11 December, 2016, 06:34:12 pm

Day 11 (elevator isotope exercises)

That was an exercise in humility for me. By far the toughest puzzle yet of 2016, but satisfying nonetheless.

Part 1:

(click to show/hide)

I spent far to long creating the scaffolding to represent the problem. And stupidly while I had originally encoded the rule that prevented lift movement if no items carried, I somehow managed to delete this. The result was that it reduces the number of moves required (from 11 to 9 in the test case, but many more in the real cases) and therefore generates an incorrect answer. I eventually spotted the error so was able to calculate a correct result.

The depth of the search tree was too much for my implementation so I introduced an arbitrary maximum depth (99 in the first instance). This allowed me to exhaustively search the solution space up to that depth and to find an optimal answer by trimming branches of the tree that deeper than the shortest path solution so far found. This took approach found a solution in about 40 seconds of calculation time.

Not very elegant or efficient, but enough to get the correct answer. It was at this point that I noticed that the lower places on the global leader board were taking 2hrs 45 minutes to find an answer to part 2 (on previous days it was more typically 15-20 minutes)...

Part 2:

(click to show/hide)

I tried running the same brute force algorithm for the 4 extra items, but it soon became clear this would take too long and at that point I had no idea what the depth of optimal answer in the search tree might be.

My first attempt at optimisation was embarrassingly crude: I set the maximum search depth to the depth of part 1 +2, and if no answer found, doubled it and re-searched. This gave me an upper and lower bounds to the correct answer (49 and 98 in my case) after a couple of hours calculation, but honing in on the answer was taking too long.

The second and successful optimisation was to recognise that you should prioritise moving pairs of items up and only single items down. This had a dramatic effect, finding the optimal answer in less than 5 minutes calculation time.

However, looking now at the approaches taken by some on the subreddit, there were plenty of much more elegant approaches that could find the solution in a second or two.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2016, 07:37:32 pm

(click to show/hide)

I think brute forcing even with optimisations is non-optimal. I'm fairly sure that there is a simple calculation that can be done - there are some invalid states so you have to work, where possible from the top upwards.

Title: Re: Advent of Code
Post by: red marley on 11 December, 2016, 08:10:12 pm

A tiny modification that knocks the Day 11 part 2 solution down to less than 2 seconds computation time:

(click to show/hide)

When traversing the solution space you obviously need to keep track of previously visited nodes on the graph (to avoid infinite cycling). I had been doing this by generating a hash representing the state of the system (each item and its floor plus the elevator position).

However, the name of the element is unimportant in the 'signature' of the shortest path through the solution graph, only whether it is a generator or microchip (the names are still important for the valid move detection though). So basing the hash only on the generator/microchip status and elevator position prunes all duplicate isomorphic branches of the tree (which is almost all of it).

I have just tested this with a fictitious example with a further 4 items (16 in total) and it finds the shortest path (99 moves) in under 20 seconds. Starting with 20 items in total finds the shortest path (119 moves) in about 3 minutes.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2016, 08:23:30 pm

(click to show/hide)

There are some thoughts that a lower bound for the solution is readily calculated by taking the number of items and taking two items at a time up a floor, coupled with one item down, minus one for each floor. Not valid for all states but close enough to give many folk a very quick response.

I could recode to prune all pairs as a set of homogenous labels and extract as necessary. I'm not sure I can be bothered now. Learned a lot though.

Title: Re: Advent of Code
Post by: Ben T on 12 December, 2016, 03:43:33 am

(click to show/hide)

I used bruteforce but gave each state a score, and always process the 'best' first, and this ran in under 10 seconds for part 1, without jo's optimization above. (Part 1 also worked with it, but didn't require it.)
The score was simply how top-heavy it was, i.e. (4 x count on floor 4) + (3 x count on floor 3) + (2x count on floor 2) + (count on floor 1) etc.

I started off processing all of each depth before moving onto the next depth, and left this going while I went to squash (several hours) and it still hadn't found an answer by the time I got back. Once I switched it to allow it to process e.g. some of depth n+2 before it had processed all of depth n if they had a better score, it found a result in seconds.
I also pruned any branches that had some items on the 1st floor and some on 4th but none on 2nd or 3rd,  as I thought this was no better strategically than with those items on 2nd and 4th, and while this was triggered a few times it didn't seem to make much difference to computation time.

jo's optimization was required (to run in under a minute anyhow) for part 2 however, whether I would have been too thick to figure that out myself I don't know, and whether it would have found a result eventually without it I'm not sure. The only difference between part 1 and 2 seems to be that that optimization is required, so maybe realizing that was what he was getting at with part 2.


https://github.com/bjtaylor1/AoC_2016/blob/master/Day11/UnitTest1.cs (method Solve())

Title: Re: Advent of Code
Post by: red marley on 12 December, 2016, 06:05:56 am

Comment on BenT's Day 11 solution:

(click to show/hide)

Nice. Effectively an A* (https://en.wikipedia.org/wiki/A*_search_algorithm) type search strategy.  I had initially hoped to do something similar but didn't know how to weight the cost function (your top-heavy metric). I think I was too distracted by the fact that the lift goes down almost as much as it goes up.

My feeling is that with a tuning of that cost function, you may be able to speed up the search considerably.

As for Day 12 - some welcome relief (especially for anyone who did Day 23 last year (http://adventofcode.com/2015/day/23) or the excellent Synacor Challenge (https://challenge.synacor.com)) after spending too much of Sunday in front of the computer. I suspect today isn't the last we'll see of assembly language interpreting.

Title: Re: Advent of Code
Post by: David Martin on 12 December, 2016, 06:52:29 am

Day 12 again can be optimised

(click to show/hide)

cpy 5 d
cpy 3 c
inc a
dec c
jnz c -2
jnz d -4


is simply to add c to a d times and set c and d to 0. There are similar multiple loops in the code and teasing out the actual logic would save some time. I bruteforced it.

Title: Re: Advent of Code
Post by: red marley on 12 December, 2016, 07:02:45 am

Day 12 (response to David Martin)

(click to show/hide)

I too just iterated through without any optimisation. What I liked about Day 11 was that part two forced us to consider optimisation, so I was a little disappointed that for Day 12, while possible, wasn't at all necessary.

I like the idea of having to construct higher level operations from the assembly language in order to solve the challenge. Addition as in your example, but also multiplication and exponention would probably be needed for an input that couldn't be processed in a practical time without optimisation.

Title: Re: Advent of Code
Post by: David Martin on 12 December, 2016, 10:29:01 am

Quote from: jo on 12 December, 2016, 07:02:45 am

Day 12 (response to David Martin)

(click to show/hide)

I too just iterated through without any optimisation. What I liked about Day 11 was that part two forced us to consider optimisation, so I was a little disappointed that for Day 12, while possible, wasn't at all necessary.

I like the idea of having to construct higher level operations from the assembly language in order to solve the challenge. Addition as in your example, but also multiplication and exponention would probably be needed for an input that couldn't be processed in a practical time without optimisation.

But then you would be in 'how to write a compiler 101' territory rather than a short wee puzzle to solve.

Title: Re: Advent of Code
Post by: Ben T on 12 December, 2016, 01:24:13 pm

I wonder how difficult it would be to convert the instructions to actual assembly language? If there are equivalents that they would map to on a 1-1 basis.

Title: Re: Advent of Code
Post by: David Martin on 12 December, 2016, 01:45:19 pm

And then set each register as a set of binary digits on a front panel display for an arduino for example?

Title: Re: Advent of Code
Post by: Ben T on 12 December, 2016, 02:39:02 pm

You can start a C++ program on a normal computer in seconds, and it can include an "asm { ... } " block IIRC. I'm sure one of the instructions is 'mov', which would be similar to their 'jnz', etc. So I was thinking merely output them to the console to then input into the adventofcode site...but if you know a better way knock yourself out :)

Title: Re: Advent of Code
Post by: Oaky on 12 December, 2016, 04:07:13 pm

I fell behind on account of running out of time on the train to work on Friday, and having a surfeit of Real Life stuffs at the weekend.  I've since mostly caught up, but I'm leaving Day 11 until tonight when I can have a proper think about it.  That one looks considerably more difficult than the others so far.

Title: Re: Advent of Code
Post by: Diver300 on 12 December, 2016, 06:57:36 pm

I converted day 12 into assembly language for a pic24, a 16 bit microcontroller. I ran the code on a simulator on a PC, and found that 32 bit resolution is needed, well more than 16 bits anyhow.

Line numbering went to pot, so I numbered the lines, and therefore the jumps, according to the original input.

Part 2 was then trivial, and took about 10 seconds to run. It would have been <1 second on a real microcontroller.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2016, 08:29:57 am

Haven't attempted day 13 yet but I know the algorithm

(click to show/hide)

Dynamic programming algorithm, not quite the same as we use in sequence alignment as you have to backtrack occasionally.
Start at 1,1 and calculate the shortest path back to the beginning. This will be a choice of three paths in the classic version. Might have to do the same from the end and find the meeting point.

Title: Re: Advent of Code
Post by: red marley on 13 December, 2016, 08:58:39 am

Or to put it another way (day 13)...

(click to show/hide)

The same as Day 11 but with simpler constraints and a maximum of only 4 out edges per node.

Title: Re: Advent of Code
Post by: Tim Hall on 13 December, 2016, 09:22:20 am

The Boy was still stuck on 11 last night, but very pleased with his solution for 12.  He tried describing to me what he'd done, finishing off with "you don't understand this do you?"  I did manage to grasp he was pleased with the elegance of his solution though.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2016, 11:02:12 am

A colleague of mine pointed me at a way to simplify day 13.

(click to show/hide)

preprocess a large enough grid to remove all dead ends.
What is left will be the path.

Title: Re: Advent of Code
Post by: Oaky on 13 December, 2016, 11:16:48 am

(click to show/hide)

Day 13 was fairly trivial, given what I'd already learned about Breadth-first searching and had already implemented towards day 11 (which I haven't yet solved!).

The reason day 11 still remains unsolved for me are the intertwined questions of how to represent the state, and how to generate the valid next states.  I keep tying myself up in knots trying to decide on a good way to do these.  I'm currently working on the premise that I'm just going to choose a representation, and will code up the valid move (i.e. neighbouring node) generation routines based on that representation regardless of how ugly/inelegant/inefficient they end up being.

Title: Re: Advent of Code
Post by: red marley on 13 December, 2016, 11:26:00 am

In response to David's colleague's heuristic...

(click to show/hide)

But might that not result in more computation? With solutions that find possible routes, you can keep track of the current shortest path so limit all subsequent searches to that shortest path - 1. With the suggested pre-processing heuristic, you can end up searching for dead ends in a greater number steps than the shortest path. To take an extreme case, the following, where S is the start location and D is the destination, would be slower with the heuristic than without it.

####################
#DS................#
####################

Title: Re: Advent of Code
Post by: tom_e on 13 December, 2016, 08:16:57 pm

Managed day 12 with only pencil and paper.  ;D

Title: Re: Advent of Code
Post by: Oaky on 13 December, 2016, 08:28:54 pm

Quote from: tom_e on 13 December, 2016, 08:16:57 pm

Managed day 12 with only pencil and paper.  ;D

I feel guilty if I manually encode the input data into my script rather than reading it from a file and parsing it.  ;)

Title: Re: Advent of Code
Post by: David Martin on 14 December, 2016, 01:06:27 am

Code: [Select]

Finally got round to day 13. Easy enough for the first part, second part is giving me a little grief for a reason I cannot fathom.
I've plotted it and worked through by hand but the answer I get appears to be too low for the site. Having checked it exhaustively by hand, I am convinced there is a bug.
[spoiler]
Input is 1350, value I get is 115. This is too low
[/spoiler]

ETA. Read the instructions. The maze bounds are 0,0 not 1,1.
Doh!
[spoiler]
ETA - new answer 122, still wrong.

[code rows=40]#X##X##            ###     ##### ##### 
#X#XXX# ##  ######## # #####   #  ## ##
XX##XX## ## #  #   ### #     #     ## ##
#XX#X# ## #    ##   #  # #### ####   # 
#XX#X## ####### # # #### ## ###   ## # 
##X#XXX#  #    ## #   #    #    #  # # #
##XXX#X#  # ##    #   ## #  #### #   # 
# ##XXX# ## #### ####  ## # #  ## ##  ##
#####XX#     ###  # #   #   #   ###### 
  ####X###      #  #### ## ### #  ## ###
#  ###X##### ##### ## ## #  ##  #   #   
##  #XXXX#X###  ##   # #  # # #  ##   ##
    #XX#XXXXX#     #  ##### #  # # #####
## #### ####X#  ##### ##  # ###  ###  ##
## #XX###XXXX## #  ##  #  ### ###   #  #
#  ##XXXXX##X##      # # #  #     #  # 
### #X######X##### #  ## #  # ###  #   #
XXX##X##  #XXXXXX## #    # ##   ### ####
X#XXXXXX# #XX##X# #  ##  #   ###  # #  #
XX##XX#X# #####X# ############ ####     
## ##XXX###  #XX##    #  #    #  ##### #
 #  ##X#     #X# ####    # ##        ##
######X# ##  #XX#XX####### ##### ## # ##
##XXX#X##### ##XXXXXX#  #   #  #### ## #
 #X#XXXXXX## # ##XX#XX# ##  # #        #
 ## #####X#  ## ### #X#  # ## # ##  ## #
  # #  ##X### ##  ##XX# ##    ## ##### #
  #     ##   # ##  # ##   ## # ##   #   
######    ## ## # ## # ### # ## #   #  #
     #  #  #   ## #  ### # #   ### ####
 ##  ### #   #    #     ##  ##  ## #  #
#####  ## ##  ## ###### # #   # #  #  #
Sorted: There was a hidden sidestep that added two to the path length.
[/spoiler]

Title: Re: Advent of Code
Post by: red marley on 14 December, 2016, 06:34:13 am

Day 14 Hash-mash

People who liked Day 5 will love Day 14.

Hint:

(click to show/hide)

hash-cache (for part two at least)

I like to start each day by making at least one stupid mistake before breakfast. Today's was

(click to show/hide)

to search for instances of triplets and fives that occur anywhere in each hash rather than as three and five consecutive characters (e.g. 12131 would match as a triplet). It soon became obvious that this was giving a very wrong answer, but I did waste too much time writing an efficient frequency counter for my incorrect interpretation of the question.

Title: Re: Advent of Code
Post by: Diver300 on 14 December, 2016, 07:30:22 am

(click to show/hide)

I assumed that hashing would take a long time as I coded for part 1, making part 2 easier.

I didn't store the hashes, only a list of indexes and the repeated characters.

(click to show/hide)

I looked for instances of 5 repeats, then looked back in my index for the instances of 3 repeats.

The flaw in that plan is that the index of the 3 repeat can be lower for a higher index 5 repeat.

On mine, the 59th instance of 5 repeats had its character repeat 3 times in hash number 22065,
while the 65th instance of 5 repeats had its character repeat 3 times in hash number 22045

Title: Re: Advent of Code
Post by: David Martin on 14 December, 2016, 09:17:11 am

For Diver300:

(click to show/hide)

I did the same - a dictionary containing all the 'first triple' indexes and then check that for valid hashes on finding a pentuple.

Carry on the loop until number of distinct indices is >64 and the current index is > max index+1000.

More than the required number of indices are found so sorted(set(indices))[63] works

part 2 - processor cycles are cheap.

For Jo:

(click to show/hide)

Silly bugs, many silly bugs. Took 4x longer to debug than write the code.

1. Increment the counter at the start and the end of the loop so I was going up in steps of 2 instead of 1.
2. When I checked the cache for valid triples on finding a pentuple  I wasn't discounting the current index (which contains a triple)
3. Assuming I had just found 64 indices

Title: Re: Advent of Code
Post by: Oaky on 14 December, 2016, 09:31:03 am

Quote from: David Martin on 14 December, 2016, 09:17:11 am

(click to show/hide)

2. When I checked the cache for valid triples on finding a pentuple  I wasn't discounting the current index (which contains a triple)

I did that one too.

(click to show/hide)

I also didn't think to check the next 1000 indices after I'd collected at least 64 keys.

My script still got the right answers without doing this, but that's a bit of luck, I guess.  I felt the need to go back afterwards and fix that.

Title: Re: Advent of Code
Post by: Ben T on 14 December, 2016, 09:49:08 am

Quote from: jo on 14 December, 2016, 06:34:13 am

Day 14....
Hint:

(click to show/hide)

hash-cache (for part two at least)

(click to show/hide)

Another option is retrospectively mark indexes as being valid keys.

When I found one that's repeated 3 times, mark that index as such.
When I found one that's repeated 5 times, look at the previous 1000, and if any have already been marked as having that character repeating 3 times, add them to a list of valid indexes.
When there are 64 indexes, stop after the next 1000 iterations (as although we have 64, they may not necessarily be the lowest 64... there might be more that have been marked as 3 but not yet marked as having a 5 in the next 1000)
Sort the indexes, and pick the 64th one.

(edit: looking at spoilers I see i'm not the first to do this method)

I vaguely recalled an algorithm to find prime numbers is similar, e.g. 2 marks 2, 4, 6, 8 etc as not being prime, 3 marks 3, 6, 9, and 12 etc as not being prime ... or something like that....
(Of course using a cache may look simpler/nicer)

Title: Re: Advent of Code
Post by: Oaky on 14 December, 2016, 10:05:47 am

Quote from: Ben T on 14 December, 2016, 09:49:08 am

Quote from: jo on 14 December, 2016, 06:34:13 am

Day 14....
Hint:

(click to show/hide)

hash-cache (for part two at least)

(click to show/hide)

You don't need one if you retrospectively mark indexes as being valid keys.

(click to show/hide)

I didn't cache mine.  Part 2 takes ~30 seconds for my input.


oaky@camembert ~/Dropbox/AdventOfCode/16/14 $ time ./s14.py -p 2 -s zpqevtbw
Part 2 answer for salt 'zpqevtbw': key 22423

real  0m33.976s
user  0m32.676s
sys   0m0.300s

Title: Re: Advent of Code
Post by: red marley on 14 December, 2016, 11:27:33 am

Day 14 continued...

(click to show/hide)

Using Oaky's input, and caching (which only ever stores 1001 hashes at any one time), my perhaps simplistic, approach takes ~15 seconds for part 2.

Create a FIFO queue of 1001 hex hashes; pop the first one check it for a triplet; If found scan through the remaining 1000 for a quintuplet; push the next hex hash and repeat until 64 found.

Title: Re: Advent of Code
Post by: Diver300 on 14 December, 2016, 03:44:26 pm

Day 14

(click to show/hide)

You don't even need to store the whole hash, just the number and the character(s) in the repeating triplet(s).

Title: Re: Advent of Code
Post by: Oaky on 14 December, 2016, 04:03:15 pm

Quote from: Diver300 on 14 December, 2016, 03:44:26 pm

Day 14

(click to show/hide)

You don't even need to store the whole hash, just the number and the character(s) in the repeating triplet(s).

(click to show/hide)

That's what I do... I maintain a dict for the triples, indexed by the char that repeats, each entry of which is a list of index numbers that generate a triple of that char.  I do the same for the quintuplets.

I only ever call the md5 or stretched_md5 function once for a given input, then test the result against the triplet and the quintuplet regexps and store the integers corresponding to the matches in my dicts, so I was puzzled by all the talk of caching.

The quintuplets dict looks like this after my part 2 run:

Code: [Select]

0: []
1: []
2: []
3: []
4: []
5: []
6: [9698]
7: [6268, 8518]
8: []
9: [19069]
a: [22467]
b: [12058]
c: []
d: []
e: []
f: [12014, 17867]

The triples dict is similar except it has about 160 entries in each list

Title: Re: Advent of Code
Post by: Diver300 on 14 December, 2016, 04:32:31 pm

Quote from: tom_e on 13 December, 2016, 08:16:57 pm

Managed day 12 with only pencil and paper.  ;D

I've just belatedly solved day 11 similarly.

(click to show/hide)

The method of getting the stuff to the top floor doesn't need to be found.

Each up movement of the lift takes two things up, and each down one has to take one thing down. At least for my puzzle, I never found any solutions but I guessed that a solution exists that never needs to take two things down or just one thing up.

Then the number of movements only depends on the sum of the floors that each object has to be raised.

Title: Re: Advent of Code
Post by: David Martin on 14 December, 2016, 04:33:57 pm

Mine sounds very much like Oaky's using a dict of arrays to store candidate indices which can then be reviewed if pentuples are found.

Title: Re: Advent of Code
Post by: tom_e on 14 December, 2016, 05:04:32 pm

Quote from: Diver300 on 14 December, 2016, 04:32:31 pm

Quote from: tom_e on 13 December, 2016, 08:16:57 pm

Managed day 12 with only pencil and paper.  ;D

I've just belatedly solved day 11 similarly.

It's an interesting question - I have some sympathy for Oaky's point of view above.  Any question where the input is quite small is potentially vulnerable to a more pure mathematical approach.  Particularly something like day 11 where the answer is relatively small and you get more than one attempt.

In this case, I'd argue you've crossed that fine line to guessing.  But since I am myself putting the first answer produced by code into the box and only going back to check for bugs if it fails (and suspect I am not alone in this), I'm not sure how clear-cut the "guessing is cheating" argument is.

Also, note (https://www.reddit.com/r/adventofcode/comments/5hoia9/2016_day_11_solutions/db1v1gk/).

Title: Re: Advent of Code
Post by: Oaky on 14 December, 2016, 06:01:23 pm

Quote from: Diver300 on 14 December, 2016, 04:32:31 pm

Quote from: tom_e on 13 December, 2016, 08:16:57 pm

Managed day 12 with only pencil and paper.  ;D

I've just belatedly solved day 11 similarly.

(click to show/hide)

The method of getting the stuff to the top floor doesn't need to be found.

Each up movement of the lift takes two things up, and each down one has to take one thing down. At least for my puzzle, I never found any solutions but I guessed that a solution exists that never needs to take two things down or just one thing up.

Then the number of movements only depends on the sum of the floors that each object has to be raised.

(click to show/hide)

Whilst your method gets the right answer for my input, I can't convince myself that it's anything other than a lower bound, with no reason to believe that it can be achieved for all inputs.

If I understand your argument correctly, then the position given in here (https://www.reddit.com/r/adventofcode/comments/5hoia9/2016_day_11_solutions/db1v1ws/?st=iwp8qb7y&sh=b2de087f) would take 6 moves where in fact I think 11 is the minimum.

Code: [Select]

F4 .   ...   HM   ...  HeM   ...  ...   
F3 E   ...  ...   ...  ...    LG   LM   
F2 .    HG  ...   HeG  ...   ...  ...   
F1 .   ...  ...   ...  ...   ...  ...   


Title: Re: Advent of Code
Post by: Diver300 on 14 December, 2016, 06:13:20 pm

Quote from: Oaky on 14 December, 2016, 06:01:23 pm

Quote from: Diver300 on 14 December, 2016, 04:32:31 pm

Quote from: tom_e on 13 December, 2016, 08:16:57 pm

Managed day 12 with only pencil and paper.  ;D

I've just belatedly solved day 11 similarly.

(click to show/hide)

The method of getting the stuff to the top floor doesn't need to be found.

Each up movement of the lift takes two things up, and each down one has to take one thing down. At least for my puzzle, I never found any solutions but I guessed that a solution exists that never needs to take two things down or just one thing up.

Then the number of movements only depends on the sum of the floors that each object has to be raised.

(click to show/hide)

Whilst your method gets the right answer for my input, I can't convince myself that it's anything other than a lower bound, with no reason to believe that it can be achieved for all inputs.

If I understand your argument correctly, then the position given in here (https://www.reddit.com/r/adventofcode/comments/5hoia9/2016_day_11_solutions/db1v1ws/?st=iwp8qb7y&sh=b2de087f) would take 6 moves where in fact I think 11 is the minimum.

Code: [Select]

F4 .   ...   HM   ...  HeM   ...  ...   
F3 E   ...  ...   ...  ...    LG   LM   
F2 .    HG  ...   HeG  ...   ...  ...   
F1 .   ...  ...   ...  ...   ...  ...   


I agree.

I am not arguing that my solution is in any way robust. The example that you give is intentionally awkward, and I think that the puzzle always starts with the elevator on the ground floor, and it has to be soluble, so I don't think that real puzzles can be quite as awkward as yours, but I am sure there are some that have to start with less efficient moves.

I suspect that once the initial awkwardness is sorted, the  bulk of a solution is perfectly efficient, but I haven't proved it.

We shall see if later puzzles leave me lost due to my lack of rigor in day 11

Title: Re: Advent of Code
Post by: Oaky on 14 December, 2016, 06:38:53 pm

Quote from: Diver300 on 14 December, 2016, 06:13:20 pm

Quote from: Oaky on 14 December, 2016, 06:01:23 pm

Quote from: Diver300 on 14 December, 2016, 04:32:31 pm

Quote from: tom_e on 13 December, 2016, 08:16:57 pm

Managed day 12 with only pencil and paper.  ;D

I've just belatedly solved day 11 similarly.

(click to show/hide)

The method of getting the stuff to the top floor doesn't need to be found.

Each up movement of the lift takes two things up, and each down one has to take one thing down. At least for my puzzle, I never found any solutions but I guessed that a solution exists that never needs to take two things down or just one thing up.

Then the number of movements only depends on the sum of the floors that each object has to be raised.

(click to show/hide)

Whilst your method gets the right answer for my input, I can't convince myself that it's anything other than a lower bound, with no reason to believe that it can be achieved for all inputs.

If I understand your argument correctly, then the position given in here (https://www.reddit.com/r/adventofcode/comments/5hoia9/2016_day_11_solutions/db1v1ws/?st=iwp8qb7y&sh=b2de087f) would take 6 moves where in fact I think 11 is the minimum.

Code: [Select]

F4 .   ...   HM   ...  HeM   ...  ...   
F3 E   ...  ...   ...  ...    LG   LM   
F2 .    HG  ...   HeG  ...   ...  ...   
F1 .   ...  ...   ...  ...   ...  ...   


I agree.

I am not arguing that my solution is in any way robust. The example that you give is intentionally awkward, and I think that the puzzle always starts with the elevator on the ground floor, and it has to be soluble, so I don't think that real puzzles can be quite as awkward as yours, but I am sure there are some that have to start with less efficient moves.

I suspect that once the initial awkwardness is sorted, the  bulk of a solution is perfectly efficient, but I haven't proved it.

We shall see if later puzzles leave me lost due to my lack of rigor in day 11

 ;D

BTW - I gather that the position I quoted (from p_tseng's reddit post), is a subset of a position that occurs during the optimal solution of an actual input that somebody was given.

Title: Re: Advent of Code
Post by: red marley on 14 December, 2016, 11:25:15 pm

Day 14 speed of calculation.

Given the various ways of finding a solution seemed to result in quite different times taken to calculate, I thought I'd have a look at where the bottleneck was when using Java.

(click to show/hide)

My approach was finding answer to part two in around 12 seconds using a simple caching of 1000 hex hashes (i.e. without the dictionary optimisation described by Oaky and David Martin).

In Java using MessageDigest, the MD5 hash calculation is fast. So even adding uncached hashes (i.e. freshly finding the next MD5 hash for every triplet and quintuplet search), this only added about 6 seconds in total for part two.

I was searching for triplets and quintuplets using simple character comparison. Replacing this with a regex (.)\1{2} (triplet) and (.)\1{4} (quintuplet) was slower, but only a little - adding 2 seconds for part 2.

The real saving/bottlneck was in converting the MD5 hash byte array into hex. Using Java's String.format - String.format("%0" + (bytes.length << 1) + "x", new BigInteger(1, bytes)) added approximately 1 minute to the calculation time. (ETA: removed needless generation of uppercase and then conversion to lowercase)

Instead, I used this optimised bit shifting and array lookup to keep calculation below 12 seconds:


private final static char[] HEX_ARRAY = "0123456789abcdef".toCharArray();

static String toHex(byte[] bytes)
{
   char[] hexChars = new char[bytes.length*2];
   for (int j=0; j<bytes.length; j++)
   {
      int byteValue   = bytes[j] & 0xFF;
      hexChars[j*2]   = HEX_ARRAY[byteValue >>> 4];
      hexChars[j*2+1] = HEX_ARRAY[byteValue & 0x0F];
   }
   return new String(hexChars);
}

Title: Re: Advent of Code
Post by: David Martin on 15 December, 2016, 07:43:07 am

(click to show/hide)

Why do you need to convert to lower case? It isn't material to the problem. You could split it into 8 bit bytes and compare those (lots of bitshift and bitmask could be very quick)

Day 15:
Straightforward.

(click to show/hide)

Modulo (time+offset+startposition) == 0 when it is in the optimal position.
Optimisations I haven't done:
If the first n discs are aligned at point t, the step size to the next aligned point will be the cumulative product of the disc sizes.

Title: Re: Advent of Code
Post by: red marley on 15 December, 2016, 08:02:48 am

Quote from: David Martin on 15 December, 2016, 07:43:07 am

Why do you need to convert to lower case? It isn't material to the problem.

Because...

(click to show/hide)

The stretched hash for part two requires a lower case hex as input to the MD5. Upper case would give a different result. However, I realise I have made stupid mistake #65 for the day as String.format() can create lower-case hex directly with "x" rather than "X", which knocks off nearly two minutes from part B (but still way slower than bit shifting/masking).

Title: Re: Advent of Code
Post by: Diver300 on 15 December, 2016, 09:02:38 am

Quote from: David Martin on 15 December, 2016, 07:43:07 am

Day 15:
Straightforward.

(click to show/hide)

Modulo (time+offset+startposition) == 0 when it is in the optimal position.
Optimisations I haven't done:
If the first n discs are aligned at point t, the step size to the next aligned point will be the cumulative product of the disc sizes.

(click to show/hide)

Only because the disk sizes are distinct prime numbers

As is often the case, part 1 could be solved by brute force, but the seemingly small addition of part 2 made brute force impractical so thinking was needed. My first solution to part 2 depended on the brute force solution to part 1, which made me realise that a far faster and more elegant solution was possible to part 1.

Title: Re: Advent of Code
Post by: David Martin on 15 December, 2016, 09:31:39 am

Smartish brute force.. in my case, though it should be possible to describe the equation analytically.

Title: Re: Advent of Code
Post by: Oaky on 15 December, 2016, 09:42:58 am

Dumb brute force for both parts (Python 2).

Part 1 runs in ~0.6 sec and Part 2 in ~2.1 sec.

I had a feeling when I set it away using the same brute force that part 2 was going to take too long that way and that I'd have to go back and recode it to be smarter, and was surprised when that wasn't the case.

I did go back and apply a couple of optimisations to my discStack class:-

(click to show/hide)

namely

1. pre-add the 1 second delays for the capsule dropping between discs to the starting positions for the discs.
2. reorder the discs to test the one with the most positions first.  My test checks each disc in order and always returns as soon as it finds a disc that blocks the capsule.

Those two items speed my part 2 up by approx 20%

Title: Re: Advent of Code
Post by: Ben T on 15 December, 2016, 09:56:17 am

Day 15 really easy. No optimizations even remotely necessary. Both parts run instantaneously

(click to show/hide)

Code: [Select]

int positions[] =  { 0, 0, 0,  2, 2,  0,  7    /* part 2:*/, 0 };
int positionCount[]{ 0, 7, 13, 3, 5, 17, 19    /* part 2: */,11 };


const bool allAligned(const int t)
{
for (int t0 = 1; t0 < sizeof(positions) / sizeof(int); t0++)
{
const int posAtt0 = (positions[t0] + t + t0) % positionCount[t0];
if (posAtt0 != 0) return false;
}
return true;
}

const int getFirstTimeAllAligned()
{
for (int t = 0; t < 0x7fffffff; t++)
{
if (allAligned(t))
return t;
}
return -1;
}

int main()
{
std::cout << getFirstTimeAllAligned() << std::endl;
    return 0;
}


Title: Re: Advent of Code
Post by: Ben T on 15 December, 2016, 10:48:44 am

Day 15 one liner

(click to show/hide)

Code: [Select]

    class Program
    {
        static int Main()
        {
            Console.Out.WriteLine(Enumerable.Repeat(0, 0xffffff).Select((d, i) => i).ToArray().First(t => new[]
            {
                new[] {0, 0},
                new[] {0, 7},
                new[] {0, 13},
                new[] {2, 3},
                new[] {2, 5},
                new[] {0, 17},
                new[] {7, 19}
                /* part 2: */, new [] {0,11}
            }.Select((p, i) => new {p, i}).Skip(1).All(a => (a.p[0] + a.i + t)%a.p[1] == 0)));
            return 0;
        }
    }


Title: Re: Advent of Code
Post by: Oaky on 15 December, 2016, 11:29:21 pm

After day 15's relatively easy problem, what's the betting day 16 is going to be a stinker?

Title: Re: Advent of Code
Post by: Oaky on 16 December, 2016, 05:48:51 am

Quote from: Oaky on 15 December, 2016, 11:29:21 pm

After day 15's relatively easy problem, what's the betting day 16 is going to be a stinker?

Apparently not.

(click to show/hide)

I woke up early and couldn't get back to sleep so started almost immediately after 05:00.

Simplistic brute force in string-slice-tastic Python (https://github.com/MarkNOakden/AdventOfCode/blob/master/16/16/s16.py).  The unit tests and argument parsing comprise more than three times as many lines as the actual logic ;)

oaky@camembert ~/Dropbox/AdventOfCode/16/16 $ time ./s16.py -p 1
Checksum for disk of length 272, from pattern '10001001100000001' is '10101001010100001'

real   0m0.311s
user   0m0.024s
sys   0m0.060s
oaky@camembert ~/Dropbox/AdventOfCode/16/16 $ time ./s16.py -p 2
Checksum for disk of length 35651584, from pattern '10001001100000001' is '10100001110101001'

real   0m6.665s
user   0m5.556s
sys   0m0.804s

What am I going to do with the rest of my morning?  Might have to do some work! ;D

Title: Re: Advent of Code
Post by: red marley on 16 December, 2016, 06:14:26 am

I didn't really dig today's (Day 16). Just grinding though some standard string manipulation, which is more or less tedious depending on your language of choice.

Yesterday's was more interesting because of there was plenty of scope for optimisation and was good practice for taking a functional approach (and unlike Day 11, could be done before breakfast).

Title: Re: Advent of Code
Post by: Diver300 on 16 December, 2016, 06:17:09 am

Quote from: Oaky on 16 December, 2016, 05:48:51 am

Quote from: Oaky on 15 December, 2016, 11:29:21 pm

After day 15's relatively easy problem, what's the betting day 16 is going to be a stinker?

Apparently not.

(click to show/hide)

I woke up early and couldn't get back to sleep so started almost immediately after 05:00.

Simplistic brute force in string-slice-tastic Python (https://github.com/MarkNOakden/AdventOfCode/blob/master/16/16/s16.py).  The unit tests and argument parsing comprise more than three times as many lines as the actual logic ;)

oaky@camembert ~/Dropbox/AdventOfCode/16/16 $ time ./s16.py -p 1
Checksum for disk of length 272, from pattern '10001001100000001' is '10101001010100001'

real   0m0.311s
user   0m0.024s
sys   0m0.060s
oaky@camembert ~/Dropbox/AdventOfCode/16/16 $ time ./s16.py -p 2
Checksum for disk of length 35651584, from pattern '10001001100000001' is '10100001110101001'

real   0m6.665s
user   0m5.556s
sys   0m0.804s

What am I going to do with the rest of my morning?  Might have to do some work! ;D

(click to show/hide)

I set part 2 going (in javascript) while I got breakfast and contemplated cunning solutions than didn't need 35 million characters stored, but when I got back to the computer, it had finished.
I will also end up doing work today!

Title: Re: Advent of Code
Post by: Oaky on 16 December, 2016, 06:25:35 am

Quote from: Oaky on 15 December, 2016, 11:29:21 pm

After day 15's relatively easy problem, what's the betting day 16 is going to be a stinker?

So, day 16 was another easy one.  After this much respite, I'm getting anxious about what Mr Wastl has in store for us next.

(click to show/hide)

I see the Christmas tree in the parking lot got erected once day 16 was complete.

Title: Re: Advent of Code
Post by: red marley on 16 December, 2016, 06:59:13 am

Quite sensibly, our toughest one this year (Day 11) was at the weekend. Last year, arguably the toughest one was Day 19 (molecules), also at the weekend. So perhaps we should brace ourselves for a toughie either tomorrow or the day after. I'm sure he wouldn't be so cruel as to set a time consuming challenge the following weekend given we may have other commitments on Sunday morning.

Title: Re: Advent of Code
Post by: Ben T on 16 December, 2016, 09:48:24 am

Recently went back and did Day 24 of last year and thought that was pretty hard (partitioning).
https://github.com/bjtaylor1/AoC_2015/blob/master/Day24/UnitTest1.cs

Title: Re: Advent of Code
Post by: Oaky on 16 December, 2016, 10:20:42 am

for 2015, day 19 part 2 was the absolute hardest IMO.

Title: Re: Advent of Code
Post by: David Martin on 16 December, 2016, 10:44:12 am

Looking at todays (Just got to it, running part 2), it flips the checksum (almost) with each doubling, so the checksum may be calculable from the starting code without needing to calculate the entire string.

(click to show/hide)

I've done a bit of whiteboarding and I'm pretty sure this is possible, and that it should be feasible to do it in a tiny amount of memory, not much more than a small number of multiples of the initial data input.

No time to play further as I have marking to do and the dept christmas lunch.

Title: Re: Advent of Code
Post by: Diver300 on 16 December, 2016, 12:28:16 pm

Quote from: Oaky on 16 December, 2016, 10:20:42 am

for 2015, day 19 part 2 was the absolute hardest IMO.

That's where I got stuck. This year I've skipped a second part. Maybe I should go back and look at the 2015 ones

Title: Re: Advent of Code
Post by: red marley on 16 December, 2016, 02:21:09 pm

Quote from: jo on 16 December, 2016, 06:14:26 am

I didn't really dig today's (Day 16). Just grinding though some standard string manipulation, which is more or less tedious depending on your language of choice.

I was wrong about this. Looking elsewhere (no links here to avoid obvious spoilers), there are some really elegant ways of processing the input that stop this being such an iterative task. If anyone's feeling like they've done too much proper work today, there's plenty of scope for thinking about some nifty optimisations. I should never have doubted Mr Wastl. What makes these challenges great is their hidden depths.

Title: Re: Advent of Code
Post by: Ben T on 16 December, 2016, 04:16:35 pm

Quote from: jo on 16 December, 2016, 02:21:09 pm

Quote from: jo on 16 December, 2016, 06:14:26 am

I didn't really dig today's (Day 16). Just grinding though some standard string manipulation, which is more or less tedious depending on your language of choice.

I was wrong about this. Looking elsewhere (no links here to avoid obvious spoilers), there are some really elegant ways of processing the input that stop this being such an iterative task. If anyone's feeling like they've done too much proper work today, there's plenty of scope for thinking about some nifty optimisations. I should never have doubted Mr Wastl. What makes these challenges great is their hidden depths.

That's fine, although my viewpoint would be that if iteration works fast enough then any further optimisation is straying from science into art :)
I was hoping he was going to say that the memory would be something like many GB, not 272.

Quote from: Diver300 on 16 December, 2016, 12:28:16 pm

Quote from: Oaky on 16 December, 2016, 10:20:42 am

for 2015, day 19 part 2 was the absolute hardest IMO.

That's where I got stuck. This year I've skipped a second part. Maybe I should go back and look at the 2015 ones

Having done 2016 day 11, 2015 day 19 part 2 wasn't that hard as it's a similar principle:

(click to show/hide)

I got it to run in 1 min 20s using my 'best branch first' algorithm from 2016 day 11, starting from the target molecule and working backwards towards "e", scoring branches first on total length then on 'reducability' (sum of 'reductions' of all replacements contained within, where the reduction of each replacement is the number of characters it will reduce it by)
(without the reducability it churns for ages with no sign of getting hotter)
https://github.com/bjtaylor1/AoC_2015/blob/master/Day19DotNet/UnitTest1.cs#L120

Title: Re: Advent of Code
Post by: Diver300 on 16 December, 2016, 07:28:37 pm

Quote from: Ben T on 16 December, 2016, 04:16:35 pm

Quote from: jo on 16 December, 2016, 02:21:09 pm

Quote from: jo on 16 December, 2016, 06:14:26 am

I didn't really dig today's (Day 16). Just grinding though some standard string manipulation, which is more or less tedious depending on your language of choice.

I was wrong about this. Looking elsewhere (no links here to avoid obvious spoilers), there are some really elegant ways of processing the input that stop this being such an iterative task. If anyone's feeling like they've done too much proper work today, there's plenty of scope for thinking about some nifty optimisations. I should never have doubted Mr Wastl. What makes these challenges great is their hidden depths.

That's fine, although my viewpoint would be that if iteration works fast enough then any further optimisation is straying from science into art :)
I was hoping he was going to say that the memory would be something like many GB, not 272.

Quote from: Diver300 on 16 December, 2016, 12:28:16 pm

Quote from: Oaky on 16 December, 2016, 10:20:42 am

for 2015, day 19 part 2 was the absolute hardest IMO.

That's where I got stuck. This year I've skipped a second part. Maybe I should go back and look at the 2015 ones

Having done 2016 day 11, 2015 day 19 part 2 wasn't that hard as it's a similar principle:

(click to show/hide)

I got it to run in 1 min 20s using my 'best branch first' algorithm from 2016 day 11, starting from the target molecule and working backwards towards "e", scoring branches first on total length then on 'reducability' (sum of 'reductions' of all replacements contained within, where the reduction of each replacement is the number of characters it will reduce it by)
(without the reducability it churns for ages with no sign of getting hotter)
https://github.com/bjtaylor1/AoC_2015/blob/master/Day19DotNet/UnitTest1.cs#L120

(click to show/hide)

Well having failed on 2015 day 19 pt 2, all I could come up with for 2016 day 11 was a swift calculation of the lower limit of the number of moves, which turned out, for my list of objects, to be right.

Title: Re: Advent of Code
Post by: David Martin on 17 December, 2016, 08:29:22 am

And day 17 appears. I may have to think a little.

Title: Re: Advent of Code
Post by: Oaky on 17 December, 2016, 04:45:22 pm

(click to show/hide)

Another application for day 11's breadth-first search.

This time I coded a bug into my next-node generation function which instead of checking if (newx, newy) was inside the grid boundary, was instead checking (newx, newx)  :-[

This cause the third part 1 test case to fail, but not the first two.  It also didn't stop my code finding the correct part 1 answer.

I only found it because with that bug in place, running against part 2 turned into an exponential time problem, consuming all the memory in my VM.

I think I'm going to write a library implementation of BFS, using the problems so far as a specification for the required generality.  ;D

Title: Re: Advent of Code
Post by: David Martin on 17 December, 2016, 06:28:31 pm

Finally got round to part 1. Part 2 is running, hopefully without an infinite loop.

ETA: hopes were in vain but infinity was removed and results obtained.

Title: Re: Advent of Code
Post by: Ben T on 17 December, 2016, 07:02:33 pm

On Day 17 part 2,

(click to show/hide)

Am I right in thinking you have to actually exhaust all possible branches due to the fact there is no cyclic-ness, as each visit to each square has a different hash and therefore a different set of possibilities for where to go from here, and thus might produce a longer path than the current best. ?

(The same is true for part 1 but for the fact that the best is the shortest, so you can prune all branches that are already as long as the best path to the vault but not reached it yet.)

Or is there actually a possible prune available for part 2?

My part 2 examples, and puzzle, currently run in between 30s and a few (<5) minutes, very slightly quicker (but not critically so) if I don't bother storing visited paths to avoid cyclic-ness (cyclicity?) to save a bit of memory. Part 1 runs in under a second.

Seems to be an exercise in resolving permutations, rather than combinations.

Title: Re: Advent of Code
Post by: red marley on 17 December, 2016, 07:19:15 pm

(click to show/hide)

The graph should be acyclic as the MD5 hashes of an accumulated set of path instructions should never repeat. So no need to store previously visited hashes. The search will always terminate when location hits [3,3] and is bounded within a manhattan distance of 6 from the exit so the search space is relatively small and can be accomplished exhaustively to find the longest path.  It only took a couple of seconds to solve with my brute force Java implementation.

Note that if the graph were cyclic (as it was on the 11th), the longest path problem is not easily solvable.

Title: Re: Advent of Code
Post by: David Martin on 17 December, 2016, 08:02:45 pm

(click to show/hide)

For the first prt I used a branch and bound strategy to prune any paths longer than the first complete one I found.
I iterated back along that path trying all possible non-taken routes.

For the second part it was much the same except not bounding the search, just checking if the current path was the longest when I reached 3,3 and backing off  to the previous branch when there was nowhere else to go.

ran in a few seconds.

 

Title: Re: Advent of Code
Post by: red marley on 17 December, 2016, 08:40:15 pm

I thought I'd do a bit of analysis of challenge difficulty (http://gicentre.net/aoctimes), as measured by leaderboard completion time, to see what we have in store for the rest of 2016 (my guess: a toughie tomorrow and a more challenging final week)

Title: Re: Advent of Code
Post by: Ben T on 18 December, 2016, 12:08:36 am

The times (and thus points) are definitely skewed though because it makes no observation of when you started it.
Did someone finish it early because they're better at coding or just because they could be bothered to get up early...
For instance, I have to be at my desk in the week, so usually start it at 9 am, but didn't even look at today's till at least 4pm.

Title: Re: Advent of Code
Post by: red marley on 18 December, 2016, 05:58:15 am

Except that the leaderboard from which those stats were derived is only the first 100 finishers. Looking at the reddit discussions it is clear that all those who feature in the top 100 will have started the second the day's puzzle was released (with the exception of day 1, 2015 which I excluded).

Title: Re: Advent of Code
Post by: red marley on 18 December, 2016, 07:02:52 am

Day 18 (trapped tiles)

(click to show/hide)

I converted the ^s and .s into 1s and 0s to give a binary representation of each row. Each triplet is then a trap if its decimal is 1 (001), 3 (011), 4 (100) and 6 (110).

However, there is a quicker more elegant way to identify traps, with a bit of a nerdy clue in the symbols used in this challenge:

(click to show/hide)

Arranging the trap configurations in a grid:
001
011
100
110

makes it clearer that it is just an XOR between the left and right bits ('^' being the XOR symbol in several programming languages)

And here's an obvious visual spoiler of the room configuration (highlighted as the central column):

(click to show/hide)

The room is part of larger other seasonal Sierpinski building.

(http://staff.city.ac.uk/~jwo/aoc/aocDay18Small.png)

and larger version of the image (http://staff.city.ac.uk/~jwo/aoc/aocDay18.png).

 

(Edited to provide a more seasonal image of the tile layout [and a design for some rather natty Christmas underpants])

Title: Re: Advent of Code
Post by: David Martin on 18 December, 2016, 07:52:39 am

(click to show/hide)

I had thought of doing bitwise manipulations but ended up being really inefficient with pattern matching.

bitstring=int('0b'+bits)
newstring=0
for p in range(100):
    newstring>> ((bitstring <<p ) & 5 ) & ((bitstring << p )& 5 ^5)

or something along those lines (I've probably got that horribly wrong)

Title: Re: Advent of Code
Post by: Diver300 on 18 December, 2016, 11:00:28 am

I've just caught up with day 17. Reading the question fully would have save some time.

(click to show/hide)

I found the longest possible path that didn't get to the corner, rather than the longest one that did. The differences were just a few steps for all the examples.

Title: Re: Advent of Code
Post by: Ben T on 18 December, 2016, 11:01:47 am

Did you manage to skip any rows, i.e. avoid having to do every single 400,000 transformations, or doesit just improve the speed at which you can generate each row from the next.
I thought if it repeated at, say, 100,000, then you could simply multiply the result at that point by 4. But it doesn't.

The ones I really like are where an optimization is essential rather than just pretty.

Title: Re: Advent of Code
Post by: red marley on 18 December, 2016, 02:23:00 pm

Quote from: Ben T on 18 December, 2016, 11:01:47 am

Did you manage to skip any rows, i.e. avoid having to do every single 400,000 transformations, or doesit just improve the speed at which you can generate each row from the next.

(click to show/hide)

Given the relationship between a Sierpinski triangle and the Fibonacci sequence I wouldn't be surprised if there was some algebraic way of calculating the sum up to the nth row without iterating. But my mathematical knowledge isn't good enough to work it out.

However you can achieve some decent processing savings in Java at least by keeping the tiles as character arrays and just comparing L and R values for each new row for equality (which is a faster equivalent of the XOR comparison which is in turn a faster equivalent of the 4 rules specified in the challenge). This reduces the calculation time for part two on my machine from about 3 seconds to 0.15 seconds.

Title: Re: Advent of Code
Post by: red marley on 19 December, 2016, 08:11:45 am

Day 19 (present nabbing)

Great problem today. I like it because it can be tackled from several different angles (with varying degrees of efficiency). A little more challenging in part because if you calculate the wrong result it is not immediately obvious why, so debugging can be more difficult (DAMHIKT).

Title: Re: Advent of Code
Post by: David Martin on 19 December, 2016, 08:17:37 am

Actualy part 1 is analytic

(click to show/hide)

There is a pattern which allows an equation to be written to derive the correct answer. Did that part with pen and paper (and only used a computer to do the calculation).

(click to show/hide)

All n**2-1 are valid (binary all 1s) and are the maxima in the rising pattern. From that you can work back.
Take the next n**2-1, from this subtract twice the difference between your number and this next peak. That is your elf

Part 2 looks more challenging. I will try to find a similar equation.

Title: Re: Advent of Code
Post by: David Martin on 19 December, 2016, 09:12:23 am

As is part 2 but slightly different as it is not continuous as a quick simulation of the first 45 parties shows (from 5-99 elves)

(click to show/hide)

It is 3**n instead of 2**n that is the key.

(click to show/hide)

The maxima are at 3**n, and between 3**n and 2*3**n (where n is floor(log(number,3)) ) the elf is number - 3**n (even) and between 2*3**n and 3**n+1 it is 3**(n+1) -2*(3**(n+1) - number)

Very pleased to have solved it elegantly without needing to brute force it.

Title: Re: Advent of Code
Post by: Ben T on 19 December, 2016, 10:51:12 am

day 19 part 1:

(click to show/hide)

int get_answer(int numElves)
{
   int hpt_pow = (int)log2(numElves);
   int hpt = pow(2, hpt_pow);
   int ans = (numElves - hpt) * 2 + 1;
   return ans;
}

Title: Re: Advent of Code
Post by: Ben T on 19 December, 2016, 01:10:50 pm

day 19 part 2:

(click to show/hide)

int get_answer_part2(int numElves)
{
   if (numElves == 1) return 1;
   int b = (int)(log(numElves - 1) / log(3));
   int c = pow(3, b);
   int d = numElves - c;
   if (d > c) return c + (d - c) * 2;
   else return d;
}

Title: Re: Advent of Code
Post by: Ben T on 19 December, 2016, 05:53:25 pm

generic iterator template for branch style problems
https://github.com/bjtaylor1/AoC_2016/blob/master/puzzle_iterator.h
used in day 17: https://github.com/bjtaylor1/AoC_2016/blob/master/Day17b/Day17b.cpp
part 2 runs in sub-10s in release mode with /Ox.

also works for 2015 day 19 1+2.

Title: Re: Advent of Code
Post by: Oaky on 19 December, 2016, 07:26:42 pm

(click to show/hide)

it's (almost) another Christmas tree :)

(http://www.oakden.org/mark/bike/yacf/pics/AoC16_19.png)

Title: Re: Advent of Code
Post by: David Martin on 20 December, 2016, 07:28:37 am

That wasn't particularly challenging - or maybe I am missing something

(click to show/hide)

like an elegant way to do it other than iterating through the list keeping track of the overlapping range so far..

Title: Re: Advent of Code
Post by: red marley on 20 December, 2016, 08:07:50 am

I agree.

(click to show/hide)

I assume you sorted the list before scanning for the range gaps. The only thing that caught me out was I forgot to account for the fact that the upper bound of a given range pair could overlap more than one of the next sorted range pairs. This made no difference to part one and the test case, but meant my first attempt at part two had too many valid IP addresses.

I suppose an interesting variant of the problem might be to find an efficient inline solution for 64 bit addresses (i.e. potentially too many to store in memory and sort).

Title: Re: Advent of Code
Post by: David Martin on 20 December, 2016, 10:52:35 am

(click to show/hide)

Yes, with just a few hundred it was fine to sort first.

My first attempt at part 1 had missed that ranges could be non-overlaping but adjacent (simple error and failure to check output properly) but then went on till the maximum found so far was more than 1 below the next start in the sorted list.

Easy to adapt to then add the gap sizes to get the total.

Title: Re: Advent of Code
Post by: tom_e on 20 December, 2016, 11:11:00 am

(click to show/hide)

I thought about merging, but didn't bother in the end.  Just did a search based on splitting the space in half repeatedly.

So look for firewall rules overlapping the current search range.  If one covers the range entirely, every IP in the range is blocked.  If none are overlapping, every IP in the range is allowed.  If there are overlapping rules, cut the space in half and search both (but start from the already overlapping rules, not the full set).  Sort of like a cube-splitting thing for spatial searching / indexing.  I forget the name.

Fast enough.  I assume merging would help, but I didn't actually check how "mergy" the input data was.

Title: Re: Advent of Code
Post by: red marley on 20 December, 2016, 01:07:19 pm

(click to show/hide)

How mergey? This mergey for my input...

(http://staff.city.ac.uk/~jwo/aoc/aoc2016day20Small.png)

(and a larger version (http://staff.city.ac.uk/~jwo/aoc/aoc2016day20.png))

where IP addresses are from left to right, blacklist ranges are horizontal black lines and valid IP addresses as vertical blue lines. The degree of redness indicates how many overlapping blacklists cover any one IP address.

BTW: There is no need to actually merge ranges; simply keep track of the current maximum blacklist address as you process each sorted range looking for any lower range bound that is at least one greater than the current maximum (takes less than 10 milliseconds to compute both parts on my machine).

Title: Re: Advent of Code
Post by: Oaky on 20 December, 2016, 01:21:04 pm

(click to show/hide)

I used numpy and pandas to get both parts pretty easily.  I managed to take into account one of the two gotchas mentioned below (non-overlapping but adjacent ranges) but missed the other.  It turned out not to affect my answer for either part though.

I also didn't originally allow for the possibility of any allowed IPs above the top of the final blacklist block (my input had the final blacklist block ending at MAXINT, so this didn't matter for me either).

I then went back and recalculated it without the first_gap function, using pandas alone (and numpy to do the initial sort).

Here's my Jupyter Notebook with both methods in it (https://github.com/MarkNOakden/AdventOfCode/blob/master/16/20/s20.ipynb)

Title: Re: Advent of Code
Post by: Ben T on 20 December, 2016, 06:41:00 pm

Quote from: David Martin on 20 December, 2016, 07:28:37 am

That wasn't particularly challenging - or maybe I am missing something

(click to show/hide)

like an elegant way to do it other than iterating through the list keeping track of the overlapping range so far..

(click to show/hide)

No, that is the elegant way to do it. The agricultural way is: https://github.com/bjtaylor1/AoC_2016/blob/master/Day20cpp/Day20cpp.cpp#L1195 :)  :sick:
runs in under a second though :)

Title: Re: Advent of Code
Post by: David Martin on 20 December, 2016, 10:19:38 pm

I was looking at the problem and thinking that it maps onto a typical biological problem 'which parts of my gene have no sequence coverage?'

I'm not sure there is a specific tool for that - I'd probably write a similar script +/- the parsing of appropriate formats.

Title: Re: Advent of Code
Post by: Ben T on 21 December, 2016, 12:37:24 pm

Day 21 relies on realising the fact that

(click to show/hide)

"rotate based on position of letter X" is only one-to-one, and thus has an inverse, if the total number of letters is even. Which it is in the puzzle input ( 8 ), but not in the examples (5)

Title: Re: Advent of Code
Post by: David Martin on 21 December, 2016, 12:49:58 pm

Not done it yet. Broadband outage at home so I have sneaked into the office to get it onto the PC. Will look at it tonight, but it doesn't seem so hard.
Not looked at the spoilers either.

Title: Re: Advent of Code
Post by: R_nger on 21 December, 2016, 01:29:39 pm

What's happening to Jo"s leader board ? Some mischievous anonymous user(s) having fun ?

Title: Re: Advent of Code
Post by: tom_e on 21 December, 2016, 01:41:52 pm

 ::-)  <tries to look innocent and not childish>

Title: Re: Advent of Code
Post by: R_nger on 21 December, 2016, 01:53:17 pm

Quote from: tom_e on 21 December, 2016, 01:41:52 pm

::-)  <tries to look innocent and not childish>

LOL... I just popped over to the CDC thread...and you've beaten me to it !!

Title: Re: Advent of Code
Post by: red marley on 21 December, 2016, 02:33:50 pm

Anonymous user 107436 needs to get their act together and get a nice silver star for Day 14.

Title: Re: Advent of Code
Post by: tom_e on 21 December, 2016, 02:46:36 pm

Yeah, I couldn't decide about that pixel.  A spurt would take too many rows, and I'm already norty flagged on github now.

Just for you, jo.

Title: Re: Advent of Code
Post by: red marley on 21 December, 2016, 03:12:54 pm

Quote from: Ben T on 21 December, 2016, 12:37:24 pm

Day 21 relies on realising the fact that

(click to show/hide)

"rotate based on position of letter X" is only one-to-one, and thus has an inverse, if the total number of letters is even. Which it is in the puzzle input ( 8 ), but not in the examples (5)

Or

(click to show/hide)

Any forward rotation function, however convoluted the rules, can only ever result in 8 possible new arrangements. So it is a simple matter of testing up to 8 standard rotations of the encrypted password to see which one would be generated by the original forward 'rotation based on position' function.

I only realised this after I spent the best part of an hour defining the inverse rotation based on position function.
 

Title: Re: Advent of Code
Post by: Oaky on 21 December, 2016, 04:41:06 pm

(click to show/hide)

I somehow convinced myself that the rotate based on position would have no inverse, and so thought I'd have to do some sort of forwards brute force on it.  I also convinced myself (through running time on my part 1) that I'd have to make my forward mapping more efficient to finish in reasonable time.

I spent an hour writing something that would automatically try to compose certain subsequent lines of the input into quicker single step permutations, before working out that that wasn't going to work.

I decided just to code up the naive brute force "run each permutation through the forward scrambler" loop that I originally thought of doing and set it away to keep my machine warm while I thought about another approach.

1.6 seconds later it returned with the answer!  d'oh! ;D

Title: Re: Advent of Code
Post by: Oaky on 21 December, 2016, 05:37:49 pm

Quote from: Ben T on 21 December, 2016, 12:37:24 pm

Day 21 relies on realising the fact that

(click to show/hide)

"rotate based on position of letter X" is only one-to-one, and thus has an inverse, if the total number of letters is even. Which it is in the puzzle input ( 8 ), but not in the examples (5)

(click to show/hide)

I'm not sure the bit in bold is true.  As far as I can see, only strings of length 1, 3 and 8 will generate a one-to-one mapping based on the "rotate based on position of letter X" rule.

Code: [Select]

Results of 'rotate based on position of letter f'
Input length is 1

In   Out

f -> f

IS one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 2

In    Out

f. -> .f
.f -> .f

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 3

In     Out

f.. -> .f.
.f. -> f..
..f -> ..f

IS one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 4

In      Out 

f... -> .f..
.f.. -> ...f
..f. -> .f..
...f -> ...f

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 5

In       Out   

f.... -> .f...
.f... -> ...f.
..f.. -> f....
...f. -> ..f..
....f -> f....

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 6

In        Out   

f..... -> .f....
.f.... -> ...f..
..f... -> .....f
...f.. -> .f....
....f. -> ....f.
.....f -> f.....

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 7

In         Out     

f...... -> .f.....
.f..... -> ...f...
..f.... -> .....f.
...f... -> f......
....f.. -> ...f...
.....f. -> .....f.
......f -> f......

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 8

In          Out     

f....... -> .f......
.f...... -> ...f....
..f..... -> .....f..
...f.... -> .......f
....f... -> ..f.....
.....f.. -> ....f...
......f. -> ......f.
.......f -> f.......

IS one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 9

In           Out       

f........ -> .f.......
.f....... -> ...f.....
..f...... -> .....f...
...f..... -> .......f.
....f.... -> .f.......
.....f... -> ...f.....
......f.. -> .....f...
.......f. -> .......f.
........f -> f........

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 10

In            Out       

f......... -> .f........
.f........ -> ...f......
..f....... -> .....f....
...f...... -> .......f..
....f..... -> f.........
.....f.... -> ..f.......
......f... -> ....f.....
.......f.. -> ......f...
........f. -> ........f.
.........f -> f.........

IS NOT one-to-one

----------------------------------------


Title: Re: Advent of Code
Post by: David Martin on 21 December, 2016, 09:02:49 pm

Quote from: Oaky on 21 December, 2016, 05:37:49 pm

Quote from: Ben T on 21 December, 2016, 12:37:24 pm

Day 21 relies on realising the fact that

(click to show/hide)

"rotate based on position of letter X" is only one-to-one, and thus has an inverse, if the total number of letters is even. Which it is in the puzzle input ( 8 ), but not in the examples (5)

(click to show/hide)

I'm not sure the bit in bold is true.  As far as I can see, only strings of length 1, 3 and 8 will generate a one-to-one mapping based on the "rotate based on position of letter X" rule.

Code: [Select]

Results of 'rotate based on position of letter f'
Input length is 1

In   Out

f -> f

IS one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 2

In    Out

f. -> .f
.f -> .f

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 3

In     Out

f.. -> .f.
.f. -> f..
..f -> ..f

IS one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 4

In      Out 

f... -> .f..
.f.. -> ...f
..f. -> .f..
...f -> ...f

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 5

In       Out   

f.... -> .f...
.f... -> ...f.
..f.. -> f....
...f. -> ..f..
....f -> f....

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 6

In        Out   

f..... -> .f....
.f.... -> ...f..
..f... -> .....f
...f.. -> .f....
....f. -> ....f.
.....f -> f.....

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 7

In         Out     

f...... -> .f.....
.f..... -> ...f...
..f.... -> .....f.
...f... -> f......
....f.. -> ...f...
.....f. -> .....f.
......f -> f......

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 8

In          Out     

f....... -> .f......
.f...... -> ...f....
..f..... -> .....f..
...f.... -> .......f
....f... -> ..f.....
.....f.. -> ....f...
......f. -> ......f.
.......f -> f.......

IS one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 9

In           Out       

f........ -> .f.......
.f....... -> ...f.....
..f...... -> .....f...
...f..... -> .......f.
....f.... -> .f.......
.....f... -> ...f.....
......f.. -> .....f...
.......f. -> .......f.
........f -> f........

IS NOT one-to-one

----------------------------------------
Results of 'rotate based on position of letter f'
Input length is 10

In            Out       

f......... -> .f........
.f........ -> ...f......
..f....... -> .....f....
...f...... -> .......f..
....f..... -> f.........
.....f.... -> ..f.......
......f... -> ....f.....
.......f.. -> ......f...
........f. -> ........f.
.........f -> f.........

IS NOT one-to-one

----------------------------------------


From 5 onwards your rotation is wrong. 

Sent from my SM-G920F using Tapatalk

Title: Re: Advent of Code
Post by: David Martin on 21 December, 2016, 11:57:50 pm

Ok, guilty of not reading the instructions. Fortunately I could grab the data at work today but have to enter the answers with the phone as I currently have no broadband. So slightly delayed but now there.

Sent from my SM-G920F using Tapatalk

Title: Re: Advent of Code
Post by: red marley on 22 December, 2016, 08:05:02 am

Day 22 (grid computing)

Nice meaty challenge today. First part straightforward but I have to go to work now before getting a solution for second part. Will think about it on way in.

Title: Re: Advent of Code
Post by: David Martin on 22 December, 2016, 09:01:14 am

Likewise. Part 1 was straightforward, almost a one-liner in python.

(click to show/hide)

Code: [Select]

import itertools
len([ x for x in itertools.permutations([y.strip().replace('T','').split() for y in open('day22input.txt').readlines()][2:],2) if int(x[0][2]) >0 and int(x[0][2])<=int(x[1][3])])



Title: Re: Advent of Code
Post by: David Martin on 22 December, 2016, 01:09:41 pm

Part 2: Not much coding needed here - easy to do by inspection and simple arithmetic.

(click to show/hide)

Once the data has been parsed it is easy to check that the small disks have the property that none of them hold more data than the smallest can handle, and the large disks just act as walls.
Then you are not so much moving data as moving empty space around. Easy to visualise:

Code: [Select]

.............................
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#0..............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............
.............#...............I have swapped X and Y as the data is listed in column order. I have to get the 0 to the bottom left and then to the top left, bringing the key data with it.
Each step in a data agnostic way is one move. To move the data it is 5 moves per step. Arithmetic then gives the answer.

Title: Re: Advent of Code
Post by: Oaky on 22 December, 2016, 04:30:13 pm

(click to show/hide)

I spent too long staring at my logic for part 1 trying to work out why I had the wrong answer before it dawned on me I had forgotten to convert the values from the input to int and so was doing my < comparison on strings instead  :-[

Once that was fixed, I wrote a dumper to print the grid in the format as per the part 2 example, then just solved it by inspection .

I will probably try setting my BFS searcher on it at some point.

Title: Re: Advent of Code
Post by: red marley on 22 December, 2016, 04:39:29 pm

^--- Probably a bit of an unhidden spoiler there David.

(click to show/hide)

I mostly liked today's puzzle even though it was a bit of a D'oh! moment in the end. I liked it because it had a deliberate distractor in Part 1 that belied the simplicity of the solution to part 2. The ability to step back and realise a problem is less complex than it first appears is something I admire (and need to improve).

For me I spent too long thinking about a suitable hashing to keep track of previous states of the array and a cost function that could adapt to changing array elements. I was getting a short, but not shortest path to move the empty disk to the top-right so I was getting a credible but wrong answer. In debugging my search I displayed the map of the disks and it was only then that it occurred to me that it might be a simple shortest path with a simple barrier. Given that such a path would not involve self-crossing, it was just a matter of confirming that all disks could potentially swap with their 4 neighbours (accounting for the barrier and edge cells). Shown visually, here are the number of swappable neighbours with my input.


 2  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  G*
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  2
 3  4  4  4  4  4  4  4  4  4  4  4  3 ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
 3  4  4  4  4  4  4  4  4  4  4  4  4  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  2
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  _  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 3  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  4  3
 2  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  3  2

And then it was just a case of adding the number of steps to move G* from top right to top left (5 moves per shift left).

Title: Re: Advent of Code
Post by: David Martin on 22 December, 2016, 09:27:11 pm

I am attempting to fill in the blanks from last years. The lack of a daily deadline doesn't seem to help.

I do think that many of them are harder than this year. The one I am currently toying with is the elves delivering presents. It is obviously some heinous factorial problem, but instead of a straight sum of factors, it is a sum of the product of every permutation.
Wondering about some sort of branch and bound strategy, and being able to set a suitable bound on the number of primes to consider.

Title: Re: Advent of Code
Post by: red marley on 22 December, 2016, 10:26:36 pm

Quote from: David Martin on 22 December, 2016, 09:27:11 pm

I do think that many of them are harder than this year.

We've still got three days to go yet.  :demon:

But I agree with you. The average completion time of the top 100 finishers last year was 26 min 50s; this year so far it has been 23 min 25s. One difference (which I like) is that the hardest questions this year (Day 11 lifts; Day 19 elf present stealing; Day 22 grid computing) have all had a trick/heuristic that makes the problem considerably easier to solve.

If you want a gentle clue for the present permutation problem from last year:

(click to show/hide)

subset sum problem

Title: Re: Advent of Code
Post by: red marley on 23 December, 2016, 06:42:15 am

Day 23  (more assembunny)

(click to show/hide)

Be careful what you wish for (although I did greatly enjoy today's challenge).

Quote from: jo on 12 December, 2016, 07:02:45 am

Day 12

I like the idea of having to construct higher level operations from the assembly language in order to solve the challenge. Addition as in your example, but also multiplication and exponention would probably be needed for an input that couldn't be processed in a practical time without optimisation.

Title: Re: Advent of Code
Post by: David Martin on 23 December, 2016, 08:59:40 am

(click to show/hide)

It took me a bit of sitting down with pen and paper to work out what the program was doing.

(click to show/hide)

Calculating factorial eggs and then adding another number to it

Solved without code (OK, I did implement it but it would still be running)

Title: Re: Advent of Code
Post by: red marley on 23 December, 2016, 02:56:14 pm

(click to show/hide)

For me, the satisfaction is in providing a coded (and therefore more generalisable) solution rather than finding the answer itself. The answer is merely a way of testing the coding.

I also get some satisfaction in moving from an initial naive solution to one that it greatly optimised (by orders of magnitude rather than tinkering with a few percent increase in speed). Today's was a good example:

Initial assembunny code from Day 12 applied to Day 23 took 21 minutes to compute the part 2 answer.
Introducing an 'add' command: took 11 minutes to compute the part 2 answer.
Introducing a 'multiply' command: took 0.06 seconds to compute the part 2 answer.

Title: Re: Advent of Code
Post by: David Martin on 23 December, 2016, 04:58:40 pm

Did you put that into the program to generalise from any set of instructions? I had thought about trying that but didn't have time. The challenge means different things to different folks.

Title: Re: Advent of Code
Post by: Ben T on 23 December, 2016, 06:07:59 pm

I haven't found a programmatic solution to day 22 or day 23 that will work with anybody's input.

Day 22 is a perfect example of something a human is good at solving based on what they see visually but a computer isn't.

(click to show/hide)

When the 'gap' has to move round the wall, the best path starts off with it actually getting further from the goal data.

With my 'optimized' brute force solution, my outputted visualizations showed it heading towards the wall, getting to it very quickly, but on reaching it, getting 'stuck' in the corner between the 'wall' of big disks and the edge of the matrix. It then just meandered around, as my algorithm had no way of deciding that bouncing off the 'wall' was then actually in a much worse position than having initially headed away from the goal but towards the gap in the wall.
It's not that the algorithm doesn't know where the wall is, it doesn't even know there even IS a wall. Maybe if I could make the assumption that there's a wall, and therefore the best path might actually start going away from the goal, I could maybe use some fuzzy logic to detect the 'bouncing off the wall' phenomenon, it might find the best path. Maybe something along the lines of 'is it impossible to carry on going in any direction without rotating at least 90 degrees'.

 Day 23,

(click to show/hide)

I found it hard to spot the repeating patterns visually let alone programmatically.

Title: Re: Advent of Code
Post by: red marley on 23 December, 2016, 06:33:58 pm

Quote from: Ben T on 23 December, 2016, 06:07:59 pm

I haven't found a programmatic solution to day 22 or day 23 that will work with anybody's input.

Day 22 is a perfect example of something a human is good at solving based on what they see visually but a computer isn't.

(click to show/hide)

When the 'gap' has to move round the wall, the best path starts off with it actually getting further from the goal data.

With my 'optimized' brute force solution, my outputted visualizations showed it heading towards the wall, getting to it very quickly, but on reaching it, getting 'stuck' in the corner between the 'wall' of big disks and the edge of the matrix. It then just meandered around, as my algorithm had no way of deciding that bouncing off the 'wall' was then actually in a much worse position than having initially headed away from the goal but towards the gap in the wall.
It's not that the algorithm doesn't know where the wall is, it doesn't even know there even IS a wall. Maybe if I could make the assumption that there's a wall, and therefore the best path might actually start going away from the goal, I could maybe use some fuzzy logic to detect the 'bouncing off the wall' phenomenon, it might find the best path. Maybe something along the lines of 'is it impossible to carry on going in any direction without rotating at least 90 degrees'.

(click to show/hide)

The shortest path involves no self-crossing lines, so simply keep track of visited locations and make sure your pathfinder can only move to unvisited ones. That should soon rule out dead ends and force the search temporarily to move away from the direct line to the corner.

Title: Re: Advent of Code
Post by: David Martin on 23 December, 2016, 10:27:44 pm

Quote from: jo on 23 December, 2016, 06:33:58 pm

Quote from: Ben T on 23 December, 2016, 06:07:59 pm

I haven't found a programmatic solution to day 22 or day 23 that will work with anybody's input.

Day 22 is a perfect example of something a human is good at solving based on what they see visually but a computer isn't.

(click to show/hide)

When the 'gap' has to move round the wall, the best path starts off with it actually getting further from the goal data.

With my 'optimized' brute force solution, my outputted visualizations showed it heading towards the wall, getting to it very quickly, but on reaching it, getting 'stuck' in the corner between the 'wall' of big disks and the edge of the matrix. It then just meandered around, as my algorithm had no way of deciding that bouncing off the 'wall' was then actually in a much worse position than having initially headed away from the goal but towards the gap in the wall.
It's not that the algorithm doesn't know where the wall is, it doesn't even know there even IS a wall. Maybe if I could make the assumption that there's a wall, and therefore the best path might actually start going away from the goal, I could maybe use some fuzzy logic to detect the 'bouncing off the wall' phenomenon, it might find the best path. Maybe something along the lines of 'is it impossible to carry on going in any direction without rotating at least 90 degrees'.

(click to show/hide)

The shortest path involves no self-crossing lines, so simply keep track of visited locations and make sure your pathfinder can only move to unvisited ones. That should soon rule out dead ends and force the search temporarily to move away from the direct line to the corner.

(click to show/hide)

That depends on what you mean by self crossing lines. If you are talking about the route of the gap then that is explicitly not true as my optimal route crossed itself every step of the desired data towards the goal. For an individual data block it may be true but I haven't checked that.

Title: Re: Advent of Code
Post by: Oaky on 23 December, 2016, 10:35:18 pm

(click to show/hide)

I left my unoptimised VM running the code for part 2 while I stared at the assembunny code trying to work out what it did.

By the time I had a prototype translation of it into python running, the original had completed anyway

Title: Re: Advent of Code
Post by: David Martin on 24 December, 2016, 09:23:23 am

Day 24: A bigger challenge

(click to show/hide)

Looks interesting. I will attempt this later but plan to follow this strategy:

(click to show/hide)

1. Build a graph network of all points . and numbers in the chart.
2. Find minimum spanning distance between each pair of numbers.
3. Use minimum spanning distance to solve the travelling salesman problem.

Seems reasonable but it hasn't seen contact with the enemy yet.

Title: Re: Advent of Code
Post by: Oaky on 24 December, 2016, 10:08:33 am

(click to show/hide)

Time to dust off the breadth-first search, with a twist...

(click to show/hide)

Need to do pairwise distances and reduce it to a travelling salesman problem otherwise the search space goes crazy

Title: Re: Advent of Code
Post by: red marley on 24 December, 2016, 01:02:10 pm

Oh dear - some stupid mistakes cost me plenty of time which meant with other Christmas stuff going on, I had to leave it a while before resuming.

(click to show/hide)

My initial attempt was to try to find the shortest path through all 7 locations in one go. I recognised it as a possible Travelling Salesperson Problem but thought with only 7 nodes, it could be computed through brute force.

For some stupid reason I thought it sensible to keep track of visited locations with a single 8 bit number holding  the visited status of the search for each of the 7 locations. While this is possible, there's no real saving over resetting the visited flag after each node is found. What it did do was mask a stupid problem in my breadth first search that I failed to spot.

To speed up my search I added a cost function to to the BFS so it prioritised moving towards the goal node. I think in practice this doesn't make much difference as the maze is pretty constrained and the shortest paths can be quite convoluted. What it did do was further mask the problem with my BFS search.

I eventually realised it was more efficient to just compute the shortest path between all pairs of nodes then find the minimum sum of each permutation of the 7 node pairs. This certainly sped up computation time (a fraction of a second rather than a few minutes), but I nevertheless still arrived at a credible but incorrect total for number of steps.

It worked on the test case but was consistently coming up with a path that was a little too long. It was only when I built a slightly more complex test case that I realised long paths were blocking of subsequent shorter candidates and I corrected the bug in my BFS. It then generated the answer in less than a second. Part 2 was a trivial case of adding the start node to the end of the list of 7 permuted nodes.

Lessons learned:

KISS
If your tests are too simple, build some more with edge cases and greater variety
More haste, less speed.

Title: Re: Advent of Code
Post by: Ben T on 24 December, 2016, 02:26:10 pm

Quote from: jo on 23 December, 2016, 06:33:58 pm

Quote from: Ben T on 23 December, 2016, 06:07:59 pm

I haven't found a programmatic solution to day 22 or day 23 that will work with anybody's input.

Day 22 is a perfect example of something a human is good at solving based on what they see visually but a computer isn't.

(click to show/hide)

When the 'gap' has to move round the wall, the best path starts off with it actually getting further from the goal data.

With my 'optimized' brute force solution, my outputted visualizations showed it heading towards the wall, getting to it very quickly, but on reaching it, getting 'stuck' in the corner between the 'wall' of big disks and the edge of the matrix. It then just meandered around, as my algorithm had no way of deciding that bouncing off the 'wall' was then actually in a much worse position than having initially headed away from the goal but towards the gap in the wall.
It's not that the algorithm doesn't know where the wall is, it doesn't even know there even IS a wall. Maybe if I could make the assumption that there's a wall, and therefore the best path might actually start going away from the goal, I could maybe use some fuzzy logic to detect the 'bouncing off the wall' phenomenon, it might find the best path. Maybe something along the lines of 'is it impossible to carry on going in any direction without rotating at least 90 degrees'.

(click to show/hide)

The shortest path involves no self-crossing lines, so simply keep track of visited locations and make sure your pathfinder can only move to unvisited ones. That should soon rule out dead ends and force the search temporarily to move away from the direct line to the corner.

(click to show/hide)

Yeah but my algorithm did this:

(https://dl.dropboxusercontent.com/u/55634526/disks.png)

The empty space started off in the square marked green, and tried to take the most direct path to the goal (purple).
When it got 'stuck', it spent time buggering about in the corner of doom exploring all the locations that were, yes, still as yet unvisited, but still closer to the goal than the 'apex' (the left end of the wall). This buggering about seemed to waste sufficient time as for me to think the algorithm would not complete in reasonable time (minutes), unless I was being impatient and it would have suddenly 'snapped' towards the apex when the purple path had coloured in the whole corner.

(The light blue path is the optimum path that my algorithm is yet to find but that was obvious on manual visual inspection)

Title: Re: Advent of Code
Post by: Ben T on 24 December, 2016, 02:38:27 pm

(That woe is day 24 not day 23... ) but:

(click to show/hide)

Quote from: jo on 24 December, 2016, 01:02:10 pm

I eventually realised it was more efficient to just compute the shortest path between all pairs of nodes then find the minimum sum of each permutation of the 7 node pairs. This certainly sped up computation time (a fraction of a second rather than a few minutes), but I nevertheless still arrived at a credible but incorrect total for number of steps.

That is the best method. (Obviously including caching the distances between each pair.)

Asusming you only have 8 exposed wires to visit (0-7), like i did, there are only 28 different pairs to calculate the distance between so if it takes on average 5s (like mine does about) to calculate the distance between each pair then it still only takes about 2 minutes to pre-compute all the leg lengths.
There are only 5,040 possible distinct tours starting with 0 and once you have pre-cached all the leg lengths then calculating the whole tour length takes hardly any time at all.
In other words, the complexity of a TSP is O(n!), but O is only adding up 7 numbers, not doing routing.

The only slight gotcha for me but that I did realise from the start was that (using the A* algorithm) the shortest distance between each pair was not necessarily the first one found, so I had to sort first by number of steps then by distance to target.

Part 2 didn't add much - I thought he was going to make the problem asymmetrical (i.e., x->y != y->x

Title: Re: Advent of Code
Post by: red marley on 24 December, 2016, 02:38:53 pm

^--- (Ben's Day 22) Sure, but with a grid of only c. 30x30 or so cells, shouldn't it soon exhaust that bottom right corner and find a better route past the wall?

(click to show/hide)

Just keeping a single 'visited' grid with the current shortest number of steps required to get to each visited cell is enough to quickly exclude any longer paths.

Title: Re: Advent of Code
Post by: Ben T on 24 December, 2016, 02:42:27 pm

Quote from: jo on 24 December, 2016, 02:38:53 pm

^--- (Ben's Day 22) Sure, but with a grid of only c. 30x30 or so cells, shouldn't it soon exhaust that bottom right corner and find a better route past the wall?

(click to show/hide)

Just keeping a single 'visited' grid with the current shortest number of steps required to get to each visited cell is enough to quickly exclude any longer paths.

maybe, yeah - I'll revisit and try and find out why it doesn't. I think the reason may be that the hash is 'too unique', i.e. it cares (too much) about the position of actual data rather than just the position of the space.

Title: Re: Advent of Code
Post by: David Martin on 24 December, 2016, 03:35:02 pm

Hmm.. Just got back to this and I think my code is really inefficient compared to the times reported. Still running DFS (maybe BFS would be better?)

Title: Re: Advent of Code
Post by: Ben T on 24 December, 2016, 04:10:05 pm

Quote from: David Martin on 24 December, 2016, 03:35:02 pm

Hmm.. Just got back to this and I think my code is really inefficient compared to the times reported. Still running DFS (maybe BFS would be better?)

(click to show/hide)

Yes I think only BFS will work, because with DFS, once you find any solution, you still need to check all nodes up to that depth because there might be a better (shallower) one, so BFS means that the shallowest (shortest) target is found first.
DFS is the quickest way to find a solution to the length of any given leg (if it doesn't have to be the shortest), but it is not the quickest way to find the shortest.

Title: Re: Advent of Code
Post by: David Martin on 24 December, 2016, 04:19:29 pm

(click to show/hide)

I am now intimately aquainted with the joy of BFS vs DFS. And the complete code runs in less than a second.

Mistakes are good, if you learn from them.

Title: Re: Advent of Code
Post by: Ben T on 24 December, 2016, 05:40:46 pm

Less than a second including calc of leg lengths?? If so mine must be inefficient then as that takes about 5 seconds per leg. Only reason could be that it is plodding along one square at a time rather than going as far as possible with each movement. But optimizing probably unnecessary...

Title: Re: Advent of Code
Post by: David Martin on 24 December, 2016, 09:13:09 pm

(click to show/hide)

Nope, reads it in to a graph structure straight off then does a BFS starting from each node (that gives you all 7 distances, though you are measuring them all twice. The only condescension to optimisation is not to start at all points as the distances are symmetric so I skip one BFS and read the results from the other.

Code: [Select]

import itertools,functools
from queue import Queue
class Graphnode ():
    def __init__(self, name, x,y):
        self.name = name
        self.links=[]
        self.x=x
        self.y=y
        self.steps=None

    def addlink(self,node):
        self.links.append(node)

    def resetsteps(self):
        self.steps=None
        self.parent=None
       
    def __repr__(self):
        return 'Node {} at {} steps'.format(self.name, self.steps)
graph={}
points={}

data=[x.strip() for x in open('day24input.txt').readlines()]

stack =[]
# now build the graph
for y in range(len(data)):
    for x in range(len(data[y])):
        if data[y][x] != '#':
            name = 'N{}-{}'.format(x,y)
            node=graph.get(name)
            #print(name, node)
            if node==None:
                node=Graphnode(name, x,y)
                graph[name]=node
            if data[y][x] !='.':
                points[data[y][x]]=node
            if data[y][x+1] != '#':
                newname='N{}-{}'.format(x+1,y)
                linknode=graph.get(newname)
                if linknode is None:
                    linknode=Graphnode(newname, x+1,y)
                    graph[newname]=linknode
                linknode.addlink(node)
                node.addlink(linknode)
            if data[y+1][x] != '#':
                newname='N{}-{}'.format(x,y+1)
                linknode=graph.get(newname)
                if linknode is None:
                    linknode=Graphnode(newname, x,y+1)
                    graph[newname]=linknode
                linknode.addlink(node)
                node.addlink(linknode)

# now do exhaustive search for each pairwise distance.
distances ={}
for k in list(points.keys())[:-1]:
    distances[k]={}
    for n in graph.values():
        n.resetsteps()
       
    root = points[k]
    root.steps=0
    stack=Queue()
    stack.put(root)
    while not stack.empty():       
        current = stack.get()
        for  n in current.links:
            if n.steps is None:
                n.steps = current.steps + 1
                n.parent = current
                stack.put(n)
    for d in points.keys():
        distances[k][d] = points[d].steps
       
distances['2']={'2':0}     
for k in distances.keys():
     distances['2'][k]=distances[k]['2']

def distx(x):
    return sum( [distances[x[i]][x[i+1]] for i in range(len(x)-1)])

nodes = [str(x)for x in range(1,8)]

part1=functools.reduce(min,map(distx, [ ['0']+list(x) for x in itertools.permutations(nodes)]))
part2=functools.reduce(min,map(distx, [ ['0']+list(x)+['0'] for x in itertools.permutations(nodes)]))
print(part1,part2)
Python has really good optimisations for iterations and map/reduce so I am learning to use those.

Title: Re: Advent of Code
Post by: David Martin on 25 December, 2016, 12:22:19 pm

Today's is quite fun.

(click to show/hide)

It is quite enlightening seeing just how many operations it takes to do something simple. For those of a coding bent a hint is

(click to show/hide)

The multiply has been met before but the divide/modulo operation is new

(click to show/hide)

>> is what it is all about

(click to show/hide)

but the number you put in is not the signal, it completes the signal.

I quite enjoyed working out what the code was doing and then determining the input needed by hand rather than brute forcing it to calculate the answer. I will admit that implementing a compiler to simplify the task is beyond my current resources (time and ability).

Title: Re: Advent of Code
Post by: Ben T on 25 December, 2016, 01:22:42 pm

(click to show/hide)

var answer = Enumerable.Range(2550, Int16.MaxValue).First(s => Regex.IsMatch(Convert.ToString(s, 2), @"^(10)+$")) - 2550;

or slightly more terse but less calculation:

(click to show/hide)

var answer = Convert.ToInt32(Enumerable.Range(1, 10).Select(i => string.Join("", Enumerable.Repeat("10", i))).First(s => Convert.ToInt32(s, 2) > 2550), 2) - 2550;

Title: Re: Advent of Code
Post by: Pickled Onion on 26 December, 2016, 09:49:35 pm

Quote from: Ben T on 19 December, 2016, 10:51:12 am

day 19 part 1:

(click to show/hide)

int get_answer(int numElves)
{
   int hpt_pow = (int)log2(numElves);
   int hpt = pow(2, hpt_pow);
   int ans = (numElves - hpt) * 2 + 1;
   return ans;
}

I know I'm a bit behind the times (computer downtime). I liked this one too, it's clear there's an analytic solution - every second elf loses his presents. But the problem as presented looks like a queue, so I coded it in that spirit:

(click to show/hide)

while (scalar @elves > 1){
   push @elves, shift @elves;
   shift @elves;
}

Title: Re: Advent of Code
Post by: David Martin on 26 December, 2016, 09:51:47 pm

Very neat.

Title: Re: Advent of Code
Post by: Pickled Onion on 26 December, 2016, 10:30:58 pm

Thank you.  :)

Perl's lists/arrays are optimised for use as queues, so repeated push/pop/shift/unshift does not create a massive realloc fest. Unfortunately, removing an element from the middle is something else entirely, so part 2 in the same vein

(click to show/hide)

while (scalar @elves > 1){
   push @elves, shift @elves;
   splice @elves, int((scalar @elves)/2)-1, 1;
}

takes rather a long time...

Title: Re: Advent of Code
Post by: Ben T on 29 December, 2016, 03:51:17 pm

Withdrawal symptoms?
I've found this website https://projecteuler.net which offers a multitude of problems some of which appear to solvable by programming.
Some are quite interesting, e.g. this one https://projecteuler.net/problem=575 which I've managed to solve.
A lot seem very maths-heavy e.g. about sets of prime  numbers and the like, but they do appear to be simple from a brute force point of view but then you are asked from a number very high in the sequence, so either mathematical knowledge and/or heavy optimization or realizing some vast simplification is required.

Title: Re: Advent of Code
Post by: Oaky on 30 November, 2017, 12:46:51 pm

2017 AoC in about 16 hours time! :)

Title: Re: Advent of Code
Post by: Greenbank on 30 November, 2017, 01:17:00 pm

ooh, signed up

(And going back and doing 2016 as practice...)

Title: Re: Advent of Code
Post by: Diver300 on 30 November, 2017, 07:51:42 pm

Quote from: Oaky on 30 November, 2017, 12:46:51 pm

2017 AoC in about 16 hours time! :)

Arrgghhh!

December productivity will be at it's usual post 2015 levels.

Title: Re: Advent of Code
Post by: David Martin on 01 December, 2017, 12:03:08 am

That's the marking taking a back seat then.

Is there a YACF league?

Title: Re: Advent of Code
Post by: Croft on 01 December, 2017, 06:27:38 am

From previous years, the YACF leaderboard code is 48462-ea506236

Title: Re: Advent of Code
Post by: davelodwig on 01 December, 2017, 10:55:06 am

Enjoyed that, once I'd remembered to read the question properly.

Am using PHP just because that's what I happen to use daily.

D.

Title: Re: Advent of Code
Post by: Oaky on 01 December, 2017, 01:03:09 pm

I'm using Python again,  trying to use Pandas/numpy wherever possible.

(click to show/hide)

Today's turned into an easy application of np.roll()

Title: Re: Advent of Code
Post by: freeflow on 01 December, 2017, 03:03:31 pm

Done today's using VBA. Tomorrow I'll try python.

Title: Re: Advent of Code
Post by: David Martin on 01 December, 2017, 05:41:21 pm

Quote from: Oaky on 01 December, 2017, 01:03:09 pm

I'm using Python again,  trying to use Pandas/numpy wherever possible.

(click to show/hide)

Today's turned into an easy application of np.roll()

Interesting - I'd not seen that.
The second part is a special case

(click to show/hide)

You can do the first half (range(len(x)//2)) then double it because you are then matching the symmetrical pair.

Title: Re: Advent of Code
Post by: Pickled Onion on 01 December, 2017, 06:49:45 pm

Ah yes, well spotted. A language that supports negative array indices is hinted by part one, and helps for part 2.

58 keystrokes. Anyone manage fewer?

Title: Re: Advent of Code
Post by: Greenbank on 01 December, 2017, 08:18:00 pm

Quote from: Greenbank on 30 November, 2017, 01:17:00 pm

ooh, signed up

(And going back and doing 2016 as practice...)

2016 done, will move on to 2015 too.

Doing all of mine in Perl as that's what I use for quick hacks and prototypes.

Title: Re: Advent of Code
Post by: David Martin on 01 December, 2017, 09:09:44 pm

Quote from: Pickled Onion on 01 December, 2017, 06:49:45 pm

Ah yes, well spotted. A language that supports negative array indices is hinted by part one, and helps for part 2.

58 keystrokes. Anyone manage fewer?

I presume that is CTRL-C/CTRL-V to copy and paste the original data? And is that one part or both parts.
81 characters, but some are spaces.

Title: Re: Advent of Code
Post by: Pickled Onion on 01 December, 2017, 09:42:12 pm

ok, I didn't include the data or printing out the answer. Fully working solution is 64 characters for part 1 and 67 characters for part 2

(click to show/hide)

Code: [Select]

@a=split//,<>;map$s+=$a[$_],grep$a[$_-1]==$a[$_],0..@a-1;print$s
@a=split//,<>;map$s+=$a[$_],grep$a[$_-@a/2]==$a[$_],0..@a-1;print$s



Title: Re: Advent of Code
Post by: Greenbank on 02 December, 2017, 12:17:57 am

Quote from: Greenbank on 01 December, 2017, 08:18:00 pm

2016 done, will move on to 2015 too.

Doing all of mine in Perl as that's what I use for quick hacks and prototypes.

Ugh, enough for now, done up to (and including day 16 of 2015).

Title: Re: Advent of Code
Post by: Pickled Onion on 03 December, 2017, 11:40:50 am

It's started to get more interesting today. Only day 3, is this year going to be a tough one?

Out of interest, who are Phong and mTrak? I'm iakobski.

Title: Re: Advent of Code
Post by: David Martin on 03 December, 2017, 04:14:09 pm

That was painful. The first part was elementary maths - no code needed.
The second part I used a dynamic programming approach and promptly filled it so full of bugs it took a long time to wrangle out. Was there a more elegant way that I somehow missed?

(click to show/hide)

I cached previous results, only calculating the ones I needed.
Work out which square you are on and which piece in which side. Write all the edge cases for turning the corners and then iterate backwards and forwards till you hit the two numbers surrounding the input data.

Seems very hard for day 3.

Title: Re: Advent of Code
Post by: Pickled Onion on 03 December, 2017, 05:31:23 pm

That's the thing with a lot of these - if you short-circuit part 1, you find part 2 needs the data from part 1.

I built the whole grid in part 1, even though it was obvious there would be a clever way round that, so adding on a value to each point was trivial.

However my first attempt using recursion succeeded only in turning my laptop into a lap-heater, who knew that recursing several of hundreds deep on each point was not the best use of cpu cycles  :facepalm:

Title: Re: Advent of Code
Post by: Greenbank on 03 December, 2017, 06:47:56 pm

Quote from: Pickled Onion on 03 December, 2017, 05:31:23 pm

That's the thing with a lot of these - if you short-circuit part 1, you find part 2 needs the data from part 1.

Or if you don't short-circuit part 1 you find that part 2 involves computing something so big that it would take the naive algorithm years to finish so you do need to short-circuit it.

Most of the time (having just gone back and done the whole of 2016 and 2015 over the last few days) whatever I do in part (a) is usually the wrong one. I guess this is no coincidence.

Quote from: David Martin on 03 December, 2017, 04:14:09 pm

The second part I used a dynamic programming approach and promptly filled it so full of bugs it took a long time to wrangle out. Was there a more elegant way that I somehow missed?

2017.3.b spoiler:-

(click to show/hide)

It didn't need to use anything like that.

Initialise 0,0 to 1. Set direction to E(ast)
iterate:-
* move in direction (E = inc x, y stays the same)
* calc new value
* Is square to left (in terms of direction being travelled, if moving East then 'left' means North) of me unset? If so turn left...
* repeat

So you go E (to 1,0 and calc).
Square left of there (1,1) is unset so turn L (dir is now N).
Move N to (1,1 and calc).
Square left of there (0,1) is unset so turn L (dir is now W).
Move W to (0,1 and calc).
Square left of there (0,0) is already set so don't change dir (still W)
Move W to (-1,1 and calc).
Square left of there (-1,0) is unset so turn L (dir is now S).
...

For langs that don't allow arrays with negative indicies, just add a constant to both X and Y to shunt it up into +ve values always.

Title: Re: Advent of Code
Post by: Pickled Onion on 03 December, 2017, 07:08:48 pm

Quote from: Greenbank on 03 December, 2017, 06:47:56 pm

Quote from: Pickled Onion on 03 December, 2017, 05:31:23 pm

That's the thing with a lot of these - if you short-circuit part 1, you find part 2 needs the data from part 1.

Or if you don't short-circuit part 1 you find that part 2 involves computing something so big that it would take the naive algorithm years to finish so you do need to short-circuit it.

Most of the time (having just gone back and done the whole of 2016 and 2015 over the last few days) whatever I do in part (a) is usually the wrong one. I guess this is no coincidence.

Yes, that's what makes these so much fun. I can solve it this way... or that way... which way is going to help in part 2?

Title: Re: Advent of Code
Post by: David Martin on 03 December, 2017, 08:55:04 pm

I suppose I just had a function that mapped the 2D onto the 1D array and went from there. I went back and checked and despite the dynamic programming, I still calculated every value.

Title: Re: Advent of Code
Post by: Oaky on 03 December, 2017, 09:35:08 pm

Didn't get to doing today's until this evening owing to family visiting plus putting up the Christmas decorations.

(click to show/hide)

I used almost the same algorithm for constructing the path as Greenbank, except my condition for turning left was to turn if the new location had only 1 populated neighbour.

I used a Python dict() keyed by the coordinates in a tuple with the value being either the address count (part 1) or the sum of neighbours (part 2).  In part 1, for laziness, I also constructed the inverse dict at the same time to easily look up the coordinate of the input address after I'd populated the dict(s).

Title: Re: Advent of Code
Post by: Diver300 on 03 December, 2017, 11:13:57 pm

Quote from: Oaky on 03 December, 2017, 09:35:08 pm

(click to show/hide)

I used almost the same algorithm for constructing the path as Greenbank, except my condition for turning left was to turn if the new location had only 1 populated neighbour.

I used the same method.

(click to show/hide)

Because every square that is populated is greater than zero, it works to populate the entire array with zeros and use >0 as the condition for having been visited.

I did part one without programming, just a text editor for notes and a calculator.

BTW, I'm mtrak

Title: Re: Advent of Code
Post by: Greenbank on 04 December, 2017, 08:40:06 am

Was hoping for a meaty one today but no.

Still, I've got some of the older ones to revisit and make work more efficiently.

Title: Re: Advent of Code
Post by: Croft on 04 December, 2017, 10:23:15 am

I'm impressed you rattled though the 2015 and 2016 ones so quickly. I seem to recall the Isotope lifts problem, the Wizard Spells game and Medicine for Rudolph problems taking quite some effort.

Title: Re: Advent of Code
Post by: David Martin on 04 December, 2017, 10:54:46 am

Today's was very much a start of week 1 problem.

(click to show/hide)

The joy of having lists and unique sets, and for part two, mapping each word onto the word alphabetically sorted on parsing the line.

Title: Re: Advent of Code
Post by: Greenbank on 04 December, 2017, 11:05:33 am

isotope lift

(click to show/hide)

I spotted the isomorphism optimisation early (the fact that element names didn't affect whether you'd been in a particular state before or not, only the position of the generators and microchips) and so that helps minimise the search space.

wizard spells I spent a fair while on as I had an annoying bug (one of my effects lasted for the wrong number of turns) - when I finally sorted that I had also missed the fact that you had to cast an effect on every turn, and my code allowed nothing to be done on a turn (with my input you got a lower score if you did nothing on the last turn as the poison spell was still in effect)

Another reminder to READ THE DESCRIPTION PROPERLY!

medicine for rudolph : maybe I was lucky...

(click to show/hide)

I worked backwards (aiming to go from the big long string back to 'e') doing a depth first search trying the possible replacements in length order (longest first) and I almost instantly got an initial result that didn't seem to drop after 10 seconds of the program running (in situations like this I report each time it finds a new 'better' score) so tried that number for fun and it was the right answer. Haven't tried to leave the program running to see how long it takes to run (it's been 10 minutes so far and still hasn't finished), unsurprising as there's little protection for it going down blind alleys at the moment.

I did notice that (in my puzzle input at least) 3 elements only appeared on the RHS of the rules, and was going to exploit that next if that initial answer hadn't been correct. I don't know how many different combinations there are when those 3 elements have been removed, might go back to this in a bit. It might be one that's best attacked from both ends in order to meet in the middle.

This kind of challenge (as in AoC) is exactly my kind of thing though. I've been coding as a job for 20+ years and have degrees in both Comp Sci and Maths, I've also done many of the Valladolid Online Judge (https://uva.onlinejudge.org/) programming challenges too so many of the concepts I've covered before.

Title: Re: Advent of Code
Post by: Croft on 04 December, 2017, 11:20:04 am

Medicine for Rudolph (Day 19, 2015)

(click to show/hide)

It's worth spending a bit of time looking at the substitution rules as there are some properties that greatly reduce the number of computations required.

In fact:

(click to show/hide)

There is even a trivially simple algebraic solution for calculating the answer (i.e. no tree searching at all). This may have been an inadvertently exposed result of the problem generation algorithm.

Title: Re: Advent of Code
Post by: Oaky on 04 December, 2017, 11:58:23 am

Quote from: David Martin on 04 December, 2017, 10:54:46 am

Today's was very much a start of week 1 problem.

(click to show/hide)

The joy of having lists and unique sets, and for part two, mapping each word onto the word alphabetically sorted on parsing the line.

(click to show/hide)

Another problem very well suited to the strengths of the Python Pandas/numpy libraries.

Code: [Select]

import pandas as pd
import numpy as np

df = pd.concat(list(map(lambda x: pd.Series(x.strip().split()), open('input.txt').readlines())), axis=1)

print(f'part 1 answer {sum(~df.apply(lambda x: any(x.dropna().duplicated())))}')

df = df.applymap(lambda x: np.nan if x is np.nan else ''.join(sorted(x)))

print(f'part 2 answer {sum(~df.apply(lambda x: any(x.dropna().duplicated())))}')


Days 1, 2, and 4 solved with pandas so far.  Maybe I need to go back and think harder about how to do 3.

Title: Re: Advent of Code
Post by: David Martin on 04 December, 2017, 11:07:28 pm

My pandas fu is not that developed.

Title: Re: Advent of Code
Post by: Diver300 on 05 December, 2017, 06:38:14 am

Day 5 seemed quite straightforward.

(click to show/hide)

Only a spoiler in as much as it refers to part 2 question.

I first thought that 3 or more meant in either direction, so I solved the wrong problem and came up with tiny answer.

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2017, 07:51:57 am

At this point the private leaderboard is more about who gets up earliest than anything else. (7.30am is the earliest I'll ever be in front of a computer.)

(Not grumbling, the trickier problems will come...)

Title: Re: Advent of Code
Post by: David Martin on 05 December, 2017, 10:54:01 am

Indeed. I appear to be 4th up in the morning.

I was idly thinking on whether there was a trivial way to determine the result from the values in the steps. I am led to believe it is pretty close to an ideal turing machine and therefore you only know if it will stop when it does, so there is no way to know the number of interations from the instructions without playing them out.

Title: Re: Advent of Code
Post by: David Martin on 06 December, 2017, 07:35:37 am

For day 6, the brute force is obvious, but I was wondering whether there is a more elegant way to do it.

(click to show/hide)

Hash each combination with the number of steps to get to that hash. Makes both parts quite straightforward.

Title: Re: Advent of Code
Post by: Greenbank on 06 December, 2017, 08:07:03 am

Day 6:

(click to show/hide)

The hash is just a (very) handy container, without it you'd just be implementing your own storage and comparison function.

I'm tempted to reimplement this in C (where there is no native dictionary/hash/hashmap structure) and rather than implementing one of those I'd probably use a tree structure to store the data, for semi-fast comparisons.

[EDIT] Ugh, that wasn't particularly pleasant, but it's redone in C just for fun.

Title: Re: Advent of Code
Post by: David Martin on 06 December, 2017, 11:06:02 am

Day 6:

(click to show/hide)

I had a horrible feeling that for part b the valid combinations would include all rotations  so that having 1 2 3 4 would be seen as identical to 4 1 2 3  (which itself just walks backwards continuously around the loop - a glider in game of life terms). Fortunately it wasn't.

Title: Re: Advent of Code
Post by: Diver300 on 06 December, 2017, 04:16:30 pm

Day 6
The debugging output for my code had basically solved part 2 by the time that I had solved part 1

(click to show/hide)

I displayed the line numbers for the latest iteration and the one it matched. The answer to the second part was simply the difference.

Title: Re: Advent of Code
Post by: David Martin on 06 December, 2017, 05:00:15 pm

Quote from: Diver300 on 06 December, 2017, 04:16:30 pm

Day 6
The debugging output for my code had basically solved part 2 by the time that I had solved part 1

(click to show/hide)

I displayed the line numbers for the latest iteration and the one it matched. The answer to the second part was simply the difference.

very similar

(click to show/hide)

I stored the step number as the value of the hash so it was just a question of retrieving the last hash and the value it pointed to. And then to make an off by one error

Title: Re: Advent of Code
Post by: Oaky on 06 December, 2017, 05:10:38 pm

Quote from: David Martin on 06 December, 2017, 05:00:15 pm

Quote from: Diver300 on 06 December, 2017, 04:16:30 pm

Day 6
The debugging output for my code had basically solved part 2 by the time that I had solved part 1

(click to show/hide)

I displayed the line numbers for the latest iteration and the one it matched. The answer to the second part was simply the difference.

very similar

(click to show/hide)

I stored the step number as the value of the hash so it was just a question of retrieving the last hash and the value it pointed to. And then to make an off by one error

(click to show/hide)

I didn't store the step number, so rather than recode to do so, I added a method to my Memory() class to cycle on from the current value until it saw that hash again.  This works because the internal state of my machine is already in a value in the cycle when the part 1 code finishes.

I also added an automated test for the new method.

I then spent an age trying to work out why my cycle_length() method wasn't terminating on the test data, only to realise that in my test I had failed to do the "setup" step of solving Part 1 in the test object instance first, so it was waiting for the memory banks to return to the test case initial value, which isn't in the cycle so it never will :facepalm:

Title: Re: Advent of Code
Post by: Diver300 on 06 December, 2017, 08:16:45 pm

Quote from: David Martin on 06 December, 2017, 05:00:15 pm

Quote from: Diver300 on 06 December, 2017, 04:16:30 pm

Day 6
The debugging output for my code had basically solved part 2 by the time that I had solved part 1

(click to show/hide)

I displayed the line numbers for the latest iteration and the one it matched. The answer to the second part was simply the difference.

very similar

(click to show/hide)

I stored the step number as the value of the hash so it was just a question of retrieving the last hash and the value it pointed to. And then to make an off by one error

(click to show/hide)

I tried to save the previous iterations as an array of arrays, in Javascript, and failed miserably. Then I just stored the history as an array of text strings, with separators between numbers to differentiate between, for instance 11,2 and 1,12. Text string comparison is just == in Java script and this problem didn't need me to recover to numbers.

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2017, 07:54:45 am

That was a bit more satisfying.. Note: read the text more carefully.

Title: Re: Advent of Code
Post by: Greenbank on 07 December, 2017, 10:03:30 am

Indeed, that's a bit better.

It's the first one (of 2017) where I've had to write psuedo-code first and then flesh it out, rather than knowing what to do straight from the start.

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2017, 10:37:36 am

The pattern and approach was quite straightforward. Better if I read the instructions for part 2 and deliver what was asked. No need for pseudo code.

(click to show/hide)

Obviously a Directed Acyclic Graph, the question was how to store the details.
Then a recursive algorithm that spits out the key information when it finds the problem.

Title: Re: Advent of Code
Post by: Greenbank on 07 December, 2017, 11:41:07 am

Day 7:

(click to show/hide)

I overengineered my first attempt as I expected some caching to be required to avoid a lengthy execution.

I just thinned it down to a basic naive implementation (that only stores individual weight and parent name for each node) and recursively calculates everything else with no caching and it ran in under 2 seconds (the version that calculates total weights for each node and stores them runs instantaneously).

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2017, 01:21:28 pm

Quote from: Greenbank on 07 December, 2017, 11:41:07 am

Day 7:

(click to show/hide)

I overengineered my first attempt as I expected some caching to be required to avoid a lengthy execution.

I just thinned it down to a basic naive implementation (that only stores individual weight and parent name for each node) and recursively calculates everything else with no caching and it ran in under 2 seconds (the version that calculates total weights for each node and stores them runs instantaneously).

(click to show/hide)

No child node storage?
The first one required the parent nodes to be calculated. The second was a straightforward depth first search which requires knowing the child nodes (but not the parents)
I built the tree, then established how n-ary it was (distribution of number of children by node). This indicated the approach for the depth-first search. (check total masses of the children are equal, else squeal and report.)

Title: Re: Advent of Code
Post by: Greenbank on 07 December, 2017, 01:41:31 pm

Day 7:

Quote from: David Martin on 07 December, 2017, 01:21:28 pm

(click to show/hide)

No child node storage?
...

(click to show/hide)

For every node I was just keeping track of its weight and its parent, i.e.

B (8)
  weight(B)=8
D (20) -> A, B, C
  weight(D)=20 ; parent(A)=D ; parent(B)=D ; parent(C)=D
A (10)
  weight(A)=10
C (10)
  weight(C)=10

The answer to part (a) is simply the node that does not have a parent, trivial to find. It's doable in a command line for example:-

Code: [Select]

$ cat inp.simp | sed -e 's/ -> \(.*\)/ -> \1, \1/' -e 's/ ([0-9]*)//' -e 's/ -> /\n/' -e 's/, /\n/g' |  sort | uniq -u
tknk

You can find the children of a node (i.e. D) by searching all nodes that have it (D) as their parent. Avoids needing anything other than 1:1 mappings but is wasteful to loop through every node when you want to find a few children but since the input space was not too large it wasn't a problem. Likewise calculating the total weights of each of the children of the current node being searched, that involves lots of duplication along the branches that are unbalanced but, again, it wasn't a problem with the final input.

Since I do most of my day to day programming in C where there are no built-in 1-to-many data structures I often initially attempt solve problems using just 1:1 data structures where possible (caveat performance at scale), this was a good example of that. Performance (and programming) is way faster with a list structure (let alone dict/hash/etc), but it's fun to do things without those kinds of extras.

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2017, 01:47:42 pm

That reminds me of the reddit competition to find the most ridiculous way to test if a number was even or odd.
It is order(N) for every lookup, making it approach order (N^2) overall.

(click to show/hide)

By keeping the child references, the depth first search is easy.
node[n] = {parent:, children:, mass:, nodemass: }
Any randomly selected node will give you very rapidly the head node in log(N) time.
Then recursively calculate the node masses till you find the unbalanced one.

Title: Re: Advent of Code
Post by: Ben T on 07 December, 2017, 02:07:42 pm

did it in a probably over verbose OO way https://github.com/bjtaylor1/AoC2017/blob/day07part2/Day07/App.cs but didn't take long and was basically shot from the hip and didn't require any debugging to get right pretty much first time

Title: Re: Advent of Code
Post by: Greenbank on 07 December, 2017, 02:41:40 pm

Day 7:

(click to show/hide)

If you want some mostly uncommented perl then snigger away:-

http://www.greenbank.org/misc/aoc/2017_7.txt

(I'm generally aiming for the answer as quickly as possible, not aiming for well commented, understandable or easily maintained code.)

The children() function can be easily modified to use the non-optimised version that loops through every node to find the children.

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2017, 04:10:34 pm

OK, here is my python

(click to show/hide)

Code: [Select]

fh = open('Downloads/input7.txt')
for line in fh.readlines():
    f = line.strip().split()
    node = f[0]
    mass = int(f[1][1:-1])
    nodes[node] = nodes.get(node,{})
    nodes[node]['mass'] = mass
    if len(f)> 2:
        child = [c.replace(',','') for c in f[3:]]
        nodes[node]['children']= child
        for c in child:
            nodes[c] = nodes.get(c, {})
            nodes[c]['parent'] = node

n = list(nodes.keys())[0]
while nodes[n].get('parent', None ) != None:
    n = nodes[n]['parent']
   
print(n)
headnode=n

orders = {}
for n in nodes.keys():
    o = len(nodes[n].get('children',[]))
    orders[o]= orders.get(o,0)+1
print(orders)
       
def get_mass(n):
    childmasses = []
    kinder = nodes[n].get('children', [])
    for k in kinder:
        childmasses.append(get_mass(k))
    if  len(set(childmasses)) == 2:
        for k in kinder:
            print(n, k, nodes[k]['nodemass'], nodes[k]['mass'])       
    cm = 0
    if len(childmasses)>0:
        cm = sum(childmasses)
    nodes[n]['nodemass'] = cm+nodes[n]['mass']
    return nodes[n]['nodemass']
   
get_mass(headnode)



Title: Re: Advent of Code
Post by: David Martin on 07 December, 2017, 04:15:17 pm

Quote from: Greenbank on 07 December, 2017, 02:41:40 pm

Day 7:

(click to show/hide)

If you want some mostly uncommented perl then snigger away:-

http://www.greenbank.org/misc/aoc/2017_7.txt

(I'm generally aiming for the answer as quickly as possible, not aiming for well commented, understandable or easily maintained code.)

The children() function can be easily modified to use the non-optimised version that loops through every node to find the children.

can you not (instead of the two cases) do:
my @c = split /\W*/, $x
my $n = unshift @c
my $w = unshift @c
if @c {
unshift @c
foreach my $child (@c) { ...}

to save repeating the code for the assignment of the first two lines.

Title: Re: Advent of Code
Post by: Greenbank on 07 December, 2017, 05:20:46 pm

Quote from: David Martin on 07 December, 2017, 04:15:17 pm

can you not (instead of the two cases) do:

Almost certainly, but that file was pretty much the first thing that gave me the correct answer (whether it prints it explicitly like mine, or gives enough information to work out the answer like yours). I don't bother polishing it once I've submitted a correct answer. If I was going to use it for anything else in the future then I'd spend some time refactoring it and adding suitable comments. I'd also consider how it would handle much larger inputs.

The last thing I want to be doing is chasing bugs in the code that reads the input, so I've no problem with a bit of duplication there.

[EDIT] It's only when the problems start to get properly challenging that I will take more care on my programs. My goal is to get the answer as quickly as possible (and in a reasonable execution time). The competition is not really making me learn anything new (if you want that then the Valladolid Online Judge or Project Euler are much better).

Title: Re: Advent of Code
Post by: Pickled Onion on 07 December, 2017, 09:48:05 pm

My goodness I made a meal out of that one. Must remember to read the question properly  :facepalm:

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2017, 10:49:09 pm

Thanks for the links to Project Euler and the Valladolid Judge sites. Interesting challenges though the sites are not terribly clear on how they work.

Title: Re: Advent of Code
Post by: Greenbank on 07 December, 2017, 10:58:36 pm

Valladolid was submit your code by email (at least when I was doing it back in 2001!). The automated system then sanitised it (to make sure you weren't doing anything silly or destructive) and then ran the code against an unseen input.

Their trick was the example inputs you got given on the website were a fraction of the size of the real input (which you never saw), or the real input was the pathological case for the standard algorithm.

So many times I'd be confident about my code, email it off, only to receive a "Time Limit Exceeded" response.

Can't remember much about Project Euler, only did one or two but I discussed a lot of the problems with someone from work I was mentoring.

Day 8: Will it be another fake CPU question (I do like them) or something like a knapsack or another TSP-esque classic?

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2017, 11:06:44 pm

We have had the first tree traversal one. Must be some magic codes to parse (medicine for rudolf). Still in early days so shouldn't be too taxing (hostage to fortune there).

Title: Re: Advent of Code
Post by: Diver300 on 07 December, 2017, 11:11:19 pm

Day 7
Solved with a spreadsheet. It did get quite big but not as large as many I written that have a more serious purpose.

Title: Re: Advent of Code
Post by: David Martin on 07 December, 2017, 11:34:22 pm

I cannot imagine voluntarily choosing to do it that way. It makes me cringe even thinking about it.

Title: Re: Advent of Code
Post by: Oaky on 07 December, 2017, 11:50:43 pm

Day 7 p2 is still not done.

RL has got in the way -- I can see two ways of attacking it, both of which should work, but haven had the time yet to give either a go.

(click to show/hide)

one is recursive, and one isn't.

I've learned from older AoC (but especially from the Synacor challenge) to be wary of jumping in with the obvious recursive solution in a language with insufficient stack limits, but looking at the longest path in the tree (which is, nicely, a directed acyclic graph), it seems that recursion here should be more than safe)

Title: Re: Advent of Code
Post by: David Martin on 08 December, 2017, 12:01:05 am

Recursion works when recursion works.
What is the non-recursive approach?

Title: Re: Advent of Code
Post by: Diver300 on 08 December, 2017, 06:18:02 am

Quote from: David Martin on 07 December, 2017, 11:34:22 pm

I cannot imagine voluntarily choosing to do it that way. It makes me cringe even thinking about it.

There towers are only 6 levels high, so finding a group of formulas that works, and copying across until there are no more sub-towers doesn't take long
The spreadsheet was 6000 lines long, as each step ended up at 9 lines. In retrospect 10 would have been easier on the brain.

Title: Re: Advent of Code
Post by: Diver300 on 08 December, 2017, 06:20:41 am

Day 8 didn't seem all that difficult.

(click to show/hide)

Transpose into Javascript. Add a line for each step to get the maximum.

Title: Re: Advent of Code
Post by: David Martin on 08 December, 2017, 07:41:36 am

Pretty much

(click to show/hide)

With python (and perl) you can store references to functions in hashes so I just put the symbols in as keys. There is a more OO approach but this morning ICBA.

Title: Re: Advent of Code
Post by: Greenbank on 08 December, 2017, 09:38:23 am

Day 8:

Quote from: Diver300 on 08 December, 2017, 06:20:41 am

(click to show/hide)

Transpose...

(click to show/hide)

ooh, what a horrid idea...

Part a:-

Code: [Select]

cat inp.simp | ( sed -e 's/^/$r{/' -e 's/ inc /}+=/' -e 's/ dec /}-=/' -e 's/ if \([a-z]*\)/ if $r{\1}/' -e 's/ if ([a-z]+)/ if $r{&}/' -e 's/$/;/' ; echo "@a=sort { \$b <=> \$a } values %r;print \@\$a[0]\n\";" ) | perl
10

Part b:-

Code: [Select]

cat inp.simp | ( echo "\$l=-9999999999;" ; sed -e 's/^/$r{/' -e 's/ inc /}+=/' -e 's/ dec /}-=/' -e 's/ if \([a-z]*\)/ if $r{\1}/' -e 's/ if ([a-z]+)/ if $r{&}/' -e 's/$/;/' -e 's/^\(\$r{[a-z]*}\).*$/&; \$l=\1 if( \1 > \$l );/' ; echo "print \"\$l\n\";" ) | perl
10


Title: Re: Advent of Code
Post by: Ben T on 08 December, 2017, 10:53:29 am

self contained dynamic compilation https://github.com/bjtaylor1/AoC2017/blob/day08part2/Day08/Program.cs
essentially the same, my TranslateCode function is your line of sed and my main function is orchestrating the running of it.

Title: Re: Advent of Code
Post by: Greenbank on 08 December, 2017, 02:00:05 pm

Quote from: Greenbank on 07 December, 2017, 10:58:36 pm

Day 8: Will it be another fake CPU question (I do like them) or something like a knapsack or another TSP-esque classic?

And, lo, it was a fake CPU type question.

I wrote an interpreter for my solution before doing the above horrific command line transpose nonsense.

Will we get a couple of biggies to do over the weekend? I hope so!

Title: Re: Advent of Code
Post by: Oaky on 08 December, 2017, 04:08:02 pm

Finally got round to doing day 7 part 2.  (after knocking out day 8 )

(click to show/hide)

networkx FTW!

Since it is a DAG, nx.descendents() comes in very handy.

(click to show/hide)

I decided to make my interpreter a little more general than was strictly necessary for the description/input program that I had.

whereas the test data (and my input, as far as a quick visual scan of it can tell) is always of the pattern

<register1> <operation> <integer1> if <register2> <comparator> <integer2>

I coded as if <integer1>, <integer2> and <register2> could all be either integers OR registers. (essentially,  I first try to feed them through int() and only if that throws an exception do I treat them as register names)

(click to show/hide)

Title: Re: Advent of Code
Post by: Ben T on 08 December, 2017, 04:42:47 pm

Quote from: Oaky on 08 December, 2017, 04:08:02 pm

(click to show/hide)

Quote from: Oaky on 08 December, 2017, 04:08:02 pm

I coded as if <integer1>, <integer2> and <register2> could all be either integers OR registers. (essentially,  I first try to feed them through int() and only if that throws an exception do I treat them as register names)

I thought that was what the difference between parts 1 and 2 was going to be, but decided not to pre-empt, and it wasn't.

Title: Re: Advent of Code
Post by: Greenbank on 09 December, 2017, 01:08:39 am

Hoping to sober up enough to be able to do Day 9 tomorrow today.

Hic.

I foresee much keyboard thrashing and grumpiness...

Title: Re: Advent of Code
Post by: Ben T on 09 December, 2017, 10:16:07 am

nothing taxing as long as you don't try and be too fancy.

Title: Re: Advent of Code
Post by: Greenbank on 09 December, 2017, 11:06:57 am

I've written enough stuff that parses input (specifically SQL and CSV) to understand the joy of string parsing with escape characters. Even with a slightly foggy brain from a mild hangover.

(click to show/hide)

I guessed that the garbage characters were going to be significant so part (b) was a simple addition of a counter increment in the appropriate bit of the pre-parser.

Did the parsing in two stages, one to clean the input stream and count the garbage, then a second one to parse the garbage free input into the groups, then a recursive function to score it all.

I'm secretly hoping that someone attempts this with a regex and eventually learns the lesson about regular expressions and context-free grammars. Brings back happy memories of university lectures about the Church-Turing thesis and the Pumping Lemma.

I love state machines; my Comp Sci dissertation was on the use of (non-)deterministic finite state automata in regular expression engines.

Title: Re: Advent of Code
Post by: Manotea on 09 December, 2017, 11:42:40 am

Inspired by Greenbank, I started reading this (https://www.gamedev.net/articles/programming/general-and-gameplay-programming/finite-state-machines-and-regular-expressions-r3176/)

Then realised I had something else to do today.  :)

Title: Re: Advent of Code
Post by: Ben T on 09 December, 2017, 01:54:14 pm

Quote from: Greenbank on 09 December, 2017, 11:06:57 am

I've written enough stuff that parses input (specifically SQL and CSV) to understand the joy of string parsing with escape characters. Even with a slightly foggy brain from a mild hangover.

(click to show/hide)

I guessed that the garbage characters were going to be significant so part (b) was a simple addition of a counter increment in the appropriate bit of the pre-parser.

Did the parsing in two stages, one to clean the input stream and count the garbage, then a second one to parse the garbage free input into the groups, then a recursive function to score it all.

I'm secretly hoping that someone attempts this with a regex and eventually learns the lesson about regular expressions and context-free grammars. Brings back happy memories of university lectures about the Church-Turing thesis and the Pumping Lemma.

I love state machines; my Comp Sci dissertation was on the use of (non-)deterministic finite state automata in regular expression engines.

I'm reasonably au fait with regex but wouldn't attempt to use it to try and count group nesting.... I didn't see any need for recursion but whether it could have made it more elegant I don't know. Mine's a fairly simple literal interpretation of the logic as described https://github.com/bjtaylor1/AoC2017/blob/day09part2/Day09/Program.cs
nothing wrong with recursion if you just like it though :)

Title: Re: Advent of Code
Post by: Pickled Onion on 09 December, 2017, 03:23:24 pm

Quote from: Greenbank on 09 December, 2017, 11:06:57 am

...then a second one to parse the garbage free input into the groups, then a recursive function to score it all.

The input was well-formed enough that it only required counting the { up and } down

Quote

I'm secretly hoping that someone attempts this with a regex and eventually learns the lesson about regular expressions and context-free grammars.

This particular one would be fairly straightforward with a regex, but yes it's the perennial question "how do I parse **ML with a regex?" A: DON'T!!

For a laugh I solved this (https://www.gchq.gov.uk/news-article/christmas-card-cryptographic-twist-charity) using regular expressions, it took rather longer to code than doing it with a pencil but the result was quite impressive nonetheless.

Title: Re: Advent of Code
Post by: David Martin on 09 December, 2017, 04:02:32 pm

Just plough through and process it as a stream.

(click to show/hide)

Set your initial state. 0 group score, not in garbage.
If the character being evaluated is ! skip the next character.
else, if in garbage, garbage ends or +1
else if { levels go up , add levels to score
else if } levels go down
else nothing
step on to the next character.
 
One pass. I thought it might get more interesting.
My code and input is at https://github.com/davidmam/aoc2017

I did come across an interesting puzzle that was easily solved to a certain state with matrix algebra. I then have to sort a matrix to get the minimum diagonal to get the appropriate order of rows.

Title: Re: Advent of Code
Post by: Oaky on 09 December, 2017, 04:49:26 pm

Quote from: David Martin on 09 December, 2017, 04:02:32 pm

Just plough through and process it as a stream.

(click to show/hide)

Set your initial state. 0 group score, not in garbage.
If the character being evaluated is ! skip the next character.
else, if in garbage, garbage ends or +1
else if { levels go up , add levels to score
else if } levels go down
else nothing
step on to the next character.
 
One pass. I thought it might get more interesting.
My code and input is at https://github.com/davidmam/aoc2017

I did come across an interesting puzzle that was easily solved to a certain state with matrix algebra. I then have to sort a matrix to get the minimum diagonal to get the appropriate order of rows.

I don't think you pushed your day 9 changes to github yet ;)

(click to show/hide)

I also built a very similar state machine.

I decided from the off that garbage and/or cancelled characters might be significant, so I counted them anyway.

When part 2 was revealed, I just had to slightly adjust my counting rules to match the ones asked for (actually it wasn't strictly necessary as it could be calculated trivially from thecounts I was returning anyway)

https://github.com/MarkNOakden/AdventOfCode/tree/master/17/09

Title: Re: Advent of Code
Post by: David Martin on 09 December, 2017, 07:14:02 pm

Good spot. Didn't tick the 'push to origin automatically' box in Sourcetree.

Title: Re: Advent of Code
Post by: Oaky on 09 December, 2017, 08:40:38 pm

(click to show/hide)

I realised when reading this:-

https://www.reddit.com/r/adventofcode/comments/7ild5h/2017_day_9_switching_it_up_at_compiletime/

that I didn't read the spec closely enough (not in a way that changes the potential answer to either part of the question, given that the input is well-formed wrt the actual rules (and not those I thought were in place)).

I was looking at the reddit solution and thinking "it doesn't allow for ! cancels except in garbage: what about situations with e.g. "{!<<<<>}" - won't it count those incorrectly?".

It's only going back to the spec in the question that I realised that "!" is described as only appearing within garbage.  :facepalm:

Title: Re: Advent of Code
Post by: Diver300 on 10 December, 2017, 06:27:17 am

The instructions for day 10 almost lead you though the programming steps needed. It reads more like a lesson in computing than a puzzle.

Title: Re: Advent of Code
Post by: David Martin on 10 December, 2017, 08:59:01 am

Agreed. Involved but not hard. Bleary eyed typos notwithstanding. Not sure I have the oomph in the morning to test-suite it. I'd have sorted the tests after finding the things that needed to be tested, by which time they would be unnecessary.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2017, 07:20:21 am

Ouch - my head hurts a bit after trying to sort that one out. Probably an inelegant solution to calculate the total number of steps. I'm sure there must be a better way to resolve the axes than a series of if/else looking at the relevant cases. Possibly something matrixy but my brain isn't functioning.

Title: Re: Advent of Code
Post by: Croft on 11 December, 2017, 07:37:02 am

Day 11

(click to show/hide)

David Martin, you can simply convert each movement into a 3-axis vector:


         x   y   z
N  -> (  0,  1,  1 )
NE -> (  1,  1,  0 )
SE -> (  1,  0, -1 )
S  -> (  0, -1, -1 )
SW -> ( -1, -1,  0 )
NW -> ( -1,  0,  1 )

Then distance is just Σ(abs(x_i) + abs(y_i) + abs(z_i)) / 2

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2017, 10:14:45 am

(click to show/hide)

Couldn't remember the details of the 3D co-ordinate solution (and am trying to do this from memory and not using google) so did it with a 2D co-ordinate system and a single if/else in the function to calculate the number of moves.

Title: Re: Advent of Code
Post by: Croft on 11 December, 2017, 10:41:34 am

Day 11

(click to show/hide)

I don't think it requires memory or Google. Just sketching it out on paper using some grid lines at 60^o is enough to work out the fairly simple rules for moving in hex space.

Title: Re: Advent of Code
Post by: Oaky on 11 December, 2017, 11:15:05 am

(click to show/hide)

I did this one using pandas again.

I used a 2D coord rep where the origin is at (0, 0) with the neighbours being at

n - (0, 2)
ne - (1, 1)
se - (1, -1)
s - (0, -2)

etc...

the step distance from any point was calculated conceptually by going diagonally in the appropriate direction until either x or y is zero, then adding either the x coord or half the y coord of where you cross the axis.

in practice,  you don't have to care ehat the direction is as the steps are symmetric in the axes, so you can use abs() to map the resulting coordinate into the NE quadrant and work the steps out from there.  the distance to one of the axes is now the smallest coordinate and the remaining steps are either the x-y if x-y is positive or -(x-y)/2 if x-y is negative (or 0 if x=y).

Here's what my path looks like:-

(https://github.com/MarkNOakden/AdventOfCode/raw/master/17/11/subprogram_path.png)

https://github.com/MarkNOakden/AdventOfCode/blob/master/17/11/day11.ipynb

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2017, 12:25:55 pm

Quote from: Croft on 11 December, 2017, 07:37:02 am

Day 11

(click to show/hide)

David Martin, you can simply convert each movement into a 3-axis vector:


         x   y   z
N  -> (  0,  1,  1 )
NE -> (  1,  1,  0 )
SE -> (  1,  0, -1 )
S  -> (  0, -1, -1 )
SW -> ( -1, -1,  0 )
NW -> ( -1,  0,  1 )

Then distance is just Σ(abs(x_i) + abs(y_i) + abs(z_i)) / 2

I must admit that trying to sort that at early morning after dealing with a frozen pipe leading to a major water leak in the house was challenging enough - I thought it should be able to be done something like that. Instead I did it the hard way.

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2017, 12:59:04 pm

Quote from: Croft on 11 December, 2017, 07:37:02 am

Day 11

(click to show/hide)

David Martin, you can simply convert each movement into a 3-axis vector:


         x   y   z
N  -> (  0,  1,  1 )
NE -> (  1,  1,  0 )
SE -> (  1,  0, -1 )
S  -> (  0, -1, -1 )
SW -> ( -1, -1,  0 )
NW -> ( -1,  0,  1 )

Then distance is just Σ(abs(x_i) + abs(y_i) + abs(z_i)) / 2

I am struggling to see how you come up with that matrix.

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2017, 01:45:59 pm

(click to show/hide)

(https://i.imgur.com/AJoDm.gif)

although you'll need to rotate it for this challenge

Title: Re: Advent of Code
Post by: Croft on 11 December, 2017, 01:47:29 pm

Greenbank beat me to it, but..

(click to show/hide)

Just sketch it out and count which axes you cross as you move in each of the 6 directions:

(https://i.imgur.com/pVwYfLg.png)

Title: Re: Advent of Code
Post by: David Martin on 11 December, 2017, 03:33:59 pm

Doh! I was looking at steps but not in the right directions.

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2017, 08:22:17 pm

(click to show/hide)

Quote from: David Martin on 11 December, 2017, 03:33:59 pm

Doh! I was looking at steps but not in the right directions.

That's what I did (since I couldn't remember it clearly enough), and when I couldn't figure it out in 20 seconds or so I gave up and continued with a 2D approach using N=[0,-1], NE=[1,-0.5], SE=[1,0.5], and then similar calculations as Oaky above.

At the time I'm not interested in the perfect solution, I'm (personally) only interested in doing it quickly and without looking anything up. Other approaches are available. But afterwards it is interesting to see the other (often better) approaches.

Title: Re: Advent of Code
Post by: Greenbank on 12 December, 2017, 07:45:31 am

Underwhelming today...

Jo's graphs seem to back up my suspicion that 2017 (so far at least) is quite a bit easier than the previous years: https://github.com/jwoLondon/adventOfCode

Title: Re: Advent of Code
Post by: Oaky on 12 December, 2017, 08:22:59 am

(click to show/hide)

It felt like cheating using the networkx library today.

Didn't stop me, though.  Gotta get those quick answers in where you can! :)

I'll probably revisit later on today and do it in pure python.

Title: Re: Advent of Code
Post by: Ben T on 12 December, 2017, 09:01:31 am

Quote from: Greenbank on 11 December, 2017, 08:22:17 pm

(click to show/hide)

Quote from: David Martin on 11 December, 2017, 03:33:59 pm

Doh! I was looking at steps but not in the right directions.

That's what I did (since I couldn't remember it clearly enough), and when I couldn't figure it out in 20 seconds or so I gave up and continued with a 2D approach using N=[0,-1], NE=[1,-0.5], SE=[1,0.5], and then similar calculations as Oaky above.

At the time I'm not interested in the perfect solution, I'm (personally) only interested in doing it quickly and without looking anything up. Other approaches are available. But afterwards it is interesting to see the other (often better) approaches.

I'm far too thick to think up any 3D solution so just did it in 2D and for part 1 did a BFS that worked fine and ran in under a second.
But for part 2 I firstly assumed incorrectly that the furthest away in 2D distance (the geographical furthest) would have the furthest number of steps, in fact it didn't.
I knew that the max steps (the answer) couldn't be much more than the number of steps for geographical furthest, but didn't want to keep guessing.
So I simply optimized it by factorizing the hexagons and only considering moves outside a minimum radius inside which they couldn't possibly take as many steps as the geographical furthest.
Still takes about a minute though. https://github.com/bjtaylor1/AoC2017/blob/day11part2b/Day11/Program.cs   :facepalm:
Quite good though, first reasonably difficult one.

Title: Re: Advent of Code
Post by: David Martin on 12 December, 2017, 09:32:08 am

Today was straightforward.

(click to show/hide)

I should look at the networkx module but there is some merit in working through from the ground up. Maybe I should spit out the necessary format for gephi or cytoscape and view the hairballs.
[/source]

Title: Re: Advent of Code
Post by: Oaky on 12 December, 2017, 01:57:06 pm

Quote from: David Martin on 12 December, 2017, 09:32:08 am

Today was straightforward.

(click to show/hide)

I should look at the networkx module but there is some merit in working through from the ground up. Maybe I should spit out the necessary format for gephi or cytoscape and view the hairballs.

(click to show/hide)

Using networkx and matplotlib.
The large green nodes are the graph containing node 0 and the red node is node 0 itself.
(http://www.oakden.org/mark/bike/yacf/pics/AdventOfCode17/day12.png)

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2017, 02:30:07 am

Slowly doing the Anti-AoC:-

How close to 5am (UK time) can I still be up but with no chance of being up to 5am to attempt the challenge (let alone be sober enough!)

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2017, 08:35:19 am

Today: I've done part 1 but part 2 will have to wait till I get home as I have too much marking to do. I recognize the problem but can't remember the elegant solution

(click to show/hide)

Each sentry maps onto a disk with diameter 2(n-1) where n is the range of the sentry.
This is the 'drop a ball through the disks' puzzle. It is a factorization one but I can't remember how to do it and haven't had time (or coffee enough) to work it out.
I'm not going to look it up - will sort it when I get home.
Brute force is not accessible for this.

Title: Re: Advent of Code
Post by: Ben T on 13 December, 2017, 10:07:13 am

day 12 quite easy going from part 1 to 2 https://github.com/bjtaylor1/AoC2017/compare/day12part1...day12part2

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2017, 01:16:06 pm

My simple naive brute force version took just under 20 seconds for day 13 part b.

(click to show/hide)

Will reimplement it properly using linear algrebra a bit later.

It's not quite the same as the 'drop a ball through the disks' puzzle (which was the Chinese-Remainder-Theorem) as that was looking for a number that satisfied a series of relations of the form: x % y = n.

This problem is about finding a number that satisfies a series of relations of the form x % y != n although I'm guessing that the possible elements in each Galois field are thinned out by multiple relations against the same field size, in which case it may come down to the CRT after all.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2017, 06:33:00 pm

I've kind of worked out how I want to do part 2 but am currently shattered so will pick it up after a wee pause.

(click to show/hide)

There is some ugly kludging with bitmasks that can be done. I'm still seeking an elegant solution, the sticking point being the not falling through holes.
Each disc of a set size can be combines to give a single bitmask, and any complete factors can also form part of that.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2017, 07:43:22 pm

Still working on a more elegant solution for day 13b.

My work in progress (big spoiler):-

(click to show/hide)

A layer of depth n has a periodicity of 2*(n-1)

So an example entry of "72: 14" translates into:
d+72 != 0 mod (2*(14-1))
d+72 != 0 mod 26
d != -72 mod 26
d != 6 mod 26

The entry of "1: 2" means d != 1 mod 2, i.e. d = 0 mod 2 as 0 is the only possible value remaining in the residue class mod 2.

I then apply this to every residue class that is divisible by 2, removing any entries that aren't equal to 0 mod 2.

Keep repeating this for residue classes that are multiples of each other, whilst I'm removing entries from residue classes, and if there's only one entry left in the residue class then it becomes a relation such as d = 20 mod 32.

Repeat this whilst it is learning something new each round and then report what is left:-

FINAL:
d = 0 mod 2
d = 0 mod 4
d = 0 mod 6
d = 4 mod 8
d = 0 mod 10
d = 12 mod 14
d = 4 mod 16
d = 0 mod 18
d = 6 mod 22
d = 20 mod 32

incomplete:-

d = 16 24 mod 26
d = 0 2 4 6 10 12 14 16 18 20 22 24 26 28 30 32 mod 34
d = 2 4 6 8 10 12 16 18 20 22 24 26 28 30 32 34 36 mod 38
d = 0 2 4 6 8 10 12 14 16 18 20 22 24 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 mod 58

So the first lot should be combined to a nice single term with the modulus being the LCM of 2,4,6,8,10,14,16,18,22,32 which is, urm, 2^5 * 3^2 * 5 * 7 * 11 = 110880). From my answer I already have I know it will be:-
d = 60660 mod 110880

60660 doesn't satisfy all of the 'incomplete' relations (60660 = 2 mod 26 and only 16 and 24 are allowed mod 26), so from there I just keep adding 110880 on again until I get something that satisfies all of them.

I've just got to do the CRT step to combine the 'complete' relations (after making sure the moduli are co-prime) into that "d = 60660 mod 110880" relation and then do the code to do the final loop multiple times.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2017, 08:38:53 pm

And the final bit (using my puzzle input, so it won't be the same for everyone)...

(click to show/hide)

...following on from the relations mine discovered above I start with n = 0 mod 1 (i.e. everything matches) and then add each of the relations in:-

Doing CRT
Called with n = 0 mod 1 and n = 0 mod 6
        combined to d = 0 mod 6
Called with n = 0 mod 6 and n = 20 mod 32
        combined to d = 84 mod 96
Called with n = 84 mod 96 and n = 0 mod 2
        combined to d = 84 mod 96
Called with n = 84 mod 96 and n = 12 mod 14
        combined to d = 180 mod 672
Called with n = 180 mod 672 and n = 6 mod 22
        combined to d = 1524 mod 7392
Called with n = 1524 mod 7392 and n = 4 mod 8
        combined to d = 1524 mod 7392
Called with n = 1524 mod 7392 and n = 0 mod 4
        combined to d = 1524 mod 7392
Called with n = 1524 mod 7392 and n = 0 mod 18
        combined to d = 16308 mod 22176
Called with n = 16308 mod 22176 and n = 4 mod 16
        combined to d = 16308 mod 22176
Called with n = 16308 mod 22176 and n = 0 mod 10
        combined to d = 60660 mod 110880
Combined: d = 60660 mod 110880
Trying...60660...171540...282420...393300...504180...615060...725940...836820...947700...1058580...1169460...1280340...1391220...1502100...1612980...1723860...1834740...1945620...2056500...2167380...2278260...2389140...2500020...2610900...2721780...2832660...2943540...3054420...3165300...3276180...3387060...3497940...3608820...3719700...3830580...3941460...
ANSWER: 3941460

Runs instantaneously too.

Here's the complete output using the simple example input from the challenge:-

$ cat inp.simp | time ./13c.pl
INIT: d mod 4 != 0
INIT: d mod 2 != 1
INIT: d mod 6 != 2
INIT: d mod 6 != 0
severity: 24
GOT: d = 0 mod 2
OK: Will apply d = 0 mod 2 to remain{4}
Removing d = 1 mod 4 because d=0 mod 2
Removing d = 3 mod 4 because d=0 mod 2
OK: Will apply d = 0 mod 2 to remain{6}
Removing d = 1 mod 6 because d=0 mod 2
Removing d = 3 mod 6 because d=0 mod 2
Removing d = 5 mod 6 because d=0 mod 2
d = 0 mod 2
Got: 6
GOT: d = 2 mod 4
GOT: d = 4 mod 6
d = 0 mod 2
d = 2 mod 4
d = 4 mod 6
Got: 2
d = 0 mod 2
d = 2 mod 4
d = 4 mod 6
Got: 0

FINAL:

d = 0 mod 2
d = 2 mod 4
d = 4 mod 6

Doing CRT
Called with n = 0 mod 1 and n = 4 mod 6
        combined to d = 4 mod 6
Called with n = 4 mod 6 and n = 2 mod 4
        combined to d = 10 mod 12
Called with n = 10 mod 12 and n = 0 mod 2
        combined to d = 10 mod 12
Combined: d = 10 mod 12
Trying...10...
ANSWER: 10
0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 9488maxresident)k
0inputs+0outputs (0major+632minor)pagefaults 0swaps

Title: Re: Advent of Code
Post by: Pickled Onion on 13 December, 2017, 08:48:56 pm

Quote from: Greenbank on 13 December, 2017, 07:43:22 pm

Still working on a more elegant solution for day 13b.

My work in progress (big spoiler):-

Neat!


Today's was the first this year where part 2 didn't respond well to a simplistic approach.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2017, 09:06:20 pm

Quote from: Pickled Onion on 13 December, 2017, 08:48:56 pm

Today's was the first this year where part 2 didn't respond well to a simplistic approach.

Really? I spent 5 minutes writing this to get the answer in 20 seconds:-

(click to show/hide)

#!/usr/bin/perl

use strict;

my %n=();

while( my $x = <STDIN> ) {
        chomp( $x );
        if( $x =~ /^(\d+): (\d+)$/ ) {
                $n{$1}=$2;
        }
}

my $delay=-1;
while( 1 ) {
        $delay++;
        my $got=0;
        foreach my $a ( keys %n ) {
                if( ($delay+$a) % ($n{$a}+$n{$a}-2) == 0 ) {
                        $got=1;
                        last;
                }
        }
        next if( $got );
        print "DELAY: $delay\n";
        exit;
}

My usual method is to see if the basic/naive approach will work and whether it produces the answer before I can implement something that runs faster.

But then I spent another 90 minutes or so to bring the execution time down to nothing, just to do it the right way (or at least one of the right ways).

Yes, that's 90 minutes to bring the execution time of a one-off task down from 20 seconds to 0 seconds. Unsurprisingly according to the chart (https://xkcd.com/1205/) it was not worth the time. But I did learn (or at least remind myself of) a few things along the way.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2017, 11:26:29 pm

You have a faster computer than me. Mine took a few minutes to run and I was completely naive with searching every possibility. The approach I had been thinking about is this:

(click to show/hide)

x is a bitmap of n bits where n is the effective size (2* (range - 1))
It looks like this for  depth %n ==0    0 1 1 1
and for depth %n ==1  1 0 1 1
So the only allowed permutations from this is the logical and of the masks 0011

Add in n=3 and the bitmask is tripled so it becomes 001100110011 and is then anded with the bitmask 011 bitshifted as required to satisfy depth % 3 and then repeated as required eg 011011011011 so my new mask is now 001000010011
And repeat as required till the end. Unfortunately the bitmask gets very long - it is the lowest common multiple of the ranges.

A smarter way would be to start with the first few and that would give a suitable step size for searching - maybe use the difference between mask lengths as a step.

Thinking out loud a bit as the brute force method worked.

Title: Re: Advent of Code
Post by: Greenbank on 14 December, 2017, 08:04:04 am

The one I posted checks every possibility (delay=0,1,2,3,4,5,...),  it just does the individual checks in a more 'mathsy' way.

Anyway, Day 14 and use of previous solutions (which I like and had hoped would appear more in AoC 2017).

I wonder if I need to make my knot hash code faster in case it's used more and more in future challenges. It currently takes 10 seconds to produce the 128 knot hashes required as input for parts (a) and (b), I'm sure I can get this down (and will give me something to do for AoC for part of the rest of the day).

Title: Re: Advent of Code
Post by: Ben T on 14 December, 2017, 11:01:45 am

Quote from: David Martin on 13 December, 2017, 11:26:29 pm

You have a faster computer than me. Mine took a few minutes to run and I was completely naive with searching every possibility. The approach I had been thinking about is this:

(click to show/hide)

x is a bitmap of n bits where n is the effective size (2* (range - 1))
It looks like this for  depth %n ==0    0 1 1 1
and for depth %n ==1  1 0 1 1
So the only allowed permutations from this is the logical and of the masks 0011

Add in n=3 and the bitmask is tripled so it becomes 001100110011 and is then anded with the bitmask 011 bitshifted as required to satisfy depth % 3 and then repeated as required eg 011011011011 so my new mask is now 001000010011
And repeat as required till the end. Unfortunately the bitmask gets very long - it is the lowest common multiple of the ranges.

A smarter way would be to start with the first few and that would give a suitable step size for searching - maybe use the difference between mask lengths as a step.

Thinking out loud a bit as the brute force method worked.

My day 13 part 2 runs in 0.4 of a second.

(click to show/hide)

The position of the scanner at given depth is given as a function of time t and the amplitude m (which is the scanner's range minus 1).
Because it moves back and forth its position is given by triangular wave equation x = m - abs(i % (2*m) - m) https://stackoverflow.com/questions/1073606/is-there-a-one-line-function-that-generates-a-triangle-wave
scanner position S = m - abs(x % (2*m) - m)
because x = t (we move one per second)
S = m - abs(t % (2*m) - m)
So we are caught when that is equal to zero.
For part 2, t is simply (t+delay) , and increment delay till you find one where you are never caught (the equation above is equal to zero).
I originally did it with a linq statement that was evaluating all the positions even if it were caught, once I changed it to one that moves  onto the next as soon as it's caught that brings it from 11 seconds to under a second.

Time to run should be proportional to the number of positions with a scanner, regardless of the max depth of any position with a scanner.
https://github.com/bjtaylor1/AoC2017/blob/day13part2/Day13/Program.cs

Title: Re: Advent of Code
Post by: Greenbank on 14 December, 2017, 11:22:37 am

Naive 13b down to under 3 seconds if I check them in range depth order (from smallest to largest). I was already bailing early but checking the layers in a suboptimal order. Using an interpreted language doesn't help either.

But my 'clever' solution for day13b runs in 0.002 seconds.
* For the example input I do my pre-computation then checks just one possible delay value.
* For my real input I do my pre-computation and then have to check just 36 possible delay values.

I could speed this up too as:

(click to show/hide)

the various number theoretic bits (factorisation, LCM, CRT) are all implemented sub-optimally.

I'll see if I can knock up an input that has an answer that is orders of magnitude larger.

Title: Re: Advent of Code
Post by: David Martin on 14 December, 2017, 11:40:25 am

Today's may have to wait till tomorrow or the weekend -overrun with other things right now.

Title: Re: Advent of Code
Post by: Diver300 on 14 December, 2017, 11:45:05 am

I used a spreadsheet (again!) for day 13.  It had far fewer active cells than for day 7 and it didn't do much more than I could have done with a pencil and paper and a calculator.

(click to show/hide)

For my puzzle input, odd numbered delays were clearly doomed.

For even numbered inputs, for each of the following periods:-
10
14
18
22
32

There was only one possible solution for each cycle. For instance, the solution had to be  4 + 10 * n , 2 + 14 * m , 14 + 18 * p etc

So I went up in 10s from 4 until I found a solution that could expressed as  2 + 14 * m.
Then I went up in 70s (the lowest common multiple of 10 and 14) until I found a solution that could be expresses as 14 + 18 * p
And so on until I had a solution worked for all 5 numbers. That only took a total of about 20 tries.

The other levels had more complicated rules with more than one solution, so I went up in jumps of 110880 and visually compared the remainders. That was under 40 lines of the spreadsheet, comparing 4 columns.

Title: Re: Advent of Code
Post by: Greenbank on 14 December, 2017, 11:49:39 am

Quote from: Greenbank on 14 December, 2017, 11:22:37 am

I'll see if I can knock up an input that has an answer that is orders of magnitude larger.

OK, try this against your 2017 day 13b solver: http://www.greenbank.org/misc/aoc2017/2017_13b.huge.txt

The answer is about ~250 times larger than my answer for 13b was, which should give you a rough idea of execution time if it's checking every number along the way. (The answer still fits inside a signed 32-bit integer though, so programs shouldn't need to be altered.)

Mine gets it in under 0.001s after only having to try 38 numbers.

[EDIT] In contrast, my naive solver took 738s to get the answer.

Title: Re: Advent of Code
Post by: Diver300 on 14 December, 2017, 12:24:18 pm

Day 14 relies on a code written for day 10.

(click to show/hide)

Part 2. This is searching for contiguous areas. I'd done something similar when I wrote code for minesweeper on a Psion, where it automatically finds contiguous clear areas.

I ran a list of cells that I need dealing with.  That got up to 45 items.

Title: Re: Advent of Code
Post by: Greenbank on 14 December, 2017, 12:55:18 pm

(click to show/hide)

I did one script to generate the input to the knot-hash function (blah-0 to blah-127).
I then ran that input through the knot-hash function to get the list of hashes
I then had another script to convert it to binary representation.
I treated the output of the above as the input for the next program, so I didn't have to go do that work again and again each time I tested my code.

I stored the grid in a 128x128 array using # or . characters. (Should have just kept it as 1 or 0 thinking about it.)

I iterated through the grid to find an element that was still #. If I found one I incremented a counter (to signify a new group) and then used a recursive function to:-
a) set the element to . to indicate it was done (there's no need to keep track of whether it was originally set or not, and there's no need to store the group number along side each element)
b) call itself on each of the 4 neighbours that are still set to #

The alternative to a recursive function (if recursion depth could get too big) would be to use a list of element co-ordinates to know what to process next.

[EDIT] With the example my code managed to get to 105 nested recursions, with my final puzzle input it was only 89 max depth. My program (well, the perl interpreter) had no problem even with the pathalogical case of all hashes being ffffffffffffffffffffffffffffffff which leads to a recursion depth of 16384 and there only being one group.

Don't think there's any other optimisation that can be done.

If the goal was minimising memory usage I'd store each element of memory as a single bit (1 is # and 0 is .) So memory usage for the grid could be just 128*128/8 = 2048 bytes.

Title: Re: Advent of Code
Post by: Greenbank on 15 December, 2017, 10:34:38 am

Pretty simple today (day 15), no surprises.

Title: Re: Advent of Code
Post by: Oaky on 15 December, 2017, 04:50:24 pm

(click to show/hide)

A little bit of eye-candy - groups coloured in:-
(http://www.oakden.org/mark/bike/yacf/pics/groups.png)

Title: Re: Advent of Code
Post by: Greenbank on 15 December, 2017, 04:52:49 pm

Ooh. Do 4 colours suffice?

Title: Re: Advent of Code
Post by: Oaky on 15 December, 2017, 05:12:30 pm

Quote from: Greenbank on 15 December, 2017, 04:52:49 pm

Ooh. Do 4 colours suffice?

Well, given my input, I'm using

(click to show/hide)

1019

  colours (including the black for the background), but in the 4-colour sense, two suffices for this pattern. :)  Doesn't look as nice then, though.

Title: Re: Advent of Code
Post by: Oaky on 15 December, 2017, 05:48:24 pm

Quote from: Greenbank on 14 December, 2017, 12:55:18 pm

(click to show/hide)

I did one script to generate the input to the knot-hash function (blah-0 to blah-127).
I then ran that input through the knot-hash function to get the list of hashes
I then had another script to convert it to binary representation.
I treated the output of the above as the input for the next program, so I didn't have to go do that work again and again each time I tested my code.

I stored the grid in a 128x128 array using # or . characters. (Should have just kept it as 1 or 0 thinking about it.)

I iterated through the grid to find an element that was still #. If I found one I incremented a counter (to signify a new group) and then used a recursive function to:-
a) set the element to . to indicate it was done (there's no need to keep track of whether it was originally set or not, and there's no need to store the group number along side each element)
b) call itself on each of the 4 neighbours that are still set to #

The alternative to a recursive function (if recursion depth could get too big) would be to use a list of element co-ordinates to know what to process next.

[EDIT] With the example my code managed to get to 105 nested recursions, with my final puzzle input it was only 89 max depth. My program (well, the perl interpreter) had no problem even with the pathalogical case of all hashes being ffffffffffffffffffffffffffffffff which leads to a recursion depth of 16384 and there only being one group.

Don't think there's any other optimisation that can be done.

If the goal was minimising memory usage I'd store each element of memory as a single bit (1 is # and 0 is .) So memory usage for the grid could be just 128*128/8 = 2048 bytes.

(click to show/hide)

I didn't use the recursive approach, instead iterated over each element in my disk_grid (of 1's and 0's) filling in a new grid (groups_grid) applying the following rules:

Code: [Select]

If the current disk cell is 1
    is the disk cell above populated? then:
        copy the group number from the group_grid cell above to this one
        is the group_grid cell to the left of me populated with a different number? then:
            replace that number everywhere in the group grid with the number I just filled in here (only have to consider this row and the ones above)
    else: is the disk cell to the left populated? then:
        copy the value from the group_grid cell left of me to this cell
    else:
        choose a new group number and fill it in in the current group_grid cell


(click to show/hide)

Title: Re: Advent of Code
Post by: Diver300 on 15 December, 2017, 09:56:56 pm

Day 15

I thought that Javascript might struggle doing modulus 2³¹. It didn't, and only takes a few seconds to run.

The whole point about day 13 was that it took too long to run when brute-forced. When reading day 15, I thought that the maths that is simple in principle would have some feature that would trip up the simple approach.

Title: Re: Advent of Code
Post by: David Martin on 15 December, 2017, 11:13:32 pm

Far too busy to do yesterday and today till now.

Day 14 was easy for part 1,

(click to show/hide)

With such a small grid I walked it recursively from the next unassigned value, exploring all unassigned values and adding them to a hash. I should have put the group numbers in too.

Day 15 was straightforward

(click to show/hide)

barring silly errors. Just bitwise comparisons, remembering that (a & 2**16 -1) ^ (b & 2**16 -1) ==0 is a match.

and for part 2, repeating each calculation whilst n & (multiple - 1) filters very easily.

Title: Re: Advent of Code
Post by: Diver300 on 16 December, 2017, 07:53:22 am

day 16 part 2 is proving difficult.....

Title: Re: Advent of Code
Post by: Pickled Onion on 16 December, 2017, 08:10:00 am

Quote from: Diver300 on 16 December, 2017, 07:53:22 am

day 16 part 2 is proving difficult.....

You're not the only one stuck on that

(click to show/hide)

You will kick yourself when you spot it

Title: Re: Advent of Code
Post by: David Martin on 16 December, 2017, 10:03:52 am

I am finding part 2 challenging

(click to show/hide)

You don't need to repeat the dance, just note how the dance transforms the input. Then that multiplies logarithmically.
So far I have built a bitwise transformation matrix. 1 dance applied to 1 dance gives 2 dances. 2 dances applied to 2 dances gives 4 and so on.
Then walk through the bit map of 1000000000 applying the appropriate transformations (they should be commutative).
The answer I get settles to a particular order - the program runs almost instantly.

But it is the wrong answer. This has me confused. Part 1 was correct so my transformation matrix is correct.

Title: Re: Advent of Code
Post by: Pickled Onion on 16 December, 2017, 10:40:21 am

I didn't think that would work.

(click to show/hide)

The intermixing of "partner" and "exchange" means each transformation will be different

Title: Re: Advent of Code
Post by: David Martin on 16 December, 2017, 10:45:00 am

OK, simple error

(click to show/hide)

Because the order has changed, the exchange of named entities (rather than positional) is not scalable.
Once the key thing has been thought about it becomes very quick.

Title: Re: Advent of Code
Post by: David Martin on 16 December, 2017, 10:45:32 am

Quote from: Pickled Onion on 16 December, 2017, 10:40:21 am

I didn't think that would work.

(click to show/hide)

The intermixing of "partner" and "exchange" means each transformation will be different

That is now obvious. :)

Title: Re: Advent of Code
Post by: Greenbank on 16 December, 2017, 12:57:50 pm

Bit late to it today...

(click to show/hide)

Seeing the requirement for 1,000,000,000 iterations I knew there was going to be some trick before I even attempted to put my main code into a bigger loop, and guessed there would be no point even trying to optimise the code in order to be run 1,000,000,000 times.

So I checked something else and it turned out to be very simple. (I'll leave it a bit before elaborating.)

It's annoying as I'm solving the majority of these in a faster time than the 100th person on the main leaderboard (today I would have scraped into the top 10). But I guess quite a few other people are too (who also just don't happen to be at their computer at midnight EST).

Title: Re: Advent of Code
Post by: Diver300 on 16 December, 2017, 04:43:35 pm

Quote from: Pickled Onion on 16 December, 2017, 10:40:21 am

I didn't think that would work.

(click to show/hide)

You don't need to repeat the dance, just note how the dance transforms the input. Then that multiplies logarithmically.
So far I have built a bitwise transformation matrix. 1 dance applied to 1 dance gives 2 dances. 2 dances applied to 2 dances gives 4 and so on.
Then walk through the bit map of 1000000000 applying the appropriate transformations (they should be commutative).
The answer I get settles to a particular order - the program runs almost instantly.

But it is the wrong answer. This has me confused. Part 1 was correct so my transformation matrix is correct.


The intermixing of "partner" and "exchange" means each transformation will be different

(click to show/hide)

I though that I could run it 1000 times, which takes a few seconds, then take the transformation that 1000 runs gives, run that 1000 times to give the transformation that 1,000,000 gives, and run that 1000 times.

I also found out that the mix of exchange and partner messes it up.

Title: Re: Advent of Code
Post by: Ben T on 16 December, 2017, 05:25:07 pm

(click to show/hide)

a not particularly hard to spot trick question  :)

Title: Re: Advent of Code
Post by: Diver300 on 16 December, 2017, 05:31:18 pm

Day 16

(click to show/hide)

I realised that I could separate out the partner swaps from the two position swaps, and run all the partner swaps first.

I think that the two position swaps could be run by working out the transformation that 1000 runs produces, running that 1000 times and working out the resultant transformation etc

That left the partner swaps. I tried some trivial ones and found that I got back to the start after n+1 repeats, where n was the number of partner swaps. So I tried with the 2213 partner swaps in my puzzle input, and it didn't work. However, I found that there had been many instances of abcdefgehijklmnop, and that after every 36 repeats the result was back to the starting value.

At that point I thought that I could use the multiplying transformations for the two position swaps, and the knowledge that I only needed 28 (= 1,000,000,000 mod 36) repeats of the 2213 partner swaps. On a whim, I tried putting back the two position swaps and found that the complete transformation also came back to abcdefgehijklmnop in 36 repeats.

So I just ran the 10,000 actions of the puzzle input 28 times to get the answer.

I still have no idea why 36 repeats of the partner swaps or 36 repeats of all of the actions result in no change.

Title: Re: Advent of Code
Post by: Ben T on 16 December, 2017, 05:38:58 pm

Quote from: Diver300 on 16 December, 2017, 05:31:18 pm

Day 16

(click to show/hide)

I realised that I could separate out the partner swaps from the two position swaps, and run all the partner swaps first.

I think that the two position swaps could be run by working out the transformation that 1000 runs produces, running that 1000 times and working out the resultant transformation etc

That left the partner swaps. I tried some trivial ones and found that I got back to the start after n+1 repeats, where n was the number of partner swaps. So I tried with the 2213 partner swaps in my puzzle input, and it didn't work. However, I found that there had been many instances of abcdefgehijklmnop, and that after every 36 repeats the result was back to the starting value.

At that point I thought that I could use the multiplying transformations for the two position swaps, and the knowledge that I only needed 28 (= 1,000,000,000 mod 36) repeats of the 2213 partner swaps. On a whim, I tried putting back the two position swaps and found that the complete transformation also came back to abcdefgehijklmnop in 36 repeats.

So I just ran the 10,000 actions of the puzzle input 28 times to get the answer.

I still have no idea why 36 repeats of the partner swaps or 36 repeats of all of the actions result in no change.

(click to show/hide)

not that complicated...just watch for when it repeats and then jump to the nearest-to-the-end possible factor of that

startpos = "abcdefghijklmnop"
currentpos = startpos
N = 1 billion
for(n = 1; n < N; )
{
  currentpos = DoMoves(currentpos);
  n++;
  if(currentpos == startpos)
  {

      n *= floor(N/n);     
     //for me, this occurred when n == 60.
     //It therefore jumps to 999,999,960, and only has to do 40 more iterations.
  }
}

Title: Re: Advent of Code
Post by: Diver300 on 16 December, 2017, 09:11:40 pm

Quote from: Ben T on 16 December, 2017, 05:38:58 pm

Quote from: Diver300 on 16 December, 2017, 05:31:18 pm

Day 16

(click to show/hide)

I realised that I could separate out the partner swaps from the two position swaps, and run all the partner swaps first.

I think that the two position swaps could be run by working out the transformation that 1000 runs produces, running that 1000 times and working out the resultant transformation etc

That left the partner swaps. I tried some trivial ones and found that I got back to the start after n+1 repeats, where n was the number of partner swaps. So I tried with the 2213 partner swaps in my puzzle input, and it didn't work. However, I found that there had been many instances of abcdefgehijklmnop, and that after every 36 repeats the result was back to the starting value.

At that point I thought that I could use the multiplying transformations for the two position swaps, and the knowledge that I only needed 28 (= 1,000,000,000 mod 36) repeats of the 2213 partner swaps. On a whim, I tried putting back the two position swaps and found that the complete transformation also came back to abcdefgehijklmnop in 36 repeats.

So I just ran the 10,000 actions of the puzzle input 28 times to get the answer.

I still have no idea why 36 repeats of the partner swaps or 36 repeats of all of the actions result in no change.

(click to show/hide)

not that complicated...just watch for when it repeats and then jump to the nearest-to-the-end possible factor of that

startpos = "abcdefghijklmnop"
currentpos = startpos
N = 1 billion
for(n = 1; n < N; )
{
  currentpos = DoMoves(currentpos);
  n++;
  if(currentpos == startpos)
  {

      n *= floor(N/n);     
     //for me, this occurred when n == 60.
     //It therefore jumps to 999,999,960, and only has to do 40 more iterations.
  }
}

(click to show/hide)

Finding the repeat is fairly easy. I did it with a ctrl-F on a list of iteration results.
What I can't work out is why it repeats, except that there has to be a solution, and something that takes an average PC about a week to finish is viable.
Is there anything about the puzzle input that says it has to repeat?

Title: Re: Advent of Code
Post by: Pickled Onion on 16 December, 2017, 10:36:19 pm

Quote from: Diver300 on 16 December, 2017, 09:11:40 pm

(click to show/hide)

Is there anything about the puzzle input that says it has to repeat?

(click to show/hide)

IANAMathematician, but I think there can only be two scenarios. Either it repeats from the start or gets into a loop. The perfect dance would cover all 16! permutations, leaving the puzzle essentially unsolvable, but it would still repeat. Being asked for a billion iterations makes it obvious the repeat would be shorter (my implementation of a single dance would have taken 3 years to run for a billion). A loop would have made it a bit more fun, essentially a repeat but not from the starting point.

Title: Re: Advent of Code
Post by: Diver300 on 17 December, 2017, 06:53:36 am

Day 17 was quite straightforward.

(click to show/hide)

The effort for part 1 goes up with the square of the number of steps. Less information is needed for part 2, and the fact that there are so many steps means that the algorithm has to be simplified to complete in reasonable time for the huge number of steps.

Title: Re: Advent of Code
Post by: Pickled Onion on 17 December, 2017, 08:41:39 am

Quote from: Diver300 on 17 December, 2017, 06:53:36 am

Day 17 was quite straightforward.

(click to show/hide)

The effort for part 1 goes up with the square of the number of steps. Less information is needed for part 2, and the fact that there are so many steps means that the algorithm has to be simplified to complete in reasonable time for the huge number of steps.

64 characters for part 2, including input data.  ;D

(click to show/hide)

Tomorrow...

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2017, 09:59:29 am

Quote from: Diver300 on 16 December, 2017, 09:11:40 pm

(click to show/hide)

Finding the repeat is fairly easy. I did it with a ctrl-F on a list of iteration results.
What I can't work out is why it repeats, except that there has to be a solution, and something that takes an average PC about a week to finish is viable.
Is there anything about the puzzle input that says it has to repeat?

(click to show/hide)

No, nothing explicitly said it had to repeat although, as Pickled Onion said, there are a finite number of permutations (16! which is ~20,000 times greater than the 1 billion steps requested) so at some point it has to repeat.

But the number of steps combined with the fact that the algorithm was going to be quite expensive to implement made me think there was going to be some other trick, even before I started to implement it.

I'd assumed that there would be some repetition and so I stored the state after each dance and checked whether it had been seen before. I hadn't expected the period to be so short though - it was only 60 with my input.

I checked and there are no duplicate states within an individual dance, so there's no way that part of it can be made faster I don't think.

I'll see if I can make my implementation faster (and implement it in C). It can certainly be made O(n) where n is the number of dances as each operation can be done in linear time:-
* a spin is just incrementing an offset, no need to move anything in memory
* an exchanges and pairings are just swapping a couple of memory locations, with the help of an array which is kept up to date with the location of each item (although need to apply the current offset from spins after extracting this because I wouldn't update the entire array when a spin is executed)

I'm guessing even the more efficient/fastest algorithm is still going to be too slow to get to 1,000,000,000 dances in any reasonable time.

It would be no great surprise that the dance moves and the number of dances were specifically chosen to put the brute force method beyond reasonable computation bounds.

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2017, 10:05:54 am

(click to show/hide)

I like these ones where the two parts mean you need to keep track of different things and the bulk of the code is thrown away for part b because it's too expensive.

Also remembered to keep accurate timestamps:-

10:07:37 started (no peeking at the day 17 page, or any hints here, before this time)
10:17:01 after submitting correct solution for part a
10:22:18 after submitting correct solution for part b

Which is 00:09:24 (wouldn't have made it onto the leaderboard if I'd started at 5am) but 00:14:41 to get to part b solution which would have been good for 74th. Ifs and buts.

Quote from: Pickled Onion on 17 December, 2017, 08:41:39 am

64 characters for part 2, including input data.  ;D

I can get it down to 84 in perl, but then I'm not very good at code golf.

Title: Re: Advent of Code
Post by: Pickled Onion on 17 December, 2017, 10:43:24 am

Quote from: Greenbank on 17 December, 2017, 10:05:54 am

Quote from: Pickled Onion on 17 December, 2017, 08:41:39 am

64 characters for part 2, including input data.  ;D

I can get it down to 84 in perl, but then I'm not very good at code golf.

I look forward to comparing line noise tomorrow!

Title: Re: Advent of Code
Post by: David Martin on 17 December, 2017, 02:01:18 pm

17a was quite straightforward.
17b required minor thought but eventually succumbed to brute force

(click to show/hide)

Once you notice that 0 is always the first position, you only need to keep track of the insert when pos = 0. Nothing else matters. It then becomes a loop. There should be a way of readily checking which values would be applicable and going straight there but my maths is not up to that. runs in a few seconds so not much bother.

Title: Re: Advent of Code
Post by: Diver300 on 17 December, 2017, 02:17:44 pm

Quote from: David Martin on 17 December, 2017, 02:01:18 pm

17a was quite straightforward.
17b required minor thought but eventually succumbed to brute force

(click to show/hide)

Once you notice that 0 is always the first position, you only need to keep track of the insert when pos = 0. Nothing else matters. It then becomes a loop. There should be a way of readily checking which values would be applicable and going straight there but my maths is not up to that. runs in a few seconds so not much bother.

(click to show/hide)

Code: [Select]

current = (current + step + 1) % buff_len;
if (current == 0){buff [1] = i;}
That's all that I ran 50 million times. (starting at i = 1)
It takes about 3 seconds

Title: Re: Advent of Code
Post by: David Martin on 17 December, 2017, 02:24:39 pm

pretty much the same here. Took a bit longer than 3 seconds (about 10 or so)

Title: Re: Advent of Code
Post by: Pickled Onion on 17 December, 2017, 02:32:26 pm

Don't you need to increment buf_len?

My Perl version took 18 seconds with a grep BLOCK, but that's because grep allocates the whole list before it starts. Turning that into a for(RANGE) runs in 8 seconds. Oh and I'm down to 61 characters in the golf version  :)

Title: Re: Advent of Code
Post by: Ben T on 17 December, 2017, 03:13:28 pm

Quote from: Diver300 on 17 December, 2017, 02:17:44 pm

Quote from: David Martin on 17 December, 2017, 02:01:18 pm

17a was quite straightforward.
17b required minor thought but eventually succumbed to brute force

(click to show/hide)

Once you notice that 0 is always the first position, you only need to keep track of the insert when pos = 0. Nothing else matters. It then becomes a loop. There should be a way of readily checking which values would be applicable and going straight there but my maths is not up to that. runs in a few seconds so not much bother.

(click to show/hide)

Code: [Select]

current = (current + step + 1) % buff_len;
if (current == 0){buff [1] = i;}
That's all that I ran 50 million times. (starting at i = 1)
It takes about 3 seconds

(click to show/hide)

Interesting that they chose 50 million, I did a function of the type
f(n) = (f(n-1)+N)%n
and called it recursively but it threw a stack overflow at about 49million and something.

Title: Re: Advent of Code
Post by: Croft on 17 December, 2017, 03:33:35 pm

Ben T:

(click to show/hide)

If you modify f(n) so it also includes the previous value as a parameter, you make it tail-recursive (https://en.wikipedia.org/wiki/Tail_call), which in many languages should avoid stack overflow (it does not need to store anything on the stack).

Title: Re: Advent of Code
Post by: Ben T on 17 December, 2017, 05:08:27 pm

Quote from: Croft on 17 December, 2017, 03:33:35 pm

Ben T:

(click to show/hide)

If you modify f(n) so it also includes the previous value as a parameter, you make it tail-recursive (https://en.wikipedia.org/wiki/Tail_call), which in many languages should avoid stack overflow (it does not need to store anything on the stack).

(click to show/hide)

Really, interesting - so if I had:

static int N = 370; //(my puzzle input)

        static int F(int n)
        {
            if (n == 0) return 0;

            return ((F(n-1) + N) % n) + 1;
        }
        static void Main()
        {
            Console.WriteLine(F(50000000));
        }

how would I 'modify it to include the previous value as a parameter' ?
Because for that I need to call the function, for which I need the value for n-2, but to get that I need the value for n-3, ...... etc.

Title: Re: Advent of Code
Post by: Diver300 on 17 December, 2017, 06:27:35 pm

Quote from: Pickled Onion on 17 December, 2017, 02:32:26 pm

Don't you need to increment buf_len?

Yes.

I put that after the conditional bit for some reason.

Title: Re: Advent of Code
Post by: Croft on 17 December, 2017, 07:14:23 pm

Ben T:

(click to show/hide)

if you count up rather than down your first call can be f(1,0) because we know the initial "previous value" is zero. You can either hard code the upper limit of 50000000 in the function or pass it in as a parameter.

Title: Re: Advent of Code
Post by: Greenbank on 18 December, 2017, 09:25:38 am

Day 18.

Part a: Yet another psuedo CPU question. Boooring, or so I thought.

But part b was a lovely twist on it.

(00:15:45 from start to part a solution, 00:35:14 from start to part b solution, would have been a minute quicker if I'd read which answer I needed to give more closely.)

(click to show/hide)

I missed all of the clues as to what part b would be ("duet" and that "snd/rcv" generally stand for send/receive not sound/recover) in an effort to get part a done as quickly as possible.

Mind you, even if I had spotted that it wouldn't have changed my implementation for part a. As I'd implemented it it didn't take too much to pull the code into a subroutine acting on an object (rather than a bunch of global variables) so I could run two of them side-by-side with the snd/rcv instructions pushing/pulling items from a queue in the other program's object. Stall detection was pretty easy.

Title: Re: Advent of Code
Post by: Greenbank on 18 December, 2017, 09:29:48 am

Quote from: Pickled Onion on 17 December, 2017, 10:43:24 am

Quote from: Greenbank on 17 December, 2017, 10:05:54 am

Quote from: Pickled Onion on 17 December, 2017, 08:41:39 am

64 characters for part 2, including input data.  ;D

I can get it down to 84 in perl, but then I'm not very good at code golf.

I look forward to comparing line noise tomorrow!

(click to show/hide)

$p=0;$i=0;while($i<50000000){$i++;$p=(($p+366)%$i)+1;$v=$i if($p==1);}print"$v\n";

Doh, obvious removal of initialisations...

while($i<50000000){$i++;$p=(($p+366)%$i)+1;$v=$i if$p==1;}print"$v\n";

while($i<5*10**7){$i++;$p=(($p+366)%$i)+1;$v=$i if$p==1;}print"$v\n";

69 chars

Title: Re: Advent of Code
Post by: David Martin on 18 December, 2017, 01:11:16 pm

First read the instructions..

(click to show/hide)

Straightforward though it took time to just write out all the functions.

(click to show/hide)

OK, rewrite to run two sets in parallel with rcv having the context switch between programs.
It then didn't end. Mostly due to me forgetting to remove the message from the message queue when I did the context switch, and not setting registers correctly. I'd set it to initialise all registers to the program id, not just one.
It then ran in next to no time at all.

Title: Re: Advent of Code
Post by: Pickled Onion on 18 December, 2017, 01:21:15 pm

Quote from: Greenbank on 18 December, 2017, 09:29:48 am

Quote from: Pickled Onion on 17 December, 2017, 10:43:24 am

Quote from: Greenbank on 17 December, 2017, 10:05:54 am

Quote from: Pickled Onion on 17 December, 2017, 08:41:39 am

64 characters for part 2, including input data.  ;D

I can get it down to 84 in perl, but then I'm not very good at code golf.

I look forward to comparing line noise tomorrow!

(click to show/hide)

$p=0;$i=0;while($i<50000000){$i++;$p=(($p+366)%$i)+1;$v=$i if($p==1);}print"$v\n";

Doh, obvious removal of initialisations...

while($i<50000000){$i++;$p=(($p+366)%$i)+1;$v=$i if$p==1;}print"$v\n";

while($i<5*10**7){$i++;$p=(($p+366)%$i)+1;$v=$i if$p==1;}print"$v\n";

69 chars

(click to show/hide)

slow, using grep:

$l=1;print((grep{$c=1+($c+382%$l)%$l++;$c==1&&$_}(1..5e7))[-1]);

then basically the same as yours, with a couple of tricks to shorten:

$l=1;for(1..5e7){$c=1+($c+382)%$l++;$c==1&&print"\r$_"}

54 characters

Title: Re: Advent of Code
Post by: R_nger on 18 December, 2017, 06:05:00 pm

Quote from: David Martin on 18 December, 2017, 01:11:16 pm

First read the instructions..

(click to show/hide)

Straightforward though it took time to just write out all the functions.

(click to show/hide)

OK, rewrite to run two sets in parallel with rcv having the context switch between programs.
It then didn't end. Mostly due to me forgetting to remove the message from the message queue when I did the context switch, and not setting registers correctly. I'd set it to initialise all registers to the program id, not just one.
It then ran in next to no time at all.

Should that be Day 18 ?

Title: Re: Advent of Code
Post by: Oaky on 18 December, 2017, 09:58:13 pm

(click to show/hide)

I coded part 1 with half an eye on the send/receive interpretation, creating a list of sent values and popping one off for the rcv part. So, once I'd written up the functions, it took very little time to adapt the code to part two.

I was also able to re-use functions from the day 8 vm which I wrote to allow registers or values in all of the appropriate areas.

I did, however, spend most of the day chasing two annoying bugs:

• I was popping the rcv value off the wrong end of the stack.
• A race condition in my threaded version of the solution

Once I fixed the first one, part 2 worked, running the two programs in a scheduler loop, switching between them whenever one was blocked.

I haven't yet solved the threaded version's race condition though.  I'm finding it difficult to reliably tell from one thread whether the other thread is also blocked :/

Title: Re: Advent of Code
Post by: David Martin on 18 December, 2017, 10:32:19 pm

Quote from: R_nger on 18 December, 2017, 06:05:00 pm

Quote from: David Martin on 18 December, 2017, 01:11:16 pm

First read the instructions..

(click to show/hide)

Straightforward though it took time to just write out all the functions.

(click to show/hide)

OK, rewrite to run two sets in parallel with rcv having the context switch between programs.
It then didn't end. Mostly due to me forgetting to remove the message from the message queue when I did the context switch, and not setting registers correctly. I'd set it to initialise all registers to the program id, not just one.
It then ran in next to no time at all.

Should that be Day 18 ?

That was probably one of the bugs..

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2017, 08:12:59 am

Not much of a workout today. (Day 19). And scarily I wrote a 97 line perl program that ran first time with no syntax errors (but one minor logic error that my checking caught).

(click to show/hide)

I can only imagine part b is there to catch out people who tried to do the first part manually. You can't cheat either as the number of steps is greater than the number of non-whitespace characters in the puzzle input as some grid squares are passed over twice.

It was only 10s for me to add in a step counter and output that (although I had an off-by-one error so it cost me a minute to resubmit my answer, should have checked it against the example solution first!)

Title: Re: Advent of Code
Post by: David Martin on 19 December, 2017, 08:39:53 am

Again, a lot of code for not much intellectual input - overengineered it but that isn't a bad thing.

(click to show/hide)

I  didn't look closely at the input so had all cases including letters immediately after corners and so on. A few silly mistakes but it got there without error once the silly things had been dealt with (starting off going N instead of S, and stripping all the whitespace off the end of lines when reading the input - D'Oh!)

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2017, 08:50:38 am

(click to show/hide)

This was my logic error (the joys of copy-and-paste programming):-

...

Code: [Select]

        if( $dir eq "S" ) {
                $y+=1;
        } elsif( $dir eq "N") {
                $y-=1;
        } elsif( $dir eq "E" ) {
                $x+=1;
        } elsif( $dir eq "E" ) {
                $x-=1;
        } else {
                print "ARGH: DIR $dir\n";
                exit;
        }

Of course you can do the above in a more compact way and fewer lines, but when the program stopped with "ARGH: DIR W" I knew exactly where to look.

Title: Re: Advent of Code
Post by: David Martin on 19 December, 2017, 11:59:55 am

Fortunately the input was well behaved, I had considered cases like two corners in consecutive steps, realised that the coding would be more involved and if it came across a not immediately tractable solution to print the local environment and ask for guidance. It didn't need to as there was at least one step between each corner.

Title: Re: Advent of Code
Post by: Croft on 19 December, 2017, 12:14:50 pm

A bit disappointed in the simplicity of Part 1. I was almost certain when doing part 1, that the second part was going to ask for the shortest path from start to destination point of part 1.

Title: Re: Advent of Code
Post by: David Martin on 19 December, 2017, 12:21:50 pm

By only taking known routes and adding corners where they cross.. I'm just expecting a humdinger tomorrow then.

Title: Re: Advent of Code
Post by: Pickled Onion on 19 December, 2017, 12:33:40 pm

Tripped up by having my packet fall off the end of the route and carry on going. The test data was fine as that took it off the circuit board and stopped, but on the actual circuit it found another path and carried on in circles. Oops.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2017, 01:05:05 pm

Quote from: David Martin on 19 December, 2017, 11:59:55 am

Fortunately the input was well behaved, I had considered cases like two corners in consecutive steps, realised that the coding would be more involved and if it came across a not immediately tractable solution to print the local environment and ask for guidance. It didn't need to as there was at least one step between each corner.

Not sure why this would be a problem, there are no decisions to be made at any corners. Either you can continue on in a straight line still or you have to choose left or right (and there won't be a choice).

For example:-

Code: [Select]

  |
B++A
  ++

is unambiguous.

(click to show/hide)

My solution didn't care what the route characters were. As far as it was concerned it was either a space (not part of a route) or not a space (part of the route, and possibly a letter).

Title: Re: Advent of Code
Post by: Ben T on 19 December, 2017, 01:55:07 pm

Quote from: Oaky on 18 December, 2017, 09:58:13 pm

(click to show/hide)

I haven't yet solved the threaded version's race condition though.  I'm finding it difficult to reliably tell from one thread whether the other thread is also blocked :/

(click to show/hide)

I've done 18b in a threaded way as well and I think it's always possible to make them deadlock at the 'wrong' place.
I've done a deadlock check by doing a test-lock-retest for whether the receive queue is empty, and if the other thread is also waiting on an empty queue, there's a deadlock.
However, it's always possible that if one thread races ahead and does, say, 100 or more lines before the other does any, then they get into a deadlock situation far before the 'latest possible' deadlock situation.
So most of the time my code generates the answer that was the first and only one I tried and which was accepted, 6958.  But 1 time out of 10 it will generate 127.
Could there have been multiple correct answers, I wonder?
It does say in the text "in fact, the programs don't even necessarily run at the same speed".
Not sure how to define 'race condition' in this case. I can prove that it deadlocks other than when at the 'maximum' right answer but not sure how to deem that wrong other than by forcing them to go at the same speed.
I think what would also prevent this 'race condition' would be to force them to go at similar speeds, but how 'similar' it needs to be is the question.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2017, 03:45:47 pm

Quote from: Ben T on 19 December, 2017, 01:55:07 pm

Quote from: Oaky on 18 December, 2017, 09:58:13 pm

(click to show/hide)

I haven't yet solved the threaded version's race condition though.  I'm finding it difficult to reliably tell from one thread whether the other thread is also blocked :/

(click to show/hide)

I've done 18b in a threaded way as well and I think it's always possible to make them deadlock at the 'wrong' place.
I've done a deadlock check by doing a test-lock-retest for whether the receive queue is empty, and if the other thread is also waiting on an empty queue, there's a deadlock.
However, it's always possible that if one thread races ahead and does, say, 100 or more lines before the other does any, then they get into a deadlock situation far before the 'latest possible' deadlock situation.
So most of the time my code generates the answer that was the first and only one I tried and which was accepted, 6958.  But 1 time out of 10 it will generate 127.
Could there have been multiple correct answers, I wonder?
It does say in the text "in fact, the programs don't even necessarily run at the same speed".
Not sure how to define 'race condition' in this case. I can prove that it deadlocks other than when at the 'maximum' right answer but not sure how to deem that wrong other than by forcing them to go at the same speed.
I think what would also prevent this 'race condition' would be to force them to go at similar speeds, but how 'similar' it needs to be is the question.

(click to show/hide)

I can't see how they can deadlock and produce anything but a single answer. The data they send is not dependent on anything timing related and must the be the same each time.

There can only be a deadlock when both queues are empty and both are attempting to receive. It's impossible to detect this from the other process if there are no other communication channels between the programs. A "haven't heard from it from 30 seconds, assuming it is also deadlocked" is about the best you can do without something that knows about the state of the other processes queue.

I was going to re-implement mine this evening as two separate processes using TCP comms, just for fun.

Title: Re: Advent of Code
Post by: Ben T on 19 December, 2017, 04:19:59 pm

Quote from: Greenbank on 19 December, 2017, 03:45:47 pm

Quote from: Ben T on 19 December, 2017, 01:55:07 pm

Quote from: Oaky on 18 December, 2017, 09:58:13 pm

(click to show/hide)

I haven't yet solved the threaded version's race condition though.  I'm finding it difficult to reliably tell from one thread whether the other thread is also blocked :/

(click to show/hide)

I've done 18b in a threaded way as well and I think it's always possible to make them deadlock at the 'wrong' place.
I've done a deadlock check by doing a test-lock-retest for whether the receive queue is empty, and if the other thread is also waiting on an empty queue, there's a deadlock.
However, it's always possible that if one thread races ahead and does, say, 100 or more lines before the other does any, then they get into a deadlock situation far before the 'latest possible' deadlock situation.
So most of the time my code generates the answer that was the first and only one I tried and which was accepted, 6958.  But 1 time out of 10 it will generate 127.
Could there have been multiple correct answers, I wonder?
It does say in the text "in fact, the programs don't even necessarily run at the same speed".
Not sure how to define 'race condition' in this case. I can prove that it deadlocks other than when at the 'maximum' right answer but not sure how to deem that wrong other than by forcing them to go at the same speed.
I think what would also prevent this 'race condition' would be to force them to go at similar speeds, but how 'similar' it needs to be is the question.

(click to show/hide)

I can't see how they can deadlock and produce anything but a single answer. The data they send is not dependent on anything timing related and must the be the same each time.

There can only be a deadlock when both queues are empty and both are attempting to receive. It's impossible to detect this from the other process if there are no other communication channels between the programs. A "haven't heard from it from 30 seconds, assuming it is also deadlocked" is about the best you can do without something that knows about the state of the other processes queue.

I was going to re-implement mine this evening as two separate processes using TCP comms, just for fun.

(click to show/hide)

No, I know it's impossible to detect IF there isn't comms between them. But I took it as a challenge to implement deadlock detection... by having some form of communication between them.
The basis of it is:

while (!ThisThreadsQueue.TryDequeue(out valReceived))
{
    bool monitorEntered = false;
    try
    {
        if (!(monitorEntered = Monitor.TryEnter(deadlockCheck)))
        {
            // a deadlock is detected - as we failed to read, but the other thread owns deadlockCheck - hence is also waiting
            OtherThreadsQueue.Enqueue(null); //so that it knows we have detected a deadlock and also stops
            OtherThreadsSemaphore.Release();
            throw new DeadlockException();
        }
        ThisThreadsSemaphore.WaitOne();
    }
    finally
    {
        if (monitorEntered) Monitor.Exit(deadlockCheck);
    }
}
if(valReceived == null) throw new DeadlockException(); //the other thread detected a deadlock, so we should also stop

// we read a value
p.Registers[p.P1] = valReceived.Value;

There must be a situation in which it can encounter a false positive when doing the deadlock check, but I can't think up a MCVE and a sequence of steps through it (i.e. how fast does one thread progress compared to the other) that nails it.

Title: Re: Advent of Code
Post by: David Martin on 19 December, 2017, 04:21:26 pm

Quote from: Greenbank on 19 December, 2017, 01:05:05 pm

Quote from: David Martin on 19 December, 2017, 11:59:55 am

Fortunately the input was well behaved, I had considered cases like two corners in consecutive steps, realised that the coding would be more involved and if it came across a not immediately tractable solution to print the local environment and ask for guidance. It didn't need to as there was at least one step between each corner.

Not sure why this would be a problem, there are no decisions to be made at any corners. Either you can continue on in a straight line still or you have to choose left or right (and there won't be a choice).

For example:-

Code: [Select]

  |
B++A
  ++

is unambiguous.

but

Code: [Select]

   ||||
   ++++
isn't unless you look further afield than immediately adjacent characters. I couldn't be bothered so just wrote a prompt in to look at it by eye and indicate where it should go

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2017, 04:35:52 pm

Quote from: Ben T on 19 December, 2017, 04:19:59 pm

(click to show/hide)

No, I know it's impossible to detect IF there isn't comms between them. But I took it as a challenge to implement deadlock detection... by having some form of communication between them.
The basis of it is:
...

(click to show/hide)

The race condition I can see is that you check to see if you can dequeue something without having anything locked, so the order could be:-

p0 check to see if anything on queue from p1, nothing
p1 puts something on queue for p0
p1 attempts a receive and checks to see if anything on queue from p0, nothing
p1 enters deadlock check code
p0 tries to enter deadlock check code but fails as p1 has it locked and so it all exits, despite there being something on p0's queue

(Based on a quick scan of that code...)

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2017, 04:39:13 pm

Quote from: David Martin on 19 December, 2017, 04:21:26 pm

but

Code: [Select]

   A|BC
   ++++
isn't unless you look further afield than immediately adjacent characters. I couldn't be bothered so just wrote a prompt in to look at it by eye and indicate where it should go

If you're coming down from A then it's unambiguous. You go down, turn left (as you can't turn right), to the end of that line (because you only turn when you can't continue straight on) and then the only choice is to turn left (up) to get to C.

Likewise coming down from C is unambiguous (C down, right, all the way to the end, right and up to A).

Coming down from B is ambiguous as you have a choice of which way to turn, but my reading of the instructions was that this was not going to occur since it didn't say what to do in such cases.

Title: Re: Advent of Code
Post by: Oaky on 19 December, 2017, 06:01:01 pm

Quote from: Greenbank on 19 December, 2017, 03:45:47 pm

Quote from: Ben T on 19 December, 2017, 01:55:07 pm

Quote from: Oaky on 18 December, 2017, 09:58:13 pm

(click to show/hide)

I haven't yet solved the threaded version's race condition though.  I'm finding it difficult to reliably tell from one thread whether the other thread is also blocked :/

(click to show/hide)

I've done 18b in a threaded way as well and I think it's always possible to make them deadlock at the 'wrong' place.
I've done a deadlock check by doing a test-lock-retest for whether the receive queue is empty, and if the other thread is also waiting on an empty queue, there's a deadlock.
However, it's always possible that if one thread races ahead and does, say, 100 or more lines before the other does any, then they get into a deadlock situation far before the 'latest possible' deadlock situation.
So most of the time my code generates the answer that was the first and only one I tried and which was accepted, 6958.  But 1 time out of 10 it will generate 127.
Could there have been multiple correct answers, I wonder?
It does say in the text "in fact, the programs don't even necessarily run at the same speed".
Not sure how to define 'race condition' in this case. I can prove that it deadlocks other than when at the 'maximum' right answer but not sure how to deem that wrong other than by forcing them to go at the same speed.
I think what would also prevent this 'race condition' would be to force them to go at similar speeds, but how 'similar' it needs to be is the question.

(click to show/hide)

I can't see how they can deadlock and produce anything but a single answer. The data they send is not dependent on anything timing related and must the be the same each time.

There can only be a deadlock when both queues are empty and both are attempting to receive. It's impossible to detect this from the other process if there are no other communication channels between the programs. A "haven't heard from it from 30 seconds, assuming it is also deadlocked" is about the best you can do without something that knows about the state of the other processes queue.

I was going to re-implement mine this evening as two separate processes using TCP comms, just for fun.

(click to show/hide)

The basis of my deadlock detection was to have two objects in each VM state... pseudo-code (aka pigeon-python):-

Code: [Select]

self.i_am_blocked
self.other_is_blocked

and connecting the programs involves cross-connecting these objects...

Code: [Select]

def connect(self, other):
    self.other_is_blocked = other.i_am_blocked

(as well as similarly connecting their send buffers...)

The deadlock detection then looks like

Code: [Select]

if self.i_am_blocked and self.other_is_blocked:
    # deadlocked
    <do deadlock stuffs here>

self.i_am_blocked gets set when I try to rcv, but my queue is empty.  I then go into a tight loop retrying the rcv, and testing for a deadlock each time round the loop.

self.i_am_blocked gets cleared when I sucessfully read a value from my queue^*.

I mostly see the threaded version giving me the same answer as the non-threaded, but sometimes it erroneously detects a deadlock early, giving me answers starting at 127 but sometimes higher (usually less than 1000, though).

---

( * ) I wondered if this might be the issue. Maybe instead I should have been clearing the other program's blocked status via self.other_is_blocked when I send a value to my queue?  Then again,  I think there's still scope for prog1 to try a rcv, fail, then prog0 do a snd, clearing clear the prog1 blocked flag before prog1 got round to got round to setting it with the net effect that prog1 thinks it's blocked (or at least looks blocked to prog0 via the self.other_is_blocked channel, but does in fact, have stuff in its queue.

Perhaps I need to either have a lock which the thread acquires when touching the send/receive/am I blocked code and releases once it's out of there.

Perhaps I should make one of the programs special based on it's program number and have only that program maintain (or just clear?) the blocked states?  I need to think about the failure modes of the non-atomicity of the receive adn blocked flag maintenance.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2017, 06:37:09 pm

Quote from: Oaky on 19 December, 2017, 06:01:01 pm

(click to show/hide)

self.i_am_blocked gets cleared when I sucessfully read a value from my queue^*.

...

---

( * ) I wondered if this might be the issue. Maybe instead I should have been clearing the other program's blocked status via self.other_is_blocked when I send a value to my queue?  Then again,  I think there's still scope for prog1 to try a rcv, fail, then prog0 do a snd, clearing clear the prog1 blocked flag before prog1 got round to got round to setting it with the net effect that prog1 thinks it's blocked (or at least looks blocked to prog0 via the self.other_is_blocked channel, but does in fact, have stuff in its queue.

...

(click to show/hide)

Yes, that's where the problem lies.

In your setup you could have p1 blocked waiting for a signal, and p0 sends a signal and then progresses to a rcv command (where nothing is ready to be received and so blocks itself) at which point it sees both p1 blocked (since it hasn't cleared its flag yet) and itself (p0) blocked, and triggers the exit.

And, yes, locks (mutexes/condition variables/etc) are the solution. Implementing them properly is left as an exercise for the reader.

Modifying who does what where will only move the problem and enable a different scenario that can lead to false deadlock detection, or highlight a problem that cannot be detected or prevented.

i.e. making a program repsonsible for clearing the other processes is_blocked flag, you would imagine it executes nice and linearly like this:-

p1 blocked
p0a sends message to p1
p0b clears p1's is_blocked status
p1 processes message
etc...

but what if it did:-

p1 blocked
p0a sends message to p1
p1 processes message
p1 executes another rcv command, nothing on queue, marks itself as blocked
p0b clears p1's is_blocked status
p0 waits for message (nothing on its queue)

now it's deadlocked and there's no deadlock detection

I think it's possible if you have a single shared mutex protecting access (both read and write) to the is_blocked variables and make the sending program clear the counterpart's is_blocked variable, but I haven't run through all of the scenarios. I'll see if I can implement it myself with perl's threads (with and without a mutex) and try and replicate the undefined behaviour.

[EDIT] Sorry, I keep editing the above, we need a YACF-AOC Slack channel. I've created one but would this be a good idea or do people want to keep the discussion here?

Title: Re: Advent of Code
Post by: Oaky on 19 December, 2017, 07:33:41 pm

I'd join a Slack channel.

(click to show/hide)

I fixed my threaded implementation. 

It was pretty simple in the end - a judicious sprinkling of "with lock:" blocks around the snd, rcv and deadlock detection code fixed it (https://github.com/MarkNOakden/AdventOfCode/blob/master/17/18/day18%20-%20fixing%20the%20threads.ipynb).



BTW - this is quite nice: Javascript 18b solver (https://xsmalldeadguyx.github.io/AoC17/day18p2.html)

Title: Re: Advent of Code
Post by: Oaky on 19 December, 2017, 07:50:26 pm

(click to show/hide)

I tried to second-guess the part 2 question while writing my MapWalker.  I thought that he was either going to ask for the number of times I crossed another pipe, or the number of turns I made, so I kept track of the times I went under another pipe and the times I changed direction.  I was wrong.  Number of steps was one metric I hadn't maintained during part 1.

This was one of those (there was at least one last year: Reindeer Medicine?) where I decided not to use a feature of the input and test data which wasn't explicitly a part of the description.  In both my input data and the example data, there are no examples where two pipes are directly side by side (they always have at least one space between - i.e. "| |" rather than "||").  The only difference it would have made to my code would have been in the crossing detection, though, so it's irrelevant anyway.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2017, 09:01:02 pm

(click to show/hide)

Quote from: Greenbank on 19 December, 2017, 06:37:09 pm

I think it's possible if you have a single shared mutex protecting access (both read and write) to the is_blocked variables and make the sending program clear the counterpart's is_blocked variable, but I haven't run through all of the scenarios. I'll see if I can implement it myself with perl's threads (with and without a mutex) and try and replicate the undefined behaviour.

Yep, as expected.

Without a mutex it randomly detects an early deadlock (at a whole load of values below the actual answer, not just 127). It works correctly about 1 in 10 times for me.

If I clear the is_blocked variable when sending (without mutex protection) it never detects a deadlock.

With a mutex, and protecting the send/receive code with that mutex, it works fine.

The horror: http://www.greenbank.org/misc/aoc/2017_18t_mutex.txt

(I should really minimise the snd/rcv stuff done inside the mutex lock.)

I hate perl threads/mutexes.

Title: Re: Advent of Code
Post by: Ben T on 19 December, 2017, 09:31:20 pm

Quote from: Greenbank on 19 December, 2017, 04:35:52 pm

Quote from: Ben T on 19 December, 2017, 04:19:59 pm

(click to show/hide)

No, I know it's impossible to detect IF there isn't comms between them. But I took it as a challenge to implement deadlock detection... by having some form of communication between them.
The basis of it is:
...

(click to show/hide)

The race condition I can see is that you check to see if you can dequeue something without having anything locked, so the order could be:-

p0 check to see if anything on queue from p1, nothing
p1 puts something on queue for p0
p1 attempts a receive and checks to see if anything on queue from p0, nothing
p1 enters deadlock check code
p0 tries to enter deadlock check code but fails as p1 has it locked and so it all exits, despite there being something on p0's queue

(Based on a quick scan of that code...)

(click to show/hide)

ah.... Yes I see, thanks, so I suppose I need to extend the test-lock-retest logic to the "is it deadlocked" test. Illustrates just how fiddly threading synchronization is.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2017, 10:43:52 pm

(click to show/hide)

And here's a hacky TCP version (uses 127.0.0.1 port 7777 for comms).

http://www.greenbank.org/misc/aoc/2017_18_tcp.txt

cat input | ./18_tcp.pl 0 &
cat input | ./18_tcp.pl 1 &

Or enable the various print statements that are commented out in the code and run them in separate terminal windows.

Deadlock detection is simply when a program hits a rcv and doesn't receive anything for 5 seconds.

Pre-exit sleep() is there to prevent p0 from exiting before p1 has finished checking the socket (since the code doesn't handle exceptions on sockets properly) and getting to its own exit code (and printing the answer).

Title: Re: Advent of Code
Post by: Greenbank on 20 December, 2017, 09:10:49 am

Relatively simple today (day 20).

(click to show/hide)

Was expecting many more iterations to be required. For my input part (a) settled down after 414 iterations and part (b) was done in just 38 iterations. I did 10,000 iterations just to be sure, takes a few seconds but wanted to be sure.

Will now look for an analytical method for part(a) rather than brute forcing it. I guess it'll work by looking at the minimum manhattan 'distances' of the accelerations first, then minimum manhattan distances of the velocities as a tie breaker, then minimum manhattan distances of the starting positions if there is a tie on those two.

[EDIT]
Thinking about it, it's not quite that simple when it comes to position...

p=< 3,0,0>, v=< 0,0,0>, a=<1,0,0>
p=< 4,0,0>, v=< 0,0,0>, a=<-1,0,0>

Same magnitude of acceleration and velocity but p1 will always be closer despite starting further away (because it first travels towards the origin rather than p0 which travels away).

[EDIT2] Doh. Missed the most obvious way of doing part a (no iterations required although still need to pick a number n rather than doing it purely analytically), but then I guess my brain was expecting a need to do it by iterations for part (b) (and doing part (b) non-iteratively would have been interesting...)

Title: Re: Advent of Code
Post by: David Martin on 20 December, 2017, 12:49:43 pm

I must have something wrong with my iterations as it is taking a long time and not finding collisions.

(click to show/hide)

I started by assuming that the lowest acceleration wins. But forgot to consider multiple equally low options. Having failed the first time it was trivial to find the alternative.

Title: Re: Advent of Code
Post by: David Martin on 20 December, 2017, 01:23:20 pm

*blush* Silly bug. Not updating z coordinate. Now solved.

Title: Re: Advent of Code
Post by: Diver300 on 20 December, 2017, 01:59:44 pm

Day 20
First part was solved with one run through the data.

(click to show/hide)

For this part the initial position isn't relevant.
I first thought that the speed wasn't relevant but if there is a tie on the acceleration, the initial velocity matters.
I ran through all particles finding the smallest Manhattan acceleration. For a tie, where any axis that had zero acceleration, the Manhattan total of the velocities was used to decide.

My plan probably only works where the smallest accelerations have zero accelerations in some axes.

Title: Re: Advent of Code
Post by: Greenbank on 20 December, 2017, 02:17:00 pm

Quote from: Diver300 on 20 December, 2017, 01:59:44 pm

Day 20
First part was solved with one run through the data.

(click to show/hide)

For this part the initial position isn't relevant.
I first thought that the speed wasn't relevant but if there is a tie on the acceleration, the initial velocity matters.
I ran through all particles finding the smallest Manhattan acceleration. For a tie, where any axis that had zero acceleration, the Manhattan total of the velocities was used to decide.

My plan probably only works where the smallest accelerations have zero accelerations in some axes.

(click to show/hide)

You can't ignore position. Consider this case:-

p=< 3,0,0>, v=< 0,0,0>, a=<1,0,0>
p=< 4,0,0>, v=< 0,0,0>, a=<-1,0,0>

Same magnitude of acceleration and velocity but p1 will always be closer (after the first iteration) despite starting further away (because it first travels towards the origin rather than p0 which travels away).

Title: Re: Advent of Code
Post by: Diver300 on 20 December, 2017, 02:47:23 pm

Quote from: Greenbank on 20 December, 2017, 02:17:00 pm

Quote from: Diver300 on 20 December, 2017, 01:59:44 pm

Day 20
First part was solved with one run through the data.

(click to show/hide)

For this part the initial position isn't relevant.
I first thought that the speed wasn't relevant but if there is a tie on the acceleration, the initial velocity matters.
I ran through all particles finding the smallest Manhattan acceleration. For a tie, where any axis that had zero acceleration, the Manhattan total of the velocities was used to decide.

My plan probably only works where the smallest accelerations have zero accelerations in some axes.

(click to show/hide)

You can't ignore position. Consider this case:-

p=< 3,0,0>, v=< 0,0,0>, a=<1,0,0>
p=< 4,0,0>, v=< 0,0,0>, a=<-1,0,0>

Same magnitude of acceleration and velocity but p1 will always be closer (after the first iteration) despite starting further away (because it first travels towards the origin rather than p0 which travels away).

True. I'm not claiming that my algorithm for part 1 would work with all possible inputs.

Title: Re: Advent of Code
Post by: Oaky on 20 December, 2017, 03:10:29 pm

(click to show/hide)

hmm... my part 2 is not working and I don't know why.

It works fine on the example, and seems to converge on my input in 36 iterations, but the answer is not accepted.

On my own input, I don't see any collisions that arent simply pairs of particles, although my algorithm does detect the three way collision in the example.

Code: [Select]

iteration        1: count = 1000
iteration       10: count = 998
iteration       18: count = 996
iteration       35: count = 994
iteration       36: count = 992
and there it sits....  ???

Title: Re: Advent of Code
Post by: Greenbank on 20 December, 2017, 03:47:55 pm

(click to show/hide)

More than 40% of my particles collided. Sometimes as many as 9 at once.

8 in total seems very few.

PM me your input (or email - alex @ <yacfusername> . org) and I'll give you a co-ordinate where lots of stuff happens. (If you want that kind of help.)

Title: Re: Advent of Code
Post by: Pickled Onion on 20 December, 2017, 07:47:45 pm

(click to show/hide)

There were a number of schoolboy errors that were easy to slip up on in part 2. I thought I'd got them all, and the test data was working well, but I forgot that even if you put integers as the keys of a perl hash it will still sort lexically. Oops.

But yes, there will be more than 8 collisions. I had ~350, and up to 26 at once.

So Oakers, what's your strategy?

Title: Re: Advent of Code
Post by: Diver300 on 20 December, 2017, 09:06:48 pm

Day 20 b

(click to show/hide)

I gave each particle a collision time, starting at a large number.
I through each particle 3 times for each time interval
First to detect collisions by comparing each particle's positions with each other particles, where the collision time of the other was >= current time
If there was a match, the collision time was set to current time.

Second time through I did the newtonian dynamics

Third time though I counted the uncollided particles.

I just ran and displayed 100 time intervals. Everything stopped changing at about 40.

Interestingly, all collisions were within a Manhattan distance of 127 of the origin.

Title: Re: Advent of Code
Post by: David Martin on 20 December, 2017, 09:39:18 pm

(click to show/hide)

I created a list of particles. I then created a list of indexes of the list of particles.
I then check the positions of all the particles in the list of indices with a hash (by hashing the position and adding to the list of particles at that position) and iterate the particle as I check it's position.
If the list of positions is shorter than the list of current particles (the list of indices) then I remove from the list of indices every particle that is in a position list longer than 2.

Repeat till a convergence criteria is reached (number of consecutive steps with no collisions). If I was keen I could set a smaller convergence criteria and check that particles are not converging as a limit. But I didn't.

All code on github at https://github.com/davidmam/aoc2017

Title: Re: Advent of Code
Post by: Greenbank on 20 December, 2017, 10:27:04 pm

(click to show/hide)

I parsed the last of particles and created a multi-dimensional array, one row per particle (so the row index is particle number since they started at 0) and columns for: px, py, pz, vx, vy, vz, ax, ay, az
I also create a perl hash (a.k.a. dict in most other languages) to hold the particle numbers that have collided and are out of the game.
each iteration:-
__initialise an empty perl hash to store the location of each particle (this is initialised each iteration)
__for each particle that has not already been marked as collided (this is just checking for non-existence of a key in the hash)
____calculate its new velocity (vx+=ax; vy+=ay; vz+=az;)
____calculate its new position (px+=vx; py+=vy; pz+=vz;)
____check if position as a comma separated string exists in the location hash (e.g. "1,2,7")
______if it doesn't then store the particle's location in the location hash with the value being the particle number, e.g. "1,2,7" -> 0
______if it does match then the current particle is marked as collided and so is the particle number stored in the location hash for this position
At the end of the code I just have to count the number of keys in the collided hash to see how many particles collided, and take this away from the total number of particles to get the answer

I could easily have stored the collided state as a 10th column in the original array, but storing it in a hash meant I could count the number of entries with a simple bit of code 'scalar(keys %collided)' rather than having to loop through the array to count them.

Title: Re: Advent of Code
Post by: Ben T on 20 December, 2017, 11:50:29 pm

 how have you all identified the state where won't be any more collisions for part b, ( or changes in closest to origin for a)?
Did you identify merely a point at which there probably won't be any more or that there can't possibly be?

(click to show/hide)

I identified a "quiescent" state where all the particles have the same sign of p, v and a (but obviously not as each other) (thus are moving and accelerating away from the origin) and also that the particle with the lowest magnitude of position also has the lowest magnitude of velocity, thus can't possibly ever "overtake" another one. That seems to work for b as well but thinking about it I can't see how it proves there can't ever be another collision, only that the closest one will always remain so.

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2017, 08:50:04 am

Day 21 looking meaty...

(click to show/hide)

I didn't bother looking to identify whether there was a chance of another collision.
I didn't see any more collisions after 38 iterations, and ran it for 10,000. Since the answer I posted was correct I never bothered doing any more work on it.
But, yes, it would be quite easy to contrive an input with a single pair of particles that didn't collide for hundreds of thousands of steps just to catch people out.

Title: Re: Advent of Code
Post by: David Martin on 21 December, 2017, 09:23:33 am

Definitely requiring more thought. First time this year in the top 1000

(click to show/hide)

OK, this took some thinking. Eventually I determined a solution and then part b was a simple extension.
There are at maximum 8 transformations for each pattern including the identity. By generating a list of transforms and then applying them in turn to each cell until one matched a transformation key, it was straightforward.

I could have generated a hash of all possible patterns from the input data and my list of transforms - that would have saved some time and made the code a bit more compact.

(click to show/hide)

There is a temptation with a small number of iterations to try and shortcut. The full version doesn't take long unoptimised (a few seconds)

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2017, 09:54:57 am

Day 21.

Correct answer for part (a), wrong answer for part (b).

The madness begins.

Title: Re: Advent of Code
Post by: David Martin on 21 December, 2017, 10:17:42 am

Off by one in your iteration count?

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2017, 11:33:36 am

Quote from: David Martin on 21 December, 2017, 10:17:42 am

Off by one in your iteration count?

Nope, more serious than that, but I got it (took me about 20 minutes to find it but I've been doing some real work for the last couple of hours). 43 minutes from submitting part (a) to submitting part (b). Ugh.

(click to show/hide)

Added some test cases for the various functions.
My rotate/flip functions where fine, but I had functions to split up a big grid into smaller grids and also combine the smaller resulting grids into one big grid again.
split: ABC/DEF/GHI -> A,B,C,D,E,F,G,H,I
combine: A,B,C,D,E,F,G,H,I -> ABC/DEF/GHI

x wasn't the same as combine(split(x)). I'd flipped the x and y coordinates in the combine routine and it was doing:-

split: ABC/DEF/GHI -> A,B,C,D,E,F,G,H,I
combine: A,B,C,D,E,F,G,H,I -> ADG/BEH/CFI

With it fixed it produced the right answer. It didn't affect the answer of the output up to 5 iterations.

I'm wondering about optimisations now, mine isn't particularly fast (48s) as most of the time is spent splitting and combining strings. Of course # and . translate well to binary so I'm tempted to try implement it with bit bashing but that will be interesting with the boxes being split across multiple rows.

I got a reasonable speed up (113s to 48s) by adding rules for each of the translations as I found them, i.e. if there is no rule for x but there is for rotate(fliph(x)) -> Z then add x -> Z as a rule.
[EDIT] It doesn't get any noticably faster (well from 48s to 47s) by adding all of the rules/transformations at the start when reading the input (so no need to do any during the iterations).

So it's my storage method and implementation of the conversions/manipulations that is particularly slow.

Title: Re: Advent of Code
Post by: Oaky on 21 December, 2017, 02:13:36 pm

Quote from: Greenbank on 21 December, 2017, 11:33:36 am

Quote from: David Martin on 21 December, 2017, 10:17:42 am

Off by one in your iteration count?

Nope, more serious than that, but I got it (took me about 20 minutes to find it but I've been doing some real work for the last couple of hours). 43 minutes from submitting part (a) to submitting part (b). Ugh.

(click to show/hide)

Added some test cases for the various functions.
My rotate/flip functions where fine, but I had functions to split up a big grid into smaller grids and also combine the smaller resulting grids into one big grid again.
split: ABC/DEF/GHI -> A,B,C,D,E,F,G,H,I
combine: A,B,C,D,E,F,G,H,I -> ABC/DEF/GHI

x wasn't the same as combine(split(x)). I'd flipped the x and y coordinates in the combine routine and it was doing:-

split: ABC/DEF/GHI -> A,B,C,D,E,F,G,H,I
combine: A,B,C,D,E,F,G,H,I -> ADG/BEH/CFI

With it fixed it produced the right answer. It didn't affect the answer of the output up to 5 iterations.

I'm wondering about optimisations now, mine isn't particularly fast (48s) as most of the time is spent splitting and combining strings. Of course # and . translate well to binary so I'm tempted to try implement it with bit bashing but that will be interesting with the boxes being split across multiple rows.

I got a reasonable speed up (113s to 48s) by adding rules for each of the translations as I found them, i.e. if there is no rule for x but there is for rotate(fliph(x)) -> Z then add x -> Z as a rule.
[EDIT] It doesn't get any noticably faster (well from 48s to 47s) by adding all of the rules/transformations at the start when reading the input (so no need to do any during the iterations).

So it's my storage method and implementation of the conversions/manipulations that is particularly slow.

(click to show/hide)

fun with functions and composition etc.

My solution took 14s for part 2.

I pre-generated all the rotated/flipped rules and used a list of lists of chars for the grids and a list of lists of grids when splitting.

I particularly enjoyed making the symmetry transformations as function compositions...

Code: [Select]

def compose(f,g):
    def new(x):
        return f(g(x))
    return new

def vflip(g):
    return list(reversed(g))

def hflip(g):
    return list(map(lambda x: list(reversed(x)), g))

def transpose(g):
    return list(map(list, zip(*g)))

def e(g):
    # identity element
    return g

r90 = compose(transpose, vflip)
r180 = compose(hflip, vflip)
r270 = compose(transpose, hflip)
neswflip = compose(vflip, r90)
nwseflip = compose(hflip, r90)

all_transforms = [e, r90, r180, r270, hflip, vflip, neswflip, nwseflip] # symmetry group of square

def fapply(flist, arg):
    '''apply a list of functions to an argument, returning the list of results
    fapply([f, g, h], x) => [f(x), g(x), h(x)]'''
    return list(map(lambda x: x(arg), flist))

https://github.com/MarkNOakden/AdventOfCode/blob/master/17/21/day21.ipynb

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2017, 03:07:09 pm

Down to 30s for 21.b. I'd left my test code in there so I was doubling up on the expensive split/combine work for each iteration.

Will work on ways to get this down to <1s if I can in-between bouts of RealWork(TM).

[EDIT] 17s after simplifying some of the steps, still a way to go.
[EDIT] 15.38s and I think I know how to remove a lot of the complexity from here
[EDIT] 5.23s and much simpler now too, enthusiasm for further refactoring is waning

Title: Re: Advent of Code
Post by: David Martin on 21 December, 2017, 03:12:14 pm

Calculating part 2 from scratch took <20secs with my rather naive implementation. Adding in the minor optimisation of adding patterns as you find them took it down to sub 14s from scratch.

(click to show/hide)

I have a function expand(grid) that does what it says on the tin. The timing is of a loop where grid is the initial start and the loop is:

Code: [Select]

for i in range(18):
    grid = expand(grid)

print(sum([x.count('#') for x in grid]))


Title: Re: Advent of Code
Post by: Ben T on 21 December, 2017, 04:27:58 pm

55 seconds. Probably some optimizations but possibly marginal gains.
Was hoping it would  create a christmas tree but it didn't.

(click to show/hide)

edit: in fact definitely one optimization which could make a big difference, namely equating cache keys with similar (rotated/flipped) ones.

Title: Re: Advent of Code
Post by: Oaky on 21 December, 2017, 05:10:14 pm

(click to show/hide)

(http://www.oakden.org/mark/bike/yacf/pics/part2_18.png)
click for animated GIF (large file ~6MB!) (http://www.oakden.org/mark/bike/yacf/pics/day21part2.gif)

Title: Re: Advent of Code
Post by: Diver300 on 21 December, 2017, 11:55:15 pm

Day 21, part 2 took my computer 4.637 seconds

(click to show/hide)

That's running in Javascript under Chrome on a 10 year old MacBook

I copied the 2 -> 3 transformation so that there were 16 of them, and I could convert the 4 pixels to binary and do a direct look up.

For the 3 -> 4 transformations, I wrote a rotate function and a flip function.
I converted each input pattern into a number in binary, and found which combination of rotates and flips gave the largest value.
That gave me a lookup table of largest input value to output pattern, which only had to be done once at the start of the programme. Each time I had to transform a 3x3 square, I worked out the largest value its transformed bits could represent, and the lookup of that value gave the 4x4 pattern.

For 5 iterations I got it to output a pattern, and I counted the hashes with a text editor. That didn't work for 18, but all I needed was to get the code to count the hashes and it ran reasonably quickly.

Title: Re: Advent of Code
Post by: Oaky on 22 December, 2017, 12:47:27 am

(click to show/hide)

day 21 was a puzzle of the type I really like since I could define the small steps that got me closer and closer to the solutiojj an implement those incrementally (I should have done it TDD the whole way with unittest module, but didnt bother this time).

Day 20, on the other hand, is really annoying me because I think I understand it fully, and I think my code is doing exactly what I want it to do, but my answer is wrong (and also "feels" wrong - I would really expect more collisions than I'm finding, and definitely some multi-way ones.)

Code: [Select]

Collision between particles:
p0 p1 p2 v0 v1 v2 a0 a1 a2
395 13 -27 530 106 -185 89 4 -17 8
401 13 -27 530 -103 -6 89 -2 -11 8

iteration       10: count = 998

Collision between particles:
p0 p1 p2 v0 v1 v2 a0 a1 a2
306 30 -14 728 -9 182 74 1 14 4
314 30 -14 728 -144 12 74 -12 5 4

iteration       18: count = 996

Collision between particles:
p0 p1 p2 v0 v1 v2 a0 a1 a2
471 -8 -15 700 -338 -361 37 -11 -7 1
473 -8 -15 700 547 231 37 15 6 1

iteration       35: count = 994

Collision between particles:
p0 p1 p2 v0 v1 v2 a0 a1 a2
212 -49 33 72 -299 72 2 -8 4 0
213 -49 33 72 -278 -148 2 -9 -1 0

iteration       36: count = 992


Title: Re: Advent of Code
Post by: David Martin on 22 December, 2017, 09:12:45 am

(click to show/hide)

I'm normally not this directionally challenged. But got there and found my initial solution was readily adaptable for part 2 with minimal changes (just the cell state change changed).

not fast but it gets there in a few seconds.

Title: Re: Advent of Code
Post by: Ben T on 22 December, 2017, 11:56:18 am

(click to show/hide)

Hmm, quite easy really. I think the only challenge of day 22 relies on you not knowing how to implement a potentially infinite grid.
https://github.com/bjtaylor1/AoC2017/blob/day22part2/Day22/Program.cs

Title: Re: Advent of Code
Post by: Greenbank on 22 December, 2017, 12:33:25 pm

Quote from: Ben T on 22 December, 2017, 11:56:18 am

(click to show/hide)

Hmm, quite easy really. I think the only challenge of day 22 relies on you not knowing how to implement a potentially infinite grid.
https://github.com/bjtaylor1/AoC2017/blob/day22part2/Day22/Program.cs

Late to it today as I was helping set up a family party.

(click to show/hide)

I used a 1000x1000 grid and plonked the initial map starting at 500,500.

I then got the wrong answers because I started from 500,500 rather than in the middle of the supplied map as the instructions clearly state. Doh.

I was hoping it wouldn't get far enough out for 1000x1000 not to be big enough, for my puzzle input it ranges: x=[348,709] and y=[270,692] so it turned out to be a good enough guess.

Title: Re: Advent of Code
Post by: David Martin on 22 December, 2017, 12:58:06 pm

(click to show/hide)

I started with the original grid at 0,0 and then kept track of all the points I had visited with a hash. I first set the new cell to clear, then checked to see whether I had been there (in which case it took that value. If I hadn't visited and it was on the grid, I took the initial grid value.

It was then just a case of starting in the right place, moving in the right direction, and knowing my left from my right.

They have been a little bit samey. Maybe a new thread with some 'extra' puzzles on?

Title: Re: Advent of Code
Post by: Greenbank on 22 December, 2017, 01:22:29 pm

(click to show/hide)

I was expecting part (b) of today to be "what is the fewest number of steps/burts/whatever that would leave no infected nodes?" or similar. That could have been truly horrid.

Title: Re: Advent of Code
Post by: Ben T on 22 December, 2017, 03:15:11 pm

Quote from: David Martin on 22 December, 2017, 12:58:06 pm

(click to show/hide)

I started with the original grid at 0,0 and then kept track of all the points I had visited with a hash. I first set the new cell to clear, then checked to see whether I had been there (in which case it took that value. If I hadn't visited and it was on the grid, I took the initial grid value.

It was then just a case of starting in the right place, moving in the right direction, and knowing my left from my right.

They have been a little bit samey. Maybe a new thread with some 'extra' puzzles on?

Agree, unlike last year, there hasn't been any this year that I have found hard. Some fairly 'involved', that took a few hours, but nothing more than that.

Title: Re: Advent of Code
Post by: David Martin on 22 December, 2017, 03:27:44 pm

OK, new thread started. I'll throw some data up for the first in due course.

Title: Re: Advent of Code
Post by: Pickled Onion on 22 December, 2017, 03:46:55 pm

(click to show/hide)

Interesting reading the different approaches.

I just started with the map, centre=(0,0) and whenever my virus went to step off the edge I called the expand() function. All changes made in-place as there's no need to know the previous state of infection.

Title: Re: Advent of Code
Post by: Ben T on 22 December, 2017, 04:01:28 pm

(click to show/hide)

Quote from: Pickled Onion on 22 December, 2017, 03:46:55 pm

Interesting reading the different approaches.

I just started with the map, centre=(0,0) and whenever my virus went to step off the edge I called the expand() function. All changes made in-place as there's no need to know the previous state of infection.

I didn't even have a map.... just a 'bag' of nodes, each with X and Y position, which can be anything.
If it moves to a node that doesn't currently yet exist, it just creates one and it starts off in the default state of 'clean' (as specified).
The limits of the (imagined) "matrix" are simply the lowest/highest X and Y positions that happen to currently exist in the bag.
My (imagined) "matrix" is thus probably very rarely square or even regular shaped.

Title: Re: Advent of Code
Post by: Pickled Onion on 22 December, 2017, 06:35:40 pm

Quote from: Ben T on 22 December, 2017, 04:01:28 pm

(click to show/hide)

Quote from: Pickled Onion on 22 December, 2017, 03:46:55 pm

Interesting reading the different approaches.

I just started with the map, centre=(0,0) and whenever my virus went to step off the edge I called the expand() function. All changes made in-place as there's no need to know the previous state of infection.

I didn't even have a map.... just a 'bag' of nodes, each with X and Y position, which can be anything.
If it moves to a node that doesn't currently yet exist, it just creates one and it starts off in the default state of 'clean' (as specified).
The limits of the (imagined) "matrix" are simply the lowest/highest X and Y positions that happen to currently exist in the bag.
My (imagined) "matrix" is thus probably very rarely square or even regular shaped.

(click to show/hide)

Eh? The puzzle input was a map even if you squish it to a bunch of nodes. But you are right, there was no need to extend the given map, everything outside is is clean. I guess I just did that to make it easier to print it out for the test cases.

Title: Re: Advent of Code
Post by: David Martin on 22 December, 2017, 07:59:19 pm

I did the same as Ben T.

(click to show/hide)

You just need to knwo where you have been and a limited subset of starting positions. So a hash of positions makes sense. Don't need to keep an entire map in memory.

Title: Re: Advent of Code
Post by: Oaky on 22 December, 2017, 10:09:35 pm

Quote from: Oaky on 22 December, 2017, 12:47:27 am

(click to show/hide)

day 21 was a puzzle of the type I really like since I could define the small steps that got me closer and closer to the solutiojj an implement those incrementally (I should have done it TDD the whole way with unittest module, but didnt bother this time).

Day 20, on the other hand, is really annoying me because I think I understand it fully, and I think my code is doing exactly what I want it to do, but my answer is wrong (and also "feels" wrong - I would really expect more collisions than I'm finding, and definitely some multi-way ones.)

Code: [Select]

Collision between particles:
p0 p1 p2 v0 v1 v2 a0 a1 a2
395 13 -27 530 106 -185 89 4 -17 8
401 13 -27 530 -103 -6 89 -2 -11 8

iteration       10: count = 998

Collision between particles:
p0 p1 p2 v0 v1 v2 a0 a1 a2
306 30 -14 728 -9 182 74 1 14 4
314 30 -14 728 -144 12 74 -12 5 4

iteration       18: count = 996

Collision between particles:
p0 p1 p2 v0 v1 v2 a0 a1 a2
471 -8 -15 700 -338 -361 37 -11 -7 1
473 -8 -15 700 547 231 37 15 6 1

iteration       35: count = 994

Collision between particles:
p0 p1 p2 v0 v1 v2 a0 a1 a2
212 -49 33 72 -299 72 2 -8 4 0
213 -49 33 72 -278 -148 2 -9 -1 0

iteration       36: count = 992


Got it!

My code was doing exactly what I expected, apart from the input data importer, which had a mistake in my regexp so that I was truncating the z coordinates to one digit only.

(click to show/hide)

The clue was that when I was seeing collisions, there were several near misses with identical x and y but slightly different z coordinates

Title: Re: Advent of Code
Post by: David Martin on 23 December, 2017, 09:26:58 am

Day 23 part A is straightforward

Part B:

(click to show/hide)

You need to work out what h is actually counting rather than trying to make the process faster.

(click to show/hide)

h is only incremented when f is 0. f is set to zero unless there is no e for which b is exactly divisible, ie b is prime.
The b to test are in steps of 17 (in my input) over a range of 17000.

I can count the number of times b is divisible by any integer less than sqrt(c)
but that gives me the wrong answer (too high).
What have I missed?
An off by one would give me a number that is too low.

ETA: Where was I going wrong? An inability to count the number of zeros. *blush*
And then an off by one errror

Title: Re: Advent of Code
Post by: Pickled Onion on 23 December, 2017, 10:16:08 am

(click to show/hide)

That's quite a spoiler. Took me a while to convert to code then optimise, then realise what the algorithm was  :facepalm:

Title: Re: Advent of Code
Post by: David Martin on 23 December, 2017, 10:34:24 am

Quote from: Pickled Onion on 23 December, 2017, 10:16:08 am

(click to show/hide)

That's quite a spoiler. Took me a while to convert to code then optimise, then realise what the algorithm was  :facepalm:

That is why it is in (ETA: now multiple) spoiler tags.

Title: Re: Advent of Code
Post by: Pickled Onion on 23 December, 2017, 11:34:22 am

(click to show/hide)

This is what I did while trying to work out why your solution didn't work and mine did. Golf: 73 characters:

(click to show/hide)

for($b=105700;$b<=122700;$b+=17){$h++if grep!($b%$_),(2..sqrt$b);}print$h;

shorter without the sqrt, but slower for the usual grep reasons.

Title: Re: Advent of Code
Post by: David Martin on 23 December, 2017, 11:45:42 am

(click to show/hide)

len([x for x in range(105700,122701,17) if [y for y in range(2,1012) if x%y ==0]])

Title: Re: Advent of Code
Post by: Pickled Onion on 23 December, 2017, 11:53:14 am

Neat  ;)

Title: Re: Advent of Code
Post by: Diver300 on 23 December, 2017, 12:39:10 pm

Day 23 part 2

(click to show/hide)

Quote from: David Martin on 23 December, 2017, 09:26:58 am

And then an off by one error

I had worked out that the code went round 1000 times, but only when I cut down to trivial¹ numbers did I work out that the code actually executes for the first and the last of the 1000 times, so the answer is 1001 -

(click to show/hide)

the number of primes in the range

Once I worked out correctly what was going on, I used a spreadsheet to find the answer.

1) FCVO trivial. Around 2.5 million lines executed.

Title: Re: Advent of Code
Post by: Greenbank on 23 December, 2017, 01:28:59 pm

Thankfully I chose wisely at the start of today's challenge.

(click to show/hide)

It's a choice of writing an interpreter, or transposing the code directly into perl (with goto statements!).

I find it much easier with the latter to work back from individual statements to the underlying algorithm, i.e. replacing blocks of code with a jnz at the end with a do/while loop (I know it's a for loop really but, for some reason, I don't use for loops often if ever).

My day23b code ended up as:

(click to show/hide)

$b=107900;
$c=107900+17000;

do {
        $f=0;
        $d=2;
        if( prime( $b ) ) {
                $f=1;
        }
        if( $f == 0 ) {
                $h++;
        }
        $g=$b-$c;
        $b+=17;
} while( $g != 0 );
print "h=$h\n";
# isprime definition elided...

[EDIT] This is obviously far from optimal, it's just where mine ended up as I was working on simplifying it. I'll see if I can knock up an animated gif of the various stages (depends on how tricky tomorrows puzzles are).

Title: Re: Advent of Code
Post by: Ben T on 23 December, 2017, 03:35:40 pm

(click to show/hide)

on mine, the registers at line 28 (at the point of evaluating whether to quit, as whether g == 0) go:
1   109900   126900   109900   109900   0   -17000   1
1   109917   126900   109917   109917   0   -16983   2
1   109934   126900   109934   109934   0   -16966   3
1   109951   126900   109951   109951   0   -16949   4
1   109968   126900   109968   109968   0   -16932   5
1   109985   126900   109985   109985   0   -16915   6
1   110002   126900   110002   110002   0   -16898   7
1   110019   126900   110019   110019   0   -16881   8
1   110036   126900   110036   110036   0   -16864   9
1   110053   126900   110053   110053   0   -16847   10
extrapolating in excel, they should (but obviously don't) finish
1   126815   126900   126815   126815   0   -85   996
1   126832   126900   126832   126832   0   -68   997
1   126849   126900   126849   126849   0   -51   998
1   126866   126900   126866   126866   0   -34   999
1   126883   126900   126883   126883   0   -17   1000
1   126900   126900   126900   126900   0   0   1001

but I put 1001 in and it was wrong (too high).  :-\
So have translated it to C++ and set it grinding away, hopefully it will have stopped by the time I come back from the gym  :D

Title: Re: Advent of Code
Post by: Pickled Onion on 23 December, 2017, 03:47:41 pm

With my numbers, the first time f was not 0 was at row 38 in a table similar to yours.

Title: Re: Advent of Code
Post by: Pickled Onion on 23 December, 2017, 03:51:35 pm

I've not done 21, so now my circuit shows the connections for 22 & 23 but won't light up.  :-[

Title: Re: Advent of Code
Post by: David Martin on 23 December, 2017, 05:06:37 pm

(click to show/hide)

Look at the code. You will see that the increment of h is dependent on f. Look again at the code and determine when f is set to 1 and under which conditions it is reset to zero. There are conditions where it is not reset to zero so h is not incremented.

Title: Re: Advent of Code
Post by: David Martin on 23 December, 2017, 05:28:03 pm

The different patterns in the circuit are getting more creative. Just had a chip labelled 1.21GW - must be a flux capacitor.

Title: Re: Advent of Code
Post by: Ben T on 23 December, 2017, 07:04:12 pm

Quote from: David Martin on 23 December, 2017, 05:06:37 pm

(click to show/hide)

Look at the code. You will see that the increment of h is dependent on f. Look again at the code and determine when f is set to 1 and under which conditions it is reset to zero. There are conditions where it is not reset to zero so h is not incremented.

(click to show/hide)

I have 'decompiled' it to the following, which may have errors but I don't think so.
It zeros f and thus increments h when d*e == b. I mean i'm picking up on clues that it's trying to test whether something's prime.
In the case that it zeros f then b can't be prime. So b is the one it's trying to test for primeness?
But for me it's a bit of a leap of faith chopping out the entire middle and replacing it with a primeness test, as it's unclear what effects on the outside loop I'm also removing invalidly. But I'll see if it works anyhow.
Surely it's incrementing h when b isn't prime  as that is when f == 0? not sure if i've got that the wrong way round.

Cheers for the pointers

So
   int b = 0, c = 0, d = 0, e = 0, f = 0, g = 0, h = 0;

b = 99;
c = b;
b *= 100;
b -= -100000;
c = b;
c -= -17000;
do {
   f = 1;
   d = 2;
   do {
      e = 2;
      do {
         g = d * e - b;
         if (d*e == b)
         {
            f = 0;
         }
         e++;
         g = e - b;
      } while(e != b);
      d++;
      g = d - b;
   } while(g != 0);

   if (f == 0)  h++;
   g = b - c;
   if (g == 0) break;
   b -= -17;
}
while(true);
line32: std::cout << h;
   return 0;

Title: Re: Advent of Code
Post by: Ben T on 23 December, 2017, 07:18:11 pm

Quote from: Ben T on 23 December, 2017, 07:04:12 pm

Quote from: David Martin on 23 December, 2017, 05:06:37 pm

(click to show/hide)

Look at the code. You will see that the increment of h is dependent on f. Look again at the code and determine when f is set to 1 and under which conditions it is reset to zero. There are conditions where it is not reset to zero so h is not incremented.

(click to show/hide)

I have 'decompiled' it to the following, which may have errors but I don't think so.
It zeros f and thus increments h when d*e == b. I mean i'm picking up on clues that it's trying to test whether something's prime.
In the case that it zeros f then b can't be prime. So b is the one it's trying to test for primeness?
But for me it's a bit of a leap of faith chopping out the entire middle and replacing it with a primeness test, as it's unclear what effects on the outside loop I'm also removing invalidly. But I'll see if it works anyhow.
Surely it's incrementing h when b isn't prime  as that is when f == 0? not sure if i've got that the wrong way round.

Cheers for the pointers

So
   int b = 0, c = 0, d = 0, e = 0, f = 0, g = 0, h = 0;

b = 99;
c = b;
b *= 100;
b -= -100000;
c = b;
c -= -17000;
do {
   f = 1;
   d = 2;
   do {
      e = 2;
      do {
         g = d * e - b;
         if (d*e == b)
         {
            f = 0;
         }
         e++;
         g = e - b;
      } while(e != b);
      d++;
      g = d - b;
   } while(g != 0);

   if (f == 0)  h++;
   g = b - c;
   if (g == 0) break;
   b -= -17;
}
while(true);
line32: std::cout << h;
   return 0;

(click to show/hide)

Well , complete guess. I replaced it with

bool isprime(int b)
{
   for(int i = 2; i < b/2; i++)
      if (b % i == 0) return false;
   return true;
}

int main()
{
   int mul = 0;
   int b = 0, c = 0, d = 0, e = 0, f = 0, g = 0, h = 0;

b = 99;
c = b;
b *= 100;
b -= -100000;
c = b;
c -= -17000;
do {
   if(!isprime(b))  h++;
   if (b == c) break;
   b -= -17;
}
while(true);
line32: std::cout << h;
   return 0;

and it returned the right answer immediately.

Still feels like a bit of a guess though. Could you tell that calculating primeness is ALL it was doing, or just assumed that that was the extent of the algorithm by what it looked like, when squinting ;) ?
I remember the decompilation one last year was the only one I did by hook or by crook. The only one where you have to analyze the input rather than let your code process it regardless of what it is.

Title: Re: Advent of Code
Post by: David Martin on 23 December, 2017, 08:06:12 pm

(click to show/hide)

I could see that any case where d*e == b it would be zero. The only cases where that is not possible is where b is prime and I could see no other point at which f is set.
I could see that f is reset for each increment in b but not otherwise. So I stepped through b in increments of 17 and counted the non-prime numbers. This gave the right answer (when I remembered to include the last number. off by one otherwise :) )

Title: Re: Advent of Code
Post by: Pickled Onion on 24 December, 2017, 08:59:05 am

Quote from: Ben T on 23 December, 2017, 07:18:11 pm

(click to show/hide)

Still feels like a bit of a guess though. Could you tell that calculating primeness is ALL it was doing, or just assumed that that was the extent of the algorithm by what it looked like, when squinting ;) ?
I remember the decompilation one last year was the only one I did by hook or by crook. The only one where you have to analyze the input rather than let your code process it regardless of what it is.

(click to show/hide)

The way I did it was to turn each of the instructions into a language I know. Then I ran it with some small but more interesting numbers than the case where a=0; Then I combined/simplified instructions step by step, checking the output at the end of each outer loop didn't change. By getting rid of the fluff it eventually became clear.

It would have been quicker to analyse the code like Dr Dave did, but I didn't trust myself not to miss something among the various loops.

Title: Re: Advent of Code
Post by: Pickled Onion on 24 December, 2017, 09:06:46 am

Day 24 a bit more interesting, but not complicated.

(click to show/hide)

Keeping every bridge rather than optimising made part 2 an easy addition of a couple of lines

Title: Re: Advent of Code
Post by: Greenbank on 24 December, 2017, 09:32:05 am

(click to show/hide)

Yep, nothing amazing about today.

It took my quickly hacked up naive brute force implementation just 33s to run through every possible combination (with no optimisation or early pruning) so dealing with part b was similarly trivial.

I might get around to optimising it later, there are a few fairly obvious ways to make it run a lot faster.

[EDIT] Exhaustive search now down to 1.69s, that'll do me.

Title: Re: Advent of Code
Post by: Croft on 24 December, 2017, 12:27:01 pm

Day 24

(click to show/hide)

Even though the solution doesn't require it, do you think there is any way to prune the search tree? I can't think of any way to do so because this is a longest rather than shortest path problem and the overall strongest bridge  isn't necessarily found by always selecting the strongest available segment:

e.g.

0/1
0/2
1/5
2/2

Title: Re: Advent of Code
Post by: David Martin on 24 December, 2017, 01:42:21 pm

(click to show/hide)

I built a simple node and tree searching depth first recursive algorithm that was easy to modify for part b. I can't see how to realistically optimise it by pruning as the total available bridgery is always going to add up to the same score.

It didn't take long to search every combination and my maximum length was 40 (with lots of alternatives that probably use the same set of components)

Title: Re: Advent of Code
Post by: David Martin on 25 December, 2017, 09:58:54 pm

(click to show/hide)

I like the naughty or nice list.
This was a very simple coding issue - just recorded the state rules in a hash and the visited positions in another hash to not worry about absolute array indexing.
Ran first time.
Merry Christmas all.

Title: Re: Advent of Code
Post by: Oaky on 25 December, 2017, 10:09:47 pm

Quote from: David Martin on 25 December, 2017, 09:58:54 pm

(click to show/hide)

I like the naughty or nice list.
This was a very simple coding issue - just recorded the state rules in a hash and the visited positions in another hash to not worry about absolute array indexing.
Ran first time.
Merry Christmas all.

(click to show/hide)

I did exacly the same thing for the solution part.

I don't recall ever implementing a classic Universal Turing Machine before.

The thing that took longest for me was parsing the input (I could've hard-coded it, but felt like making a parser).

Title: Re: Advent of Code
Post by: Diver300 on 27 December, 2017, 09:47:40 am

Day 24.

Well that took me far too long, but it taught me quite a lot about what takes time in a program.

I wrote a routine that worked out strengths of possible bridges made out of components, and when it comes to more than one that fits, another possible bridge is created, to be looked at later. I had sorted the components so that they could be indexed by number of pins, so finding the next available connector was quick.

Stupidly, I got the programme to look for the first unfinished possible bridge each time a component was added to a possible bridge. It was that looking that took most of the time, being a loop within a loop. As the number of bridges got large, that got too large to manage, while with small numbers of bridges it wasn't a problem. I didn't realise the cause initially.

I looked at the data to optimise it, and saw that there were various unusable components, some components that would always be worse than others, and many combinations that could only usefully fit together one way. I used that to create a reduced data input set, but one with an extra column for the "strength" of the missed connectors. For instance, if I found that the only connectors with 33 pins were 1/33 and 2/33, I would create a new component that was 1/2 but had an extra 66 of strength to be added when used.

With that, I got the answer, but the code took a minute or more to run.

Then I saw that everyone else had code that ran in seconds or less, and I realised that my loop within a loop was the problem. I sorted that, and worked out the statistics.

The full data ran added 1.8 million components, and tried 600,000 possible bridges
The reduced data added 66,000 components and tried 31,000 possible bridges.

The reduced data, when the code was searching for unfinished bridges, did 485 million loops just looking for the next bridge to try.

Title: Re: Advent of Code
Post by: Greenbank on 18 March, 2018, 11:05:32 pm

Decided to learn go so redoing 2017 in go.

https://github.com/alexgreenbank/AdventOfCode

It's certainly easier when you know how to solve each one efficiently (or at least efficiently enough).

Day 5 and I finally got to the point where I wrote the complete program for part one and only had to correct typos after the first attempt at running it.

Title: Re: Advent of Code
Post by: David Martin on 18 March, 2018, 11:46:30 pm

Really not got the time till after the Easter break. Love to get back into it, but that will have to wait till the summer.

Title: Re: Advent of Code
Post by: Ben T on 19 March, 2018, 06:33:20 am

Quote from: Greenbank on 18 March, 2018, 11:05:32 pm

Decided to learn go so redoing 2017 in go.

https://github.com/alexgreenbank/AdventOfCode

It's certainly easier when you know how to solve each one efficiently (or at least efficiently enough).

Day 5 and I finally got to the point where I wrote the complete program for part one and only had to correct typos after the first attempt at running it.

If you want more practice try some project euler problems, AoC is easy in comparison (mostly).  :P

Title: Re: Advent of Code
Post by: Greenbank on 19 March, 2018, 12:27:35 pm

Quote from: Ben T on 19 March, 2018, 06:33:20 am

If you want more practice try some project euler problems, AoC is easy in comparison (mostly).  :P

Yep, and the UVA (https://uva.onlinejudge.org/). The limiting factor in all of this is free time.

Title: Re: Advent of Code
Post by: Croft on 30 November, 2018, 06:59:30 am

Anyone getting up early tomorrow morning?

Title: Re: Advent of Code
Post by: Greenbank on 30 November, 2018, 12:03:52 pm

I'll never get up early to do it, it has to fit into my day somehow. I won't get around to Sunday's until late in the evening (and I'll probably still be hungover).

I'll probably do mine first time in perl or C and then reimplement in Go. Have been meaning to look at Rust too.

Title: Re: Advent of Code
Post by: telstarbox on 30 November, 2018, 02:19:24 pm

I've solved a couple of the puzzles from last year using Excel (formulae not Visual Basic) but it's clearly not the best solution for most of them. I don't know any specific programming languages so would you recommend any particular one for having a go at this year's puzzles?

Title: Re: Advent of Code
Post by: Croft on 30 November, 2018, 03:51:42 pm

If all programming languages are new to you, I think the best choice would be the one you would most like to learn. Most are going to be languages that at least could be used to answer the AoC challenges, so really it's about what might motivate you to learn any one of them.

Some common candidates would be Python (probably the sweet spot between ease of learning and suitability for AoC-type questions), Javascript (or one of its variants such as Typescript) and Java. But there are plenty more to chose from (someone in the last couple of years set themselves the challenges of using a different language for every question - that's 50 over two years! But not something I would recommend unless you have a lot of time on your hands and feel the need to have programmed in 50 languages).

Title: Re: Advent of Code
Post by: SoreTween on 30 November, 2018, 05:19:27 pm

VBA is a perfectly decent programming language for tasks at this level, why not just use that as you have it available?  Most other languages will have a learning curve associated with the tools, excel VBA is about as simple as it gets in that respect. Plus excel formulae are well suited to some puzzles, use whatever works best for each and keep it all together in one file.  You'll soon start subliminally learning about code re-use too.

Aside: addictive innit.

Title: Re: Advent of Code
Post by: David Martin on 02 December, 2018, 02:16:14 pm

It has started off gently enough though the part twos are a bit more complex than typical from previous years. I am left thinking there must be a better/more efficient way to solve some of them.

Title: Re: Advent of Code
Post by: Ben T on 02 December, 2018, 05:29:12 pm

Day 1 part 2 looks like there might be a Dynamic Programming solution but I can't see exactly what it is at the moment.

Title: Re: Advent of Code
Post by: vorsprung on 02 December, 2018, 05:30:07 pm

Did day 1 and 2 with perl one liners.  Although the second part of day 2 was a bit long

Not sure if ICBA to carry on with this :)

Title: Re: Advent of Code
Post by: Croft on 02 December, 2018, 06:23:53 pm

Quote from: vorsprung on 02 December, 2018, 05:30:07 pm

Did day 1 and 2 with perl one liners.  Although the second part of day 2 was a bit long

Not sure if ICBA to carry on with this :)

You can join the YACF leaderboard with the code 48462-ea506236. And it does get quite addictive (and the puzzles more varied).

Title: Re: Advent of Code
Post by: Greenbank on 02 December, 2018, 08:35:13 pm

Caught up with day 1 and 2 now I'm back from a weekend away. Nice gentle start.

(click to show/hide)

The naive O(n^2) solution for day 2 part two is to just compare each possible pair of IDs and count how many characters are different and output if the strings only differ by one character, but that'd be boring...

There's a nice O(n) solution though.

(click to show/hide)

Add each ID minus its 1st character to an empty hash checking for a match, if there's a match than that's your answer.
Add each ID minus its 2nd character to an empty hash checking for a match, ...
...Repeat to the length of all of the IDs...

Title: Re: Advent of Code
Post by: vorsprung on 02 December, 2018, 08:46:21 pm

Jo,

I am anonymous user #241788  apparently

Title: Re: Advent of Code
Post by: Greenbank on 02 December, 2018, 09:00:50 pm

Jo left here a long time ago.

Forgot to say, now that it has started I can now legitimately wear my AoC t-shirt.

Title: Re: Advent of Code
Post by: Greenbank on 03 December, 2018, 10:07:45 am

(click to show/hide)

Guessed I'd need to keep track of the individual patches for part b so hardly any changes required for the second part.

Waiting for the first tricky one...

Title: Re: Advent of Code
Post by: David Martin on 04 December, 2018, 09:50:11 pm

Is it just me or are they quite involved with no obvious 'simple algorithm'? Day 4 took me a while - not difficult, just involved.

(click to show/hide)

It seemed to be very time consuming with lots of iterating over data structures. I have a thought over how it might go better using something like numpy.

Title: Re: Advent of Code
Post by: Ben T on 04 December, 2018, 11:45:44 pm

Yes, not a difficult algorithm but like you say involved. https://github.com/bjtaylor1/AoC2018/blob/master/Day04/Program.cs (link contains spoiler). Didn't take long but I did use classes where I normally wouldn't have to bother.

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2018, 09:35:29 am

Day 4 wasn't about a specific algorithm, it was just about using appropriate data structures for the job. The better choice of data structure the easier it would be to implement the solution.

That and...

(click to show/hide)

sorting the input up front, even a simple lexical sort on an array of input lines was enough

With some of the puzzles there's usually only one (high-level) algorithm that will work in a reasonable time frame, and certainly only one (high-level) algorithm that would work if the input was considerably larger (which would show up the inefficient algorithm choices).

There's a number of different ways that you could have approached day 4, all perfectly valid.

I guess it highlights the fact that it's important to know when to optimise something, or choose to correct algorithm, and when you can just get away with anything that works.

Title: Re: Advent of Code
Post by: Ben T on 05 December, 2018, 11:09:01 am

(click to show/hide)

Initially stored the sequence in a string to do the removals, this took ~5 seconds for part 1.
Optimized by the fact that in .net a string is stored as one contigious block of memory whereas a StringBuilder isn't.
This takes it from 5 seconds to 1 second as it doesn't have to keep repeatedly allocating memory of the order of the size of the input.
Not sure if java or python do the same thing.

Part 2 takes 26 seconds as would be expected, but the simple insertion of AsParallel() reduces it to about 14/15 seconds.

https://github.com/bjtaylor1/AoC2018/blob/df318310a7039c8db55d3cf48e879447346dba0d/Day05/Program.cs

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2018, 02:44:42 pm

Ooh, if we're doing timings...

(click to show/hide)

Naive regex based solutions (in perl):-

5.1: 0.3s
5.2: 7.53s

On the same machine and implemented as a double linked list and minimising memory allocation (in C):-

5.1: 0.003s
5.2: 0.033s

All single threaded, no parallelism applied to either implementation.

Title: Re: Advent of Code
Post by: Ben T on 05 December, 2018, 03:09:35 pm

Hmm. Interesting. Code?
Only reason I'm curious is if single threaded, I would have expected 5.2 to take 26 times as long as 5.1. Your perl solution did, but C took only 11 times longer, so are you doing some sort of BFS/DFS type search?

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2018, 04:51:24 pm

There's an initial cost to parsing the input string which will mean part 2 won't take exactly 26 times as long as the first.

Code and comments:

(click to show/hide)

perl: http://www.greenbank.org/aoc/2018_day5_pl.txt (only does part 2 but easy to adapt to do part 1, just do the main loop once with a non-existent base like _ )

C: http://www.greenbank.org/aoc/2018_day5.c.txt

Doesn't use any form of searching, it does a linear scan along a double linked list, if it removes anything (either it's the base that needs removing or a pair like aA or Dd) then it moves back to the previous item in case that now matches the next item.

The orig pointers are there to rebuild the next/prev pointers for the next scan along the list for the next base.

Title: Re: Advent of Code
Post by: telstarbox on 05 December, 2018, 05:15:06 pm

For day 1 part 2 - do you need to use more than one loop of the input text? It's confusing me lots!

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2018, 06:58:29 pm

Quote from: telstarbox on 05 December, 2018, 05:15:06 pm

For day 1 part 2 - do you need to use more than one loop of the input text? It's confusing me lots!

"
Note that your device might need to repeat its list of frequency changes many times before a duplicate frequency is found, and that duplicates might be found while in the middle of processing the list.
"

Title: Re: Advent of Code
Post by: David Martin on 05 December, 2018, 08:32:27 pm

My code for day 5 is obviously inefficient (it does a lot of string allocation) in Python

(click to show/hide)

I read the input int a string, then scan it repeatedly removing pairs (abs(ord(string

• ) - ord(string([x+1])) == 32 is broadly the test used - appending positions that pass to a new string and skipping those that don't)

I might try building the data structure as a tree or a linked list, with iterative pruning as I go but I can't quite get my head around the process as I am fighting a wee cold at the moment.

Title: Re: Advent of Code
Post by: Pickled Onion on 05 December, 2018, 09:04:47 pm

(click to show/hide)

You don't need to keep going over the whole string, when you've done a removal you just need to back up one character, the string up to that point has already been scanned

(click to show/hide)

   while($i<$#data){
      $data[$i] ne $data[$i+1] && uc$data[$i] eq uc$data[$i+1]
         ? splice @data, $i--, 2
         : $i++;
   }

Title: Re: Advent of Code
Post by: Greenbank on 06 December, 2018, 09:08:15 am

Day 6 was nicely different.

(click to show/hide)

Initial naive implementations:-

Part 1: 8.83s 3.85s with an obvious optimisation
Part 2: 5.34s 1.99s with different search/fill algorithm

Thinking about ways of making them faster...

Title: Re: Advent of Code
Post by: Ben T on 06 December, 2018, 11:23:56 am

Day 6 is interesting, weirdly I found part 1 harder than part 2.

(click to show/hide)

I used 'fuzzy logic' for part 1.

Couldn't see a 'proper' way to eliminate ones whose areas were infinite.

I thought a convex hull algorithm was needed to eliminate ones whose areas were infinite, but it wouldn't, because if 'D' in the example was one square to the left, it would still be inside the hull, but anything to the left of it (and not up or down) is nearer to it than to any other location, ergo its area would be infinite.

I only summed up the areas inside the rectangular bounding box, but to eliminate any that were infinite, I simply drew a big circle round all the coordinates, and any coordinate that is the nearest to a point on that circle must have an infinite area.  :-\

https://github.com/bjtaylor1/AoC2018/blob/master/Day06/Program.cs

Title: Re: Advent of Code
Post by: Greenbank on 06 December, 2018, 11:41:39 am

(click to show/hide)

Quote from: Ben T on 06 December, 2018, 11:23:56 am

Couldn't see a 'proper' way to eliminate ones whose areas were infinite.
...
I only summed up the areas inside the rectangular bounding box, but to eliminate any that were infinite, I simply drew a big circle round all the coordinates, and any coordinate that is the nearest to a point on that circle must have an infinite area.
...

(click to show/hide)

You only have to consider points on a rectangular bounding box that cover the minimum/maximum co-ordinates in the dataset, not a bigger circle/box.

Looking at the example given:-

Code: [Select]

aaaaa.cccc
aAaaa.cccc
aaaddecccc
aadddeccCc
..dDdeeccc
bb.deEeecc
bBb.eeee..
bbb.eeefff
bbb.eeffff
bbb.ffffFf

If you take any point on the outside then the next furthest distant square must belong to the same area as it is only +1 on the manhattan distance, to get to it from any other square would require more than +1 on the manhattan distance, so it can never belong to any other area.

i.e. consider this portion of the left hand side:-

Code: [Select]

1a
2.
3b

1 can only ever belong to 'a'. 3 can only ever belong to 'b'.

By the same logic 2 must be '.' because nothing can uniquely get to it in a shorter distance if two things can get to the square to the right of it in the same manhattan distance. Since moving left is moving away from all points (as we're beyond the minimum x co-ordinate) then the manhattan distances can only increase each time.

So, any points on the rectangular bounding box that belong to a single area mean that area is infinite.

Title: Re: Advent of Code
Post by: Greenbank on 07 December, 2018, 08:52:08 am

Day 7: That was ok. Dependencies and scheduling.

What's scary, apart from the two syntax errors (missing parens), is both parts produced the correct answer first time without needing any tweaks.

Title: Re: Advent of Code
Post by: Ben T on 07 December, 2018, 12:30:09 pm

Done day 7 in Java but I might do it again in .NET with an actual thread to represent each worker.
https://github.com/bjtaylor1/AoC2018/blob/master/Day07/src/main/java/com/bjt/App.java

Title: Re: Advent of Code
Post by: Pickled Onion on 07 December, 2018, 01:17:11 pm

Quote from: Greenbank on 07 December, 2018, 08:52:08 am

Day 7: That was ok. Dependencies and scheduling.

What's scary, apart from the two syntax errors (missing parens), is both parts produced the correct answer first time without needing any tweaks.

Bah. I got the code correct but typed in the wrong starting parameters for part 2 then spent ages implementing a "fix" to the logic :(

Title: Re: Advent of Code
Post by: Diver300 on 08 December, 2018, 08:45:30 am

Day 8. The first part didn't take me too long. For the second part, the example given didn't find a lot of the mistakes in my code.

Title: Re: Advent of Code
Post by: Greenbank on 08 December, 2018, 10:08:00 am

Both bits of day 8 simple, made considerably easier by the fact that perl arrays automatically return a blank entry (interpreted as 0 in an integer context) for uninitialized elements, no need for any kind of bounds checking.

Was hoping for something a bit meatier at the weekend. We'll see tomorrow...

Title: Re: Advent of Code
Post by: David Martin on 08 December, 2018, 10:41:33 am

Quote from: Diver300 on 08 December, 2018, 08:45:30 am

Day 8. The first part didn't take me too long. For the second part, the example given didn't find a lot of the mistakes in my code.

This - took a wee while for the code to run.

(click to show/hide)

I kept track of forward and reverse dependencies, removing the node from the list of things waiting on something else when their dependencies were scheduled. A silly mistake or two led to some frustration.

(click to show/hide)

Late at night, much thinking but I got the basics sorted in my head, then sorted it this morning. Keep track of the worker pool. Remove from the pool all that finish at the current min finish time. Add in as many as are available to take up the extra space. Move on to the next finish time. At the end I just have one task and finish time left which is the right answer.

Title: Re: Advent of Code
Post by: David Martin on 08 December, 2018, 10:45:05 am

And day 8 - the first really fun one. Ran extremely rapidly, so much so that I thought I had an error :)

(click to show/hide)

Classic recursive function on a data structure. I put the data points in an array and tracked where everything was, storing the cumulative meta sum in each node (which made summation easy as it is built).

(click to show/hide)

Walk back down the tree with another recursive function, calculating the value as you go - very fast again.

Title: Re: Advent of Code
Post by: Greenbank on 08 December, 2018, 11:03:14 am

(click to show/hide)

No need for a tree structure or do multiple passes. Just one recursive function.

Code: http://www.greenbank.org/misc/aoc/2018_8b_pl.txt

Title: Re: Advent of Code
Post by: David Martin on 08 December, 2018, 12:17:46 pm

Quote from: Greenbank on 08 December, 2018, 11:03:14 am

(click to show/hide)

No need for a tree structure or do multiple passes. Just one recursive function.

Code: http://www.greenbank.org/misc/aoc/2018_8b_pl.txt

(click to show/hide)

I kept the recursively built tree because I had a suspicion it would be useful for the second half, which it was.
As it was the code took fractions of a second to run.

 

Title: Re: Advent of Code
Post by: Pickled Onion on 08 December, 2018, 12:49:16 pm

Quote from: Greenbank on 08 December, 2018, 11:03:14 am

(click to show/hide)

No need for a tree structure or do multiple passes. Just one recursive function.

Code: http://www.greenbank.org/misc/aoc/2018_8b_pl.txt

The hardest part of that was understanding the instructions. My version was similar to yours with added fluff.

(click to show/hide)

$r+=$cnvals[$mdvals[$ct]-1];   # Abuse perl's lack of bounds checking and uninitialised array elements return 0

Isn't there a danger here, you could get $cnvals[-1] instead of zero? My puzzle input didn't have such a case, so it didn't matter either way.

Title: Re: Advent of Code
Post by: David Martin on 08 December, 2018, 11:19:47 pm

OK, here is my python version for day 8 - not so different.

(click to show/hide)

Code: [Select]

data = [int(x) for x in open('day8.txt').read().split()]

def readnode(pos):
    node = {'nodes':[], 'meta':[], 'start':pos, 'end':pos+1, 'metasum':0}
    node['nodecount']=data[pos]
    node['metacount']=data[pos+1]
    pos=pos+2
    for i in range(node['nodecount']):
        newnode=readnode(pos)
        pos=newnode['end']+1
        node['nodes'].append(newnode)
        node['metasum']+= newnode['metasum']
    node['meta']=data[pos:pos+node['metacount']]
    node['metasum']+=sum(node['meta'])
    node['end']=pos+node['metacount']-1
    return node

tree = readnode(0)
print(tree['metasum'])

And as the tree structure was still there for the second part.

(click to show/hide)

Code: [Select]

def nodevalue(node):
    value=0
    if len(node['nodes']):
        for n in node['meta']:
            if n and n<=len(node['nodes']):
                value+=nodevalue(node['nodes'][n-1])
    else:
        value=sum(node['meta'])
    return value

print(nodevalue(tree))


Title: Re: Advent of Code
Post by: Greenbank on 09 December, 2018, 10:22:33 am

Aha. Day 9 starts to make it really interesting.

(click to show/hide)

Naive implementation for part one took 4 and a half minutes. Not even going to try it for part two as it'll just be bonkers.

Need to rewrite it to be more efficient but that'll have to wait as I'm taking my family out for brunch and then buying a Christmas tree...

Title: Re: Advent of Code
Post by: Greenbank on 09 December, 2018, 10:23:35 am

Quote from: Pickled Onion on 08 December, 2018, 12:49:16 pm

(click to show/hide)

$r+=$cnvals[$mdvals[$ct]-1];   # Abuse perl's lack of bounds checking and uninitialised array elements return 0

Isn't there a danger here, you could get $cnvals[-1] instead of zero? My puzzle input didn't have such a case, so it didn't matter either way.

(click to show/hide)

Good point! Guess I was just lucky as that could have been a real bugger to catch!

Title: Re: Advent of Code
Post by: Pickled Onion on 09 December, 2018, 11:29:32 am

Part 1.

Frustrating out-by-one error gave the correct answer for all but one of the examples. Implementing the instructions as written, array-splicing all the way, ran in sub-second.

Part 2.

No idea. Times ten ran in about a minute. Times 100 - forget it. Can't see the pattern or formula.

Title: Re: Advent of Code
Post by: Greenbank on 09 December, 2018, 01:05:55 pm

(click to show/hide)

Left original version (in perl using array slicing/splicing) running whilst I was out for brunch and lugging a Christmas tree home, just to see how far it would go.

7399s and it had got to marble 270,000 out of  ~7,000,000, so about 4% of the way through. Ha!

Rewrote it in C using a double linked list (so no array copying/slicing/splicing which is very expensive) and it gives the answer for part b in 0.259s (part a in 0.009s).

Using some really big marble numbers (100 million):-

$ time ./9 429 100000000
664880331050

real    0m2.921s
user    0m2.174s
sys     0m0.749s

[EDIT] Reimplemented in perl using a double linked list, a bit slower at 10.314s for my final puzzle input (last marble ~7 million).

Title: Re: Advent of Code
Post by: Diver300 on 09 December, 2018, 05:29:28 pm

Quote from: Pickled Onion on 09 December, 2018, 11:29:32 am

Part 1.

Frustrating out-by-one error gave the correct answer for all but one of the examples. Implementing the instructions as written, array-splicing all the way, ran in sub-second.

Part 2.

No idea. Times ten ran in about a minute. Times 100 - forget it. Can't see the pattern or formula.

As above.

Put a progress counter on and realised that 100 times would take hours and hours.

Had to go out and do real stuff and it was done by the time I came home.

I also tried to code a time-saving routine but I didn't get that to work before I had to go out.

edit:- corrected my time-saving routine and it ran in about 20 minutes. It is still O(n²).

(click to show/hide)

If there's an array of marble values, inserting one means moving many up by 1 which is slow. If 22 consecutive non-scoring moves are done with one move, it's much faster.

Title: Re: Advent of Code
Post by: David Martin on 09 December, 2018, 09:24:04 pm

Quote from: Greenbank on 09 December, 2018, 01:05:55 pm

(click to show/hide)

Left original version (in perl using array slicing/splicing) running whilst I was out for brunch and lugging a Christmas tree home, just to see how far it would go.

7399s and it had got to marble 270,000 out of  ~7,000,000, so about 4% of the way through. Ha!

Rewrote it in C using a double linked list (so no array copying/slicing/splicing which is very expensive) and it gives the answer for part b in 0.259s (part a in 0.009s).

Using some really big marble numbers (100 million):-

$ time ./9 429 100000000
664880331050

real    0m2.921s
user    0m2.174s
sys     0m0.749s

[EDIT] Reimplemented in perl using a double linked list, a bit slower at 10.314s for my final puzzle input (last marble ~7 million).

(click to show/hide)

D'oh. The original (using array splicing) was fractions of a second. The *100 was much much slower and obviously an exponential slowdown.
Rewriting it as a double linked list was not much extra code, and ran in O(n) rather than O(n^2)

Title: Re: Advent of Code
Post by: Ben T on 09 December, 2018, 11:14:19 pm

Quote from: Greenbank on 09 December, 2018, 01:05:55 pm

(click to show/hide)

Left original version (in perl using array slicing/splicing) running whilst I was out for brunch and lugging a Christmas tree home, just to see how far it would go.

7399s and it had got to marble 270,000 out of  ~7,000,000, so about 4% of the way through. Ha!

Rewrote it in C using a double linked list (so no array copying/slicing/splicing which is very expensive) and it gives the answer for part b in 0.259s (part a in 0.009s).

Using some really big marble numbers (100 million):-

$ time ./9 429 100000000
664880331050

real    0m2.921s
user    0m2.174s
sys     0m0.749s

[EDIT] Reimplemented in perl using a double linked list, a bit slower at 10.314s for my final puzzle input (last marble ~7 million).

similar to mine but C++ is far easier than plain C...
https://github.com/bjtaylor1/AoC2018/blob/master/Day09/Day09.cpp
 (link contains spoiler)

runs in a fraction of a second for my x100 input.

Title: Re: Advent of Code
Post by: Diver300 on 10 December, 2018, 08:46:58 am

I found day 10 straightforward.

(click to show/hide)

I realised that y dimension (and probably the x) would be a minimum when the message was legible, so I ran the movements until the y was a minimum.

I didn't try to get the computer to read the result.

For part 2, I had already counted the cycles to give me a way out of the loop if when it got too far before my code worked correctly.

Title: Re: Advent of Code
Post by: Ben T on 10 December, 2018, 09:56:10 am

Quote from: Diver300 on 10 December, 2018, 08:46:58 am

I found day 10 straightforward.

(click to show/hide)

I realised that y dimension (and probably the x) would be a minimum when the message was legible, so I ran the movements until the y was a minimum.

I didn't try to get the computer to read the result.

For part 2, I had already counted the cycles to give me a way out of the loop if when it got too far before my code worked correctly.

(click to show/hide)

The first time all points are next to at least one other worked for me (and an additional check that no point is at the same location as another, but which may have been unnecessary).
A lower case "i" could have spannered that but the test message was in upper case so I figured that wouldn't happen!

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2018, 10:37:09 am

(click to show/hide)

Minimal area of bounding box for me.

Off by one for part 2 though, realised it as soon as I hit submit on my answer and had to wait 60s to enter n+1.

Would have been much trickier if they'd included one or more stray points.

Title: Re: Advent of Code
Post by: Ben T on 10 December, 2018, 11:12:12 am

(click to show/hide)

Quote from: Greenbank on 10 December, 2018, 10:37:09 am

Minimal area of bounding box for me.

Off by one for part 2 though, realised it as soon as I hit submit on my answer and had to wait 60s to enter n+1.

Would have been much trickier if they'd included one or more stray points.

I thought of a statistical approach like that but the issue I had is how do you test a scenario in isolation?

e.g. you might have a series of bounding box areas like: 56, 54, 57, 53, 13, 54.
it's clear that 13 (t=4) is the minimum, and probably the answer - but when you get to 54 (t=1), that is the lowest so far, and so is 53 (t = 3).

How do you come to the conclusion that you have definitely reached the answer without false positives, or reading past the answer?

It's interestingly similar to the type of cryptography where a brute force attack doesn't know when it's got to the right answer, because the secret encrypted with the 'wrong' key looks 'sensible' to a computer. Not sure exactly how it works or how successful it is.

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2018, 11:38:34 am

(click to show/hide)

I'd assumed that it would be at the minimum area of the local bounding box so the time to stop searching would be when you get a minimal bounding box that has an area that is larger than the lowest value seen so far.

In other words, once you'd passed the correct point the area of the bounding box would only grow again, so it's easy to detect.

As long as you know the time value for the minimum point you can compute what it looks like without needing to do any of the intermediate steps (or just go one step back).

In the end I didn't bother making it back up one or recompute it, I just ran it once to find out what the minimum area was and then edited the program to print the grid when the bounding box area is below a certain size.

I'd based all this on an assumption that the puzzles would have been generated by taking a grid representation of a string of characters, adding a random x and y offset (so that they aren't close to 0,0), giving each point a random velocity and then applying a random number of iterations to explode them outwards. This is how I'd generate the puzzles if it was me doing that side of things.

Code: [Select]

...
t=10270 171 85 222 183 sizes=3354
t=10271 166 90 217 188 sizes=2204
t=10272 163 95 212 193 sizes=1292
t=10273 161 100 207 198 sizes=549
-------------t=10273------------------
.####...######..#....#..#....#...####....####....####...#....#
#....#..#.......##...#..#...#...#....#..#....#..#....#..#....#
#.......#.......##...#..#..#....#.......#.......#.......#....#
#.......#.......#.#..#..#.#.....#.......#.......#.......#....#
#.......#####...#.#..#..##......#.......#.......#.......######
#..###..#.......#..#.#..##......#.......#..###..#..###..#....#
#....#..#.......#..#.#..#.#.....#.......#....#..#....#..#....#
#....#..#.......#...##..#..#....#.......#....#..#....#..#....#
#...##..#.......#...##..#...#...#....#..#...##..#...##..#....#
.###.#..#.......#....#..#....#...####....###.#...###.#..#....#
t=10274 166 95 212 193 sizes=1349

So it sees a minimum value of 549 and then stops on the next iteration as the area has gone up to 1349.

Obviously if this hadn't worked I would have done something different, such as print the grids for the 3 or 4 iterations either side of the local minima. It's possible to create inputs that explode the points out in such a way that the message is not the local minima (either by x, y or bounding box area), indeed it's possible to produce inputs that will spell out a message but at one point in time every point has exactly the same position x and y.

Eric tends not to be so cruel, at least not this early on in the challenge.

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2018, 11:54:13 am

(click to show/hide)

For example, try this input:-

Code: [Select]

position=<  -803,   948> velocity=<   5,  -6>
position=<  -927,   948> velocity=<   6,  -6>
position=< -1671,   824> velocity=<  12,  -5>
position=<   437,   576> velocity=<  -5,  -3>
position=<  1057,   824> velocity=< -10,  -5>
position=<  -555,   700> velocity=<   3,  -4>
position=<  -803,   576> velocity=<   5,  -3>
position=< -1423,   576> velocity=<  10,  -3>
position=<   -59,   700> velocity=<  -1,  -4>
position=< -1671,   948> velocity=<  12,  -6>
position=<  -927,   700> velocity=<   6,  -4>
position=<   933,  1072> velocity=<  -9,  -7>
position=<  1181,   824> velocity=< -11,  -5>
position=<   933,   824> velocity=<  -9,  -5>
position=<  1305,   824> velocity=< -12,  -5>
position=< -1051,  1072> velocity=<   7,  -7>
position=<   933,   700> velocity=<  -9,  -4>
position=< -1795,   700> velocity=<  13,  -4>
position=<   189,  1196> velocity=<  -3,  -8>
position=<   -59,   824> velocity=<  -1,  -5>
position=<  1181,   576> velocity=< -11,  -3>
position=< -1051,   948> velocity=<   7,  -6>
position=<  -555,   948> velocity=<   3,  -6>
position=<  1305,   576> velocity=< -12,  -3>
position=<    65,  1196> velocity=<  -2,  -8>
position=<   -59,  1072> velocity=<  -1,  -7>
position=< -1051,   824> velocity=<   7,  -5>
position=< -1051,  1196> velocity=<   7,  -8>
position=< -1919,   576> velocity=<  14,  -3>
position=<  1553,   576> velocity=< -14,  -3>
position=<  -431,   824> velocity=<   2,  -5>
position=<  1429,   824> velocity=< -13,  -5>
position=<   313,   576> velocity=<  -4,  -3>
position=<   313,  1196> velocity=<  -4,  -8>
position=< -1671,  1072> velocity=<  12,  -7>
position=<  -431,   948> velocity=<   2,  -6>
position=<  -679,   576> velocity=<   4,  -3>
position=<   437,  1196> velocity=<  -5,  -8>
position=<  1057,   576> velocity=< -10,  -3>
position=<  -431,  1072> velocity=<   2,  -7>
position=<  1429,   576> velocity=< -13,  -3>
position=<  -431,  1196> velocity=<   2,  -8>
position=< -1547,   700> velocity=<  11,  -4>
position=<   933,  1196> velocity=<  -9,  -8>
position=<   933,   948> velocity=<  -9,  -6>
position=<   933,   576> velocity=<  -9,  -3>
position=<    65,   576> velocity=<  -2,  -3>
position=<  -679,   948> velocity=<   4,  -6>
position=< -1671,  1196> velocity=<  12,  -8>
position=<   -59,   948> velocity=<  -1,  -6>
position=<   561,  1072> velocity=<  -6,  -7>
position=<   561,   700> velocity=<  -6,  -4>
position=<   189,   576> velocity=<  -3,  -3>

The answer isn't at the minima of area or x or y, but it's obviously very close.

Title: Re: Advent of Code
Post by: Ben T on 10 December, 2018, 11:55:47 am

Quote from: Greenbank on 10 December, 2018, 11:38:34 am

(click to show/hide)

I'd assumed that it would be at the minimum area of the local bounding box so the time to stop searching would be when you get a minimal bounding box that has an area that is larger than the lowest value seen so far.

In other words, once you'd passed the correct point the area of the bounding box would only grow again, so it's easy to detect.

As long as you know the time value for the minimum point you can compute what it looks like without needing to do any of the intermediate steps (or just go one step back).

In the end I didn't bother making it back up one or recompute it, I just ran it once to find out what the minimum area was and then edited the program to print the grid when the bounding box area is below a certain size.

I'd based all this on an assumption that the puzzles would have been generated by taking a grid representation of a string of characters, adding a random x and y offset (so that they aren't close to 0,0), giving each point a random velocity and then applying a random number of iterations to explode them outwards. This is how I'd generate the puzzles if it was me doing that side of things.

Code: [Select]

...
t=10270 171 85 222 183 sizes=3354
t=10271 166 90 217 188 sizes=2204
t=10272 163 95 212 193 sizes=1292
t=10273 161 100 207 198 sizes=549
-------------t=10273------------------
.####...######..#....#..#....#...####....####....####...#....#
#....#..#.......##...#..#...#...#....#..#....#..#....#..#....#
#.......#.......##...#..#..#....#.......#.......#.......#....#
#.......#.......#.#..#..#.#.....#.......#.......#.......#....#
#.......#####...#.#..#..##......#.......#.......#.......######
#..###..#.......#..#.#..##......#.......#..###..#..###..#....#
#....#..#.......#..#.#..#.#.....#.......#....#..#....#..#....#
#....#..#.......#...##..#..#....#.......#....#..#....#..#....#
#...##..#.......#...##..#...#...#....#..#...##..#...##..#....#
.###.#..#.......#....#..#....#...####....###.#...###.#..#....#
t=10274 166 95 212 193 sizes=1349

So it sees a minimum value of 549 and then stops on the next iteration as the area has gone up to 1349.

Obviously if this hadn't worked I would have done something different, such as print the grids for the 3 or 4 iterations either side of the local minima. It's possible to create inputs that explode the points out in such a way that the message is not the local minima (either by x, y or bounding box area), indeed it's possible to produce inputs that will spell out a message but at one point in time every point has exactly the same position x and y.

Eric tends not to be so cruel, at least not this early on in the challenge.

(click to show/hide)

I get your idea, but surely did you not still get a lot of false positives early on?
e.g. in my example where the areas go  56, 54, 57, 53, 13, 54.
Your code would have identified 57 as the first "bounding box that has an area that is larger than the lowest value seen so far".
And would have printed the scenario with 54 as the answer.

Title: Re: Advent of Code
Post by: Croft on 10 December, 2018, 12:03:23 pm

(click to show/hide)

Quote from: Greenbank on 10 December, 2018, 10:37:09 am

Would have been much trickier if they'd included one or more stray points.

Calculate centroid (cx, cy) of point list.
For each point (x, y):
    if distance (cx, cy) to (x+vx, y+vy) > distance (cx, cy) to (x, y), remove it from point list

if bounding box of all (x+vx, y+vy) is > bounding box of all (x,y) HALT else repeat

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2018, 12:05:20 pm

(click to show/hide)

Quote

e.g. in my example where the areas go  56, 54, 57, 53, 13, 54.

I didn't encounter blips like that (i.e. 54, 57, 53 ).

It was monotonically decreasing to a minima and then monotonically increasing from there on.

Obviously if I'd hit a local minima I would have had to rejig the algorithm...

Title: Re: Advent of Code
Post by: Ben T on 10 December, 2018, 12:17:48 pm

Quote from: Greenbank on 10 December, 2018, 11:54:13 am

(click to show/hide)

For example, try this input:-

Code: [Select]

position=<  -803,   948> velocity=<   5,  -6>
position=<  -927,   948> velocity=<   6,  -6>
position=< -1671,   824> velocity=<  12,  -5>
position=<   437,   576> velocity=<  -5,  -3>
position=<  1057,   824> velocity=< -10,  -5>
position=<  -555,   700> velocity=<   3,  -4>
position=<  -803,   576> velocity=<   5,  -3>
position=< -1423,   576> velocity=<  10,  -3>
position=<   -59,   700> velocity=<  -1,  -4>
position=< -1671,   948> velocity=<  12,  -6>
position=<  -927,   700> velocity=<   6,  -4>
position=<   933,  1072> velocity=<  -9,  -7>
position=<  1181,   824> velocity=< -11,  -5>
position=<   933,   824> velocity=<  -9,  -5>
position=<  1305,   824> velocity=< -12,  -5>
position=< -1051,  1072> velocity=<   7,  -7>
position=<   933,   700> velocity=<  -9,  -4>
position=< -1795,   700> velocity=<  13,  -4>
position=<   189,  1196> velocity=<  -3,  -8>
position=<   -59,   824> velocity=<  -1,  -5>
position=<  1181,   576> velocity=< -11,  -3>
position=< -1051,   948> velocity=<   7,  -6>
position=<  -555,   948> velocity=<   3,  -6>
position=<  1305,   576> velocity=< -12,  -3>
position=<    65,  1196> velocity=<  -2,  -8>
position=<   -59,  1072> velocity=<  -1,  -7>
position=< -1051,   824> velocity=<   7,  -5>
position=< -1051,  1196> velocity=<   7,  -8>
position=< -1919,   576> velocity=<  14,  -3>
position=<  1553,   576> velocity=< -14,  -3>
position=<  -431,   824> velocity=<   2,  -5>
position=<  1429,   824> velocity=< -13,  -5>
position=<   313,   576> velocity=<  -4,  -3>
position=<   313,  1196> velocity=<  -4,  -8>
position=< -1671,  1072> velocity=<  12,  -7>
position=<  -431,   948> velocity=<   2,  -6>
position=<  -679,   576> velocity=<   4,  -3>
position=<   437,  1196> velocity=<  -5,  -8>
position=<  1057,   576> velocity=< -10,  -3>
position=<  -431,  1072> velocity=<   2,  -7>
position=<  1429,   576> velocity=< -13,  -3>
position=<  -431,  1196> velocity=<   2,  -8>
position=< -1547,   700> velocity=<  11,  -4>
position=<   933,  1196> velocity=<  -9,  -8>
position=<   933,   948> velocity=<  -9,  -6>
position=<   933,   576> velocity=<  -9,  -3>
position=<    65,   576> velocity=<  -2,  -3>
position=<  -679,   948> velocity=<   4,  -6>
position=< -1671,  1196> velocity=<  12,  -8>
position=<   -59,   948> velocity=<  -1,  -6>
position=<   561,  1072> velocity=<  -6,  -7>
position=<   561,   700> velocity=<  -6,  -4>
position=<   189,   576> velocity=<  -3,  -3>

The answer isn't at the minima of area or x or y, but it's obviously very close.

(click to show/hide)

Prints 'YACF' after 123 seconds. Interestingly 2 seconds later, at t = 125 seconds it prints YACF, perfectly, but upside down. Intentional?

I can sort of see how the area would increase as the problem-setter was creating the input, and that you've simply reverse engineered that.
Would have been much harder (for you) if they'd been enclosed in a bounding box, like a 'TV', and 'bounce' off the sides or come back on at the left when they've gone off the right, etc. And would have been much harder for me if they'd used a lower case i.


My code could probably be rewritten (maybe in a different language) to run a lot faster, it took iirc probably >5 seconds to run, but was inside 30 seconds so optimization wasn't really needed. Only took about 10 mins to write.

Code: [Select]

using System;

namespace Day10
{
    using System.IO;
    using System.Linq;
    using System.Text.RegularExpressions;
    using AoCLib;

    class Program
    {
        static void Main(string[] args)
        {
            var parser = new Parser<Point>(new Regex(@"position\=\<\s*(?<PosX>[\-\d]+)\s*,\s*(?<PosY>[\-\d]+)\s*>\s*velocity\=\<\s*(?<VelX>[\-\d]+)\s*,\s*(?<VelY>[\-\d]+)\s*\>"));
            var points = File.ReadAllLines(@"..\..\..\input.txt")
                .Select(parser.Parse)
                .ToArray();
            int time = 0;
            while (true)
            {
                var alone = points.Count(p => !points.Any(p.IsNextTo));
                if (alone == 0)
                {
                    Print(points, time);
                }
                points.AsParallel().ForAll(p => p.Move());
                if(++time % 1000 == 0) Console.Write($"{time}    \r");
            }
        }

        private static void Print(Point[] points, int time)
        {
            var minX = points.Min(p => p.PosX);
            var minY = points.Min(p => p.PosY);
            var maxX = points.Max(p => p.PosX);
            var maxY = points.Max(p => p.PosY);
            char[][] lines = Enumerable.Range(0, 1 + maxY - minY).Select(y => Enumerable.Repeat(' ',1 + maxX - minX).ToArray()).ToArray();
            foreach (var point in points)
            {
                lines[point.PosY - minY][point.PosX - minX] = '#';
            }

            if (Console.BufferHeight < maxY - minY) Console.BufferHeight = maxY - minY;
            if (Console.BufferWidth < maxX - minX) Console.BufferWidth = maxX - minX;
            Console.Clear();
            foreach (var line in lines)
            {
                Console.WriteLine(new string(line));
            }
            Console.WriteLine($"\nafter {time}");
            Console.ReadKey(true);
        }
    }

    class Point
    {
        public int PosX { get; set; }
        public int PosY { get; set; }
        public int VelX { get; set; }
        public int VelY { get; set; }

        public void Move()
        {
            this.PosX += this.VelX;
            this.PosY += this.VelY;
        }

        public bool IsNextTo(Point other)
        {
            var xDiff = Math.Abs(this.PosX - other.PosX);
            var yDiff = Math.Abs(this.PosY - other.PosY);
            return xDiff <= 1 && yDiff <= 1 && (xDiff > 0 || yDiff > 0);
        }
    }
}



Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2018, 12:29:00 pm

Quote from: Ben T on 10 December, 2018, 12:17:48 pm

(click to show/hide)

Prints 'YACF' after 123 seconds. Interestingly 2 seconds later, at t = 125 seconds it prints YACF, perfectly, but upside down. Intentional?

(click to show/hide)

Yes, intentional, look at the positions of all the points at t=124.

Title: Re: Advent of Code
Post by: David Martin on 10 December, 2018, 10:33:22 pm

(click to show/hide)

I'd figured that it was probably going to be very close to the minimum but may not necessarily be at the minimum as you can compress the points further than legibility.
So I wrote a few functions that would let me move the points backward and forward in time, one that found the minimum and one that generated an image of the points.

So head to the minimum, view the image and then back up until it is obviously wrong, go forward till obviously wrong and stop when it is legible.

Part 2 was trivial and I should have counted the number of steps, but  saving the x of my first point and then calculating the time to move from its starting position was easy.

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2018, 08:59:50 am

(click to show/hide)

Ooh, it's a classic.

O(n^3) or worse if implemented naively however it looks like the answer comes quite early so it's worth a punt and submitting whatever your program has spat out after running for a bit (assuming you output new high scores as they are found).

For a more optimal (or rather: less pessimal) solution (in C, was much faster than perl):-

$ time ./11 42
119 232,251,12

real    0m0.771s
user    0m0.768s
sys     0m0.004s

Title: Re: Advent of Code
Post by: Diver300 on 11 December, 2018, 09:19:59 am

Day 11 part  2

(click to show/hide)

The only bit on non-naive programming that I did was to calculate the sum of the squares by adding each L-shape to go from one square up to the next. This meant that the largest square would uniquely need 599 points added to a previous total instead of 90,000 if previous totals were ignored. 

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2018, 10:33:27 am

Quote from: Diver300 on 11 December, 2018, 09:19:59 am

Day 11 part  2

(click to show/hide)

The only bit on non-naive programming that I did was to calculate the sum of the squares by adding each L-shape to go from one square up to the next. This meant that the largest square would uniquely need 599 points added to a previous total instead of 90,000 if previous totals were ignored. 

(click to show/hide)

Yep, that's good enough.

The most optimal algorithm would be a modification (slight simplification) of Kadane's 2D algorithm (since that deals with maximum sum rectangle in a 2D array so it's a bit simpler if doing max square).

Got a chance to knock up a version (now with optimisation):-

$ time ./k 42
hs=119 at 232,251,12

real    0m0.027s
user    0m0.023s
sys     0m0.004s

Title: Re: Advent of Code
Post by: Ben T on 11 December, 2018, 11:18:02 am

naive implementation in C++ https://github.com/bjtaylor1/AoC2018/blob/master/Day11/Day11.cpp (link may contain spoiler)
takes about a couple or three seconds

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2018, 02:20:49 pm

(click to show/hide)

http://www.greenbank.org/aoc/2018_day_11.c.txt

(Not particularly nicely written, would be splitting things into separate functions if I spent any more time on it. Especially confusing as x goes from 0 to 299 but y goes from 1 to 300 (for the original grid values) as the extra row of zeros to support Kadane's algorithm.)

Almost instantaneous (0.03s).

Title: Re: Advent of Code
Post by: Ben T on 11 December, 2018, 02:44:55 pm

Day 10 extension  :)

Code: [Select]

position=<679, 117> velocity=<-7, -1>
position=<584, 498> velocity=<-6, -5>
position=<489, 594> velocity=<-5, -6>
position=<109, 310> velocity=<-1, -3>
position=<585, 399> velocity=<-6, -4>
position=<300, 305> velocity=<-3, -3>
position=<680, 211> velocity=<-7, -2>
position=<586, 493> velocity=<-6, -5>
position=<586, 494> velocity=<-6, -5>
position=<397, 398> velocity=<-4, -4>
position=< 18, 683> velocity=< 0, -7>
position=< 19,  18> velocity=< 0,  0>
position=<399, 399> velocity=<-4, -4>
position=< 19,  20> velocity=< 0,  0>
position=<115,  21> velocity=<-1,  0>
position=<591, 402> velocity=<-6, -4>
position=<401, 403> velocity=<-4, -4>
position=<307, 308> velocity=<-3, -3>
position=<498, 305> velocity=<-5, -3>
position=<308, 686> velocity=<-3, -7>
position=<688, 117> velocity=<-7, -1>
position=<404, 586> velocity=<-4, -6>
position=<594, 112> velocity=<-6, -1>
position=< 24, 398> velocity=< 0, -4>
position=< 24, 399> velocity=< 0, -4>
position=<215,  16> velocity=<-2,  0>
position=<216, 491> velocity=<-2, -5>
position=<121,  17> velocity=<-1,  0>
position=< 27, 588> velocity=< 0, -6>
position=< 28,  18> velocity=< 0,  0>
position=<503,  19> velocity=<-5,  0>
position=<218, 495> velocity=<-2, -5>
position=<503, 686> velocity=<-5, -7>
position=<598, 212> velocity=<-6, -2>
position=<601, 223> velocity=<-6, -2>
position=< 31, 319> velocity=< 0, -3>
position=<126, 510> velocity=<-1, -5>
position=<411, 701> velocity=<-4, -7>
position=<221, 227> velocity=<-2, -2>
position=<127, 223> velocity=<-1, -2>
position=<412, 323> velocity=<-4, -3>
position=<697, 419> velocity=<-7, -4>
position=<603, 507> velocity=<-6, -5>
position=<128, 705> velocity=<-1, -7>
position=<318, 326> velocity=<-3, -3>
position=<319, 696> velocity=<-3, -7>
position=<224, 232> velocity=<-2, -2>
position=<130, 696> velocity=<-1, -7>
position=<605, 707> velocity=<-6, -7>
position=< 36, 696> velocity=< 0, -7>
position=<226, 510> velocity=<-2, -5>
position=<606, 518> velocity=<-6, -5>
position=<322, 601> velocity=<-3, -6>
position=<702, 511> velocity=<-7, -5>
position=< 37, 139> velocity=< 0, -1>
position=<513, 601> velocity=<-5, -6>
position=<418, 511> velocity=<-4, -5>
position=<418, 140> velocity=<-4, -1>
position=< 39, 506> velocity=< 0, -5>
position=<609,  36> velocity=<-6,  0>
position=<514, 710> velocity=<-5, -7>
position=<705, 221> velocity=<-7, -2>
position=<705, 131> velocity=<-7, -1>
position=<135, 615> velocity=<-1, -6>
position=<326, 506> velocity=<-3, -5>
position=<136, 319> velocity=<-1, -3>
position=<231, 225> velocity=<-2, -2>
position=< 41, 701> velocity=< 0, -7>
position=<516, 236> velocity=<-5, -2>
position=<137,  31> velocity=<-1,  0>
position=<517, 319> velocity=<-5, -3>
position=<612, 236> velocity=<-6, -2>
position=<613, 506> velocity=<-6, -5>
position=<233, 412> velocity=<-2, -4>
position=<613,  33> velocity=<-6,  0>
position=<613,  46> velocity=<-6,  0>
position=< 50,  54> velocity=< 0,  0>
position=<145, 340> velocity=<-1, -3>
position=<525, 436> velocity=<-5, -4>
position=<620, 152> velocity=<-6, -1>
position=<525, 153> velocity=<-5, -1>
position=<240, 344> velocity=<-2, -3>
position=< 50, 155> velocity=< 0, -1>
position=<430, 156> velocity=<-4, -1>
position=<525, 442> velocity=<-5, -4>
position=<431, 624> velocity=<-4, -6>
position=<432, 624> velocity=<-4, -6>
position=<242, 245> velocity=<-2, -2>
position=< 53, 530> velocity=< 0, -5>
position=<434, 245> velocity=<-4, -2>
position=<625, 435> velocity=<-6, -4>
position=<721, 340> velocity=<-7, -3>
position=<721,  56> velocity=<-7,  0>
position=<351, 255> velocity=<-3, -2>
position=<161, 541> velocity=<-1, -5>
position=<161, 162> velocity=<-1, -1>
position=<352, 730> velocity=<-3, -7>
position=<257, 448> velocity=<-2, -4>
position=< 67, 354> velocity=< 0, -3>
position=<257, 450> velocity=<-2, -4>
position=<162, 166> velocity=<-1, -1>
position=<637, 262> velocity=<-6, -2>
position=<352, 738> velocity=<-3, -7>
position=<448, 159> velocity=<-4, -1>
position=<544, 634> velocity=<-5, -6>
position=<260,  64> velocity=<-2,  0>
position=<736, 444> velocity=<-7, -4>
position=<357,  64> velocity=<-3,  0>
position=<168, 729> velocity=<-1, -7>
position=<367, 741> velocity=<-3, -7>
position=<558, 171> velocity=<-5, -1>
position=< 83,  93> velocity=< 0,  0>
position=<274, 361> velocity=<-2, -3>
position=<369, 473> velocity=<-3, -4>
position=<465, 552> velocity=<-4, -5>
position=<180, 553> velocity=<-1, -5>
position=<370,  93> velocity=<-3,  0>
position=<181, 554> velocity=<-1, -5>
position=<561, 473> velocity=<-5, -4>
position=<752,  80> velocity=<-7,  0>
position=<372, 283> velocity=<-3, -2>
position=<468, 271> velocity=<-4, -2>
position=<373, 188> velocity=<-3, -1>
position=<184, 645> velocity=<-1, -6>
position=<469, 171> velocity=<-4, -1>
position=<279, 172> velocity=<-2, -1>
position=<754, 268> velocity=<-7, -2>
position=<659, 744> velocity=<-6, -7>
position=<184, 650> velocity=<-1, -6>
position=< 89,  81> velocity=< 0,  0>
position=<374, 747> velocity=<-3, -7>
position=<469,  83> velocity=<-4,  0>
position=<564, 559> velocity=<-5, -5>
position=<564, 750> velocity=<-5, -7>
position=<374, 656> velocity=<-3, -6>
position=<279, 562> velocity=<-2, -5>
position=<754, 373> velocity=<-7, -3>
position=<469, 374> velocity=<-4, -3>
position=<564, 565> velocity=<-5, -5>
position=<564, 186> velocity=<-5, -1>
position=<184, 472> velocity=<-1, -4>
position=< 89, 283> velocity=< 0, -2>
position=<280,  75> velocity=<-2,  0>
position=<565,  76> velocity=<-5,  0>
position=<185, 172> velocity=<-1, -1>
position=<375, 743> velocity=<-3, -7>
position=<470, 744> velocity=<-4, -7>
position=<470, 460> velocity=<-4, -4>
position=<566, 455> velocity=<-5, -4>
position=<566, 551> velocity=<-5, -5>
position=<625, 775> velocity=< 3,  2>
position=<626, 490> velocity=< 3,  5>
position=<342, 490> velocity=< 6,  5>
position=<817, 593> velocity=< 1,  4>
position=<342, 784> velocity=< 6,  2>
position=<818, 585> velocity=< 1,  4>
position=<818, 403> velocity=< 1,  6>
position=<344, 396> velocity=< 6,  6>
position=<344, 777> velocity=< 6,  2>
position=<439, 496> velocity=< 5,  5>
position=<249, 592> velocity=< 7,  4>
position=<440, 873> velocity=< 5,  1>
position=<725, 684> velocity=< 2,  3>
position=<915, 305> velocity=< 0,  7>
position=<251, 970> velocity=< 7,  0>
position=<442, 875> velocity=< 5,  1>
position=<917, 306> velocity=< 0,  7>
position=<348, 304> velocity=< 6,  7>
position=<823, 782> velocity=< 1,  2>
position=<634, 494> velocity=< 3,  5>
position=<349, 878> velocity=< 6,  1>
position=<730, 403> velocity=< 2,  6>
position=<920, 309> velocity=< 0,  7>
position=<449, 400> velocity=< 5,  6>
position=<829, 496> velocity=< 1,  5>
position=<449, 687> velocity=< 5,  3>
position=<354, 973> velocity=< 6,  0>
position=<354, 404> velocity=< 6,  6>
position=<544, 880> velocity=< 4,  1>
position=<639, 786> velocity=< 3,  2>
position=<449, 882> velocity=< 5,  1>
position=<544, 408> velocity=< 4,  6>
position=<450, 305> velocity=< 5,  7>
position=<641, 780> velocity=< 3,  2>
position=<927, 400> velocity=< 0,  6>
position=<453, 590> velocity=< 5,  4>
position=<359, 305> velocity=< 6,  7>
position=<359, 401> velocity=< 6,  6>
position=<740, 401> velocity=< 2,  6>
position=<836, 782> velocity=< 1,  2>
position=<362, 783> velocity=< 6,  2>
position=<362, 879> velocity=< 6,  1>
position=<742, 785> velocity=< 2,  2>
position=<743, 974> velocity=< 2,  0>
position=<933, 975> velocity=< 0,  0>
position=<743, 311> velocity=< 2,  7>
position=<269, 973> velocity=< 7,  0>
position=<934, 596> velocity=< 0,  4>
position=<554, 597> velocity=< 4,  4>
position=<839, 978> velocity=< 1,  0>
position=<650, 783> velocity=< 3,  2>
position=<461, 783> velocity=< 5,  2>
position=<937, 878> velocity=< 0,  1>
position=<558, 403> velocity=< 4,  6>
position=<844, 973> velocity=< 1,  0>
position=<655, 498> velocity=< 3,  5>
position=<941, 879> velocity=< 0,  1>
position=<562, 784> velocity=< 4,  2>
position=<658, 689> velocity=< 3,  3>
position=<658, 785> velocity=< 3,  2>
position=<469, 691> velocity=< 5,  3>
position=<849, 977> velocity=< 1,  0>
position=<671, 498> velocity=< 3,  5>
position=<576, 404> velocity=< 4,  6>
position=<291, 785> velocity=< 7,  2>
position=<861, 501> velocity=< 1,  5>
position=<482, 972> velocity=< 5,  0>
position=<387, 692> velocity=< 6,  3>
position=<578, 686> velocity=< 4,  3>
position=<958, 883> velocity=< 0,  1>
position=<389, 591> velocity=< 6,  4>
position=<389, 979> velocity=< 6,  0>
position=<579, 505> velocity=< 4,  5>
position=<295, 401> velocity=< 7,  6>
position=<580, 505> velocity=< 4,  5>
position=<866, 876> velocity=< 1,  1>
position=<866, 315> velocity=< 1,  7>
position=<677, 306> velocity=< 3,  7>
position=<867, 505> velocity=< 1,  5>
position=<393, 686> velocity=< 6,  3>
position=<583, 409> velocity=< 4,  6>
position=<393, 315> velocity=< 6,  7>
position=<394, 401> velocity=< 6,  6>
position=<964, 972> velocity=< 0,  0>
position=<774, 974> velocity=< 2,  0>
position=<394, 314> velocity=< 6,  7>
position=<775, 879> velocity=< 2,  1>
position=<680, 883> velocity=< 3,  1>
position=<490, 979> velocity=< 5,  0>
position=<586, 404> velocity=< 4,  6>
position=<396, 405> velocity=< 6,  6>
position=<871, 786> velocity=< 1,  2>
position=<871, 977> velocity=< 1,  0>
position=<682, 501> velocity=< 3,  5>
position=<588, 406> velocity=< 4,  6>
position=<778, 312> velocity=< 2,  7>
position=<589, 502> velocity=< 4,  5>
position=<495, 977> velocity=< 5,  0>
position=<506, 318> velocity=< 5,  7>
position=<792, 508> velocity=< 2,  5>
position=<603, 401> velocity=< 4,  6>
position=<698, 687> velocity=< 3,  3>
position=<413, 878> velocity=< 6,  1>
position=<413, 974> velocity=< 6,  0>
position=<603, 785> velocity=< 4,  2>
position=<793, 982> velocity=< 2,  0>
position=<889, 971> velocity=< 1,  0>
position=<509, 500> velocity=< 5,  5>
position=<604, 691> velocity=< 4,  3>
position=<414, 407> velocity=< 6,  6>
position=<794, 788> velocity=< 2,  2>
position=<699, 697> velocity=< 3,  3>
position=<415, 306> velocity=< 6,  7>
position=<795, 599> velocity=< 2,  4>
position=<700, 792> velocity=< 3,  2>
position=<701, 496> velocity=< 3,  5>
position=<416, 410> velocity=< 6,  6>
position=<891, 316> velocity=< 1,  7>
position=<797, 505> velocity=< 2,  5>


Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2018, 05:09:30 pm

Quote from: Ben T on 11 December, 2018, 02:44:55 pm

Day 10 extension  :)

Excellent, found it but will need to work on an algorithm to detect when to stop as I had to manually step through once in the right area to get the exact frame.

(click to show/hide)

I think testing for:-
* adjacency
* min height
* max height
* bounding box area

and then using a combination of those to make the decision might be required

Title: Re: Advent of Code
Post by: Ben T on 11 December, 2018, 09:01:32 pm

Quote from: Greenbank on 11 December, 2018, 05:09:30 pm

Quote from: Ben T on 11 December, 2018, 02:44:55 pm

Day 10 extension  :)

Excellent, found it but will need to work on an algorithm to detect when to stop as I had to manually step through once in the right area to get the exact frame.

What does it say then? And at what time (frame)?

Quote from: Greenbank on 11 December, 2018, 05:09:30 pm

(click to show/hide)

I think testing for:-
* adjacency
* min height
* max height
* bounding box area

and then using a combination of those to make the decision might be required

You don't need all that - see #669  ...  https://yacf.co.uk/forum/index.php?topic=94710.msg2349625#msg2349625

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2018, 11:18:15 pm

Quote from: Ben T on 11 December, 2018, 09:01:32 pm

What does it say then? And at what time (frame)?

(click to show/hide)

Console output with font size set to 1pt:-

(http://www.greenbank.org/aoc/aoc2018day10extra.png)

Code: [Select]

$ cat inp.ben_t | ./10.pl | grep -v "^\.*$" | cut -b 1-40 | grep -A 20 t=94
t=94 987 14 983 16 sizes=940891 minsize=
-------------t=94------------------
..........###...........................
..........#.#...........................
..####....#..##.........................
.##..#....#...#.........................
.#...#...#....#.........................
.#....#..#....#.........................
#......#.#....#.........................
#......##...............................
#.......................................
#.......................................
....................##########..........
...................#.........#..........
.................##..........#..........
.................#.........##...........
.................#....#....#............
.................#.....#####............
.................#......................
..................#.....................
..................#.....................
...................#....................


Title: Re: Advent of Code
Post by: David Martin on 12 December, 2018, 12:24:38 am

Day 11 was nice. I have only got round to it but looked at it briefly at Makerspace tonight. One of my fellow hackers had done it naively and it took a while, so having the benefit of seeing part 2 I realised that

(click to show/hide)

a dynamic programming method was needed.

1. calculate all powers.
2. Cumulative sum across rows.
3. Cumulative sum of sums down columns.

This gives the cumulative sum from 0,0 (I ran from 0 to 300 setting all (0,y), (x,0) as 0). to (x,y)

Then you just need to calculate for x,y,size the following:
square from 0,0 to x+size-1, y+size-1
+ square from 0,0 to x-1,y-1
-rectangle from 0,0 to x-1, y+size-1
- rectangle from 0,0 to x+size-1, y-1

and find the x,y which maximises that.
I can't see a shorter way of doing it.
My rather slow computer ran that in python in a few (<10) seconds

Title: Re: Advent of Code
Post by: Greenbank on 12 December, 2018, 08:15:37 am

Day 12. Can't see why my part 2 is wrong.

Title: Re: Advent of Code
Post by: Diver300 on 12 December, 2018, 08:27:40 am

Quote from: Greenbank on 12 December, 2018, 08:15:37 am

Day 12. Can't see why my part 2 is wrong.

Nor me.

Title: Re: Advent of Code
Post by: Greenbank on 12 December, 2018, 09:08:58 am

(click to show/hide)

D'oh. Off by one (iteration) error.

Was printing out the running total after incrementing the time tick counter but before I'd done that iteration's work.

Title: Re: Advent of Code
Post by: Diver300 on 12 December, 2018, 09:10:52 am

Quote from: Diver300 on 12 December, 2018, 08:27:40 am

Quote from: Greenbank on 12 December, 2018, 08:15:37 am

Day 12. Can't see why my part 2 is wrong.

Nor me.

(click to show/hide)

Even though the final arrangements don't have plants in pots where n<0, and the start point doesn't either, some of the early intermediate arrangements do, so pots where n<0 need to be allowed for.

Title: Re: Advent of Code
Post by: Croft on 12 December, 2018, 05:19:05 pm

Quote from: David Martin on 12 December, 2018, 12:24:38 am

(click to show/hide)

a dynamic programming method was needed.

1. calculate all powers.
2. Cumulative sum across rows.
3. Cumulative sum of sums down columns.

This gives the cumulative sum from 0,0 (I ran from 0 to 300 setting all (0,y), (x,0) as 0). to (x,y)

Then you just need to calculate for x,y,size the following:
square from 0,0 to x+size-1, y+size-1
+ square from 0,0 to x-1,y-1
-rectangle from 0,0 to x-1, y+size-1
- rectangle from 0,0 to x+size-1, y-1

and find the x,y which maximises that.
I can't see a shorter way of doing it.
My rather slow computer ran that in python in a few (<10) seconds

Nice.

(click to show/hide)

That approach is used quite a lot in image processing when you need to make many rectangular brightness queries of a large image.

The only other optimisation I am aware of (apart from Greenbank's data-structure approach) would be to exploit the particular properties of the surface by terminating the window expansion once growing results in a significantly lower score (typically around the 25x25 size).

Title: Re: Advent of Code
Post by: Greenbank on 12 December, 2018, 10:50:26 pm

Quote from: Croft on 12 December, 2018, 05:19:05 pm

Quote from: David Martin on 12 December, 2018, 12:24:38 am

(click to show/hide)

a dynamic programming method was needed.

1. calculate all powers.
2. Cumulative sum across rows.
3. Cumulative sum of sums down columns.

This gives the cumulative sum from 0,0 (I ran from 0 to 300 setting all (0,y), (x,0) as 0). to (x,y)

Then you just need to calculate for x,y,size the following:
square from 0,0 to x+size-1, y+size-1
+ square from 0,0 to x-1,y-1
-rectangle from 0,0 to x-1, y+size-1
- rectangle from 0,0 to x+size-1, y-1

and find the x,y which maximises that.
I can't see a shorter way of doing it.
My rather slow computer ran that in python in a few (<10) seconds

Nice.

(click to show/hide)

That approach is used quite a lot in image processing when you need to make many rectangular brightness queries of a large image.

The only other optimisation I am aware of (apart from Greenbank's data-structure approach) would be to exploit the particular properties of the surface by terminating the window expansion once growing results in a significantly lower score (typically around the 25x25 size).

(click to show/hide)

Early exit is not an optimisation, it becomes a necessity if you're using an inefficient algorithm. If the real solution (using contrived data) was a square greater than, say 100, then something that bails at square size 25 is not going to find it.

The optimal algorithm (a simplified version of Kadane's 2D algorithm) works by taking the grid and making each cell the sum of itself and all cells above it, i.e. for a single column

Code: [Select]

. -> 0 (extra row of all 0 values)
A -> A
B -> A+B
C -> A+B+C
D -> A+B+C+D
...
Z -> A+B+C+D+E+...+X+Y+Z
...

If you build the original grid (calculating the power values) from top to bottom then this is just an extra addition when computing the value for each cell, since you only need to add the value of the cell above to the one you're just computing.

i.e. if you're computing cell D you work out the power value for row D and then add in the cell above which is already set to the sum A+B+C. When you get to row E you add in the value of the cell above which is A+B+C+D, etc.

If you're given a pre-computed grid then it's still just N*M addition operations that need to be performed to create this working grid.

Then, the partial sum of a column is just a single subtraction, i.e. to sum the 5 values from C downwards (i.e. C+D+E+F+G) you just need to subtract the value in row G from the value in row B as that works out as:-

A+B+C+D+E+F+G - (A+B) = C+D+E+F+G.

So, regardless of the number of cells in the partial column the calculation is just a single subtraction in order to sum all of those values.

If you imagine a square with sides of size 27 then, for the first square, you're still only doing 27 subtractions (to get each of the partial column sums) and then 27 additions (to add each of these together).
When you shift this square to the left once you just have to do one more subtraction (the partial sum of the next column) and one addition (to add that the to current square running total) and then another two subtractions (one to calculate the partial column total that is being removed from the left, and one to subtract that from the running total).

The important thing about this algorithm is that as the square size gets bigger the number of computations *decreases* (you still have to calculate all 300 partial column totals as you scan across the grid but you'll have to remove fewer of them, so there's less work involved). Most naive algorithms increase the number of individual computations as the square size approaches half the size of the grid. Also there are fewer rows to iterate over as the number of possible 'top' rows decreases as the size of square increases.

Kadane's 2D algorithm is a bit more complicated as it handles maximum sub *rectangles* in a matrix/grid, so there's an extra degree of freedom to make the naive algorithm O(n^4). It relies on Kadane's (1D) algorithm for maximum subset of a list which is needed to handle having a list of results instead of one result per square as a rectangle has that extra degree of freedom of the second side's size.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2018, 12:00:34 am

Quote from: Croft on 12 December, 2018, 05:19:05 pm

Quote from: David Martin on 12 December, 2018, 12:24:38 am

(click to show/hide)

a dynamic programming method was needed.

1. calculate all powers.
2. Cumulative sum across rows.
3. Cumulative sum of sums down columns.

This gives the cumulative sum from 0,0 (I ran from 0 to 300 setting all (0,y), (x,0) as 0). to (x,y)

Then you just need to calculate for x,y,size the following:
square from 0,0 to x+size-1, y+size-1
+ square from 0,0 to x-1,y-1
-rectangle from 0,0 to x-1, y+size-1
- rectangle from 0,0 to x+size-1, y-1

and find the x,y which maximises that.
I can't see a shorter way of doing it.
My rather slow computer ran that in python in a few (<10) seconds

Nice.

(click to show/hide)

That approach is used quite a lot in image processing when you need to make many rectangular brightness queries of a large image.

The only other optimisation I am aware of (apart from Greenbank's data-structure approach) would be to exploit the particular properties of the surface by terminating the window expansion once growing results in a significantly lower score (typically around the 25x25 size).

(click to show/hide)

My line of work is analysing DNA sequences and the classical algorithm is the Needleman-Wunsch (later updated to a Smith-Waterman-Gotoh).
This uses a similar approach for finding the best alignment of two sequences with gaps (adds a lot more complexity). SWG does the optimal aligning subsequences.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2018, 12:06:17 am

(click to show/hide)

I translated the input to a bitstring and use bitwise operations to read/build the new generation from the old.
Part 2 then will take about 5 million seconds using this approach so I am pretty sure there must be a better way. Maybe finding the largest previously seen matching number from that point  to do each section rather than repeating the same small mappings. Not got time to think about that now but will try that in the morning as the code will not have finished running by then. Need to find a big enough gap (4 zeros?) between numbers so that I have nonoverlapping patterns I can use.

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2018, 01:13:11 am

Got it - massive speed up.

(click to show/hide)

Make the search bit string much bigger than 5 bits - I've upped it to 20 bits and it is screaming through at about 1 million generations per second.
To bed now, unless it will finish very shortly...

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2018, 08:10:20 am

OK, not quite enough

(click to show/hide)

Really need to think about looking for repeated patterns over many iterations so I don't repeat every one individually. As there are 16 core transitions, there must be an optimisation in there somewhere (running at about 2 billion iterations per hour)

ETA: I'll look for the first repeat of a number and go from there straight to the last iteration. Save that for tonight.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2018, 09:37:27 am

(click to show/hide)

Print out the totals at the end of each iteration for the first few hundred iterations

It's not the answer but it will lead you in the right direction, up to you whether you read it obviously.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2018, 09:48:31 am

Day 13 done.

(click to show/hide)

Bit of a slog, largest one by far in terms of code (5172 bytes of perl, untidied/unrefactored - tend not to bother cleaning it up after getting the right answer).

Only problem was not reading the termination condition for part (b) properly and therefore giving another off-by-one answer.

Had worried that it was going to be made really tricky by including a few carts in a position on a corner or intersection like this:-

Code: [Select]

  v--
  |

or:-

Code: [Select]

  | 
 -v-
  |

As that would have made working out what the underlying grid looked like a lot trickier, but stuff like that never appeared in my example input.

Looking forward to the first pseudo-assembly-language type question of 2018. I liked those from previous years.

Title: Re: Advent of Code
Post by: Croft on 13 December, 2018, 10:26:02 am

Quote from: Greenbank on 13 December, 2018, 09:48:31 am

(click to show/hide)

Had worried that it was going to be made really tricky by including a few carts in a position on a corner or intersection like this:-

Code: [Select]

  v--
  |

or:-

Code: [Select]

  | 
 -v-
  |

As that would have made working out what the underlying grid looked like a lot trickier, but stuff like that never appeared in my example input.

(click to show/hide)

If the tracks under the initial placement of carts were not  'straights' presumably it would be simple to infer the shape by looking at its neighbours (helped by the fact there are no T-junctions)...

except, that if some of the neighbours were themselves hidden under carts, that would make it more complicated....

which would lead to a nice extension to the problem  where you were presented with only one initial inferable hidden track shape and plenty of initially uninferable ones, that once inferred, would yield another etc. (i.e. requiring a topological sort much like the sleigh assembly problem).

Title: Re: Advent of Code
Post by: David Martin on 13 December, 2018, 12:58:04 pm

Quote from: Greenbank on 13 December, 2018, 09:37:27 am

(click to show/hide)

Print out the totals at the end of each iteration for the first few hundred iterations

It's not the answer but it will lead you in the right direction, up to you whether you read it obviously.

interesting idea. Will try that.

Title: Re: Advent of Code
Post by: Diver300 on 14 December, 2018, 08:17:01 am

Day 14, part 2

(click to show/hide)

My answer was over 20 million.

(click to show/hide)

MY puzzle input ended in 1, so the last digit of my puzzle input appeared in the list with a digit after it. My initial search for my puzzle input was only on the last characters of the list, so no answer appeared until I added a search on the characters that ended one back from the end.

Title: Re: Advent of Code
Post by: Greenbank on 14 December, 2018, 11:46:05 am

(click to show/hide)

Took a while for my hungover brain to process things this morning.

I'd expect that he specifically chose puzzle inputs for everyone where the answer appears when you add two numbers, just to trip up people who were only searching for it after each iteration (it got me too until I spotted it).

He also carefully chooses his examples so they don't exhibit this behaviour so you don't spot it if you use the examples as test cases.

Title: Re: Advent of Code
Post by: David Martin on 14 December, 2018, 08:45:52 pm

Quote from: David Martin on 13 December, 2018, 12:58:04 pm

Quote from: Greenbank on 13 December, 2018, 09:37:27 am

(click to show/hide)

Print out the totals at the end of each iteration for the first few hundred iterations

It's not the answer but it will lead you in the right direction, up to you whether you read it obviously.

interesting idea. Will try that.

Been rather busy so AoC has been on hold.

(click to show/hide)

So I had got a massive speed up by playing around with larger word sizes, which was still too slow.
I therefore checked for cycles and that worked very rapidly, but they gave the wrong answer when I tried it with larger words so reverted to the original generation codes and it was straightforward.

Now onward and upward.

Title: Re: Advent of Code
Post by: David Martin on 14 December, 2018, 10:48:23 pm

(click to show/hide)

Many silly errors (like using .strip() to remove the newline on data input which also wrecked the data by removing essential leading whitespace - D'Oh)
Ended up with a nice class for each cart that knew where it was and where it had been. Very easy then to solve part 2.

Title: Re: Advent of Code
Post by: David Martin on 15 December, 2018, 10:48:14 am

(click to show/hide)

Another happily circular linked list. I kept track of the first node and prepended to it rather than add to the end of the list. Each elf knew their own place in the list.

Yes I was caught briefly by the 'adding two and only checking each cycle' thing before I wasted too much time.

Title: Re: Advent of Code
Post by: David Martin on 15 December, 2018, 10:52:38 am

Day 15. It has taken so long to read the question and it will be a long time to code. Other things to do so I might come back to it later. Trying to think of how I can avoid calculating a shortest path every time, though it is easy to only calculate one per round per enemy.

Later

Title: Re: Advent of Code
Post by: Greenbank on 15 December, 2018, 08:23:47 pm

Oof, hungover and family around but managed to get Day 15 done.

Hours. Hours and hours. Oof.

Will rework it tomorrow if/when I have time.

Title: Re: Advent of Code
Post by: Greenbank on 16 December, 2018, 03:12:29 pm

Day 16: Wasted far too long chasing a silly bug in the implementation of one of the opcodes which made part (a) give the wrong answer.

Guessed at what part (b) would be so implemented part (a) in a way that would make it easier without a load of rework.

Title: Re: Advent of Code
Post by: Ben T on 16 December, 2018, 04:29:02 pm

My code for Day 15's horrible. Lots of nested loops with break-outs, inline functions and branches. Eugh.   ::-) ;D

(click to show/hide)

Part 1 takes a few (<10) seconds.
Part 2 takes about O(n) where n is the min attack power, but I think I can optimize it to being more like O(n^x) where x < 1 with better caching of the distances - at the moment the cache lives with the board, and when a new calculation for a different starting attack power is done it throws away the cache, even though the movement is agnostic to the attack power.

Title: Re: Advent of Code
Post by: David Martin on 16 December, 2018, 08:29:08 pm

Horrible cold so I have put day 15 and 16 on hold for the moment. Will return when my brain does.

Title: Re: Advent of Code
Post by: Greenbank on 16 December, 2018, 11:52:23 pm

Quote from: Ben T on 16 December, 2018, 04:29:02 pm

My code for Day 15's horrible. Lots of nested loops with break-outs, inline functions and branches. Eugh.   ::-) ;D

(click to show/hide)

Part 1 takes a few (<10) seconds.
Part 2 takes about O(n) where n is the min attack power, but I think I can optimize it to being more like O(n^x) where x < 1 with better caching of the distances - at the moment the cache lives with the board, and when a new calculation for a different starting attack power is done it throws away the cache, even though the movement is agnostic to the attack power.

(click to show/hide)

The problem is that the distances can change as the goblins/elves move around (blocking some routes, acting as obstacles, etc), so I can't see how caching things would help.

A more sensible fill algorithm should help, I think that's where my code is spending way too much time (no easy profiling in perl).

For example, my current solution takes 17s for each of the first few iterations (at elf attack power = 3). Whilst it took ~3.5min to test a possible attack power it didn't take a huge amount of time to find the answer by a kind of binary search guided by hand (found it after the 6th value) whilst half watching Strictly with my daughter and going to prod the computer between each dance.

It should be possible to find the answer for part b in under a second although might need to be done in C rather than perl for that speed.

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2018, 11:52:29 am

Missing something in Day 17. Part (a) answer is correct but part (b) is wrong and can't see why.

(click to show/hide)

I'm not far off. First guess (n) was too low. Looked at the final output and wondered whether a box being up against the left edge (with the right lip higher) was causing the problem so added 14 on and guessed again, but that was too high.

So my answer is somewhere between n and n+14 but can't see why.

Ah, found this snippet that it obviously wasn't handling properly:-

Code: [Select]

................|......................|............|...........
................|......................|............|...........
..#|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~#.#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~#.#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~#.#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~###~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..###########################################################|..
.............................................................|..

And fixed the code to handle that and n+3 was accepted for part (b).

But this means my part (a) answer was wrong (it's now 3 higher) but the original value was accepted. Very odd.

Title: Re: Advent of Code
Post by: Ben T on 17 December, 2018, 02:31:07 pm

Quote from: Greenbank on 16 December, 2018, 11:52:23 pm

Quote from: Ben T on 16 December, 2018, 04:29:02 pm

My code for Day 15's horrible. Lots of nested loops with break-outs, inline functions and branches. Eugh.   ::-) ;D

(click to show/hide)

Part 1 takes a few (<10) seconds.
Part 2 takes about O(n) where n is the min attack power, but I think I can optimize it to being more like O(n^x) where x < 1 with better caching of the distances - at the moment the cache lives with the board, and when a new calculation for a different starting attack power is done it throws away the cache, even though the movement is agnostic to the attack power.

(click to show/hide)

The problem is that the distances can change as the goblins/elves move around (blocking some routes, acting as obstacles, etc), so I can't see how caching things would help.

A more sensible fill algorithm should help, I think that's where my code is spending way too much time (no easy profiling in perl).

For example, my current solution takes 17s for each of the first few iterations (at elf attack power = 3). Whilst it took ~3.5min to test a possible attack power it didn't take a huge amount of time to find the answer by a kind of binary search guided by hand (found it after the 6th value) whilst half watching Strictly with my daughter and going to prod the computer between each dance.

It should be possible to find the answer for part b in under a second although might need to be done in C rather than perl for that speed.

(click to show/hide)

My current one takes 1 min 18 s for part 2 (my min attack power for elves to win was about 34) just looping from 3 to 34, no binary chop.
Although for numerous iterations, it has zero cache misses for routing but the iteration still takes a few seconds, so there must be something else taking a bit of time, will profile when at home to find out what.
Refined the cache to be static, and the 'signature' of the board (locations of rock/other units that can't be moved through) part of the cache key.
Probably much faster in C++.
Not particularly pretty: https://github.com/bjtaylor1/AoC2018/blob/day15part2/Day15/Program.cs
where 'Board' is: https://github.com/bjtaylor1/AoC2018/blob/day15part2/AoCLib/Board.cs

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2018, 03:47:48 pm

Day 15: Some people go a little over the top on their visualisations:

https://www.reddit.com/r/adventofcode/comments/a6sej7/day_15_unity_visualization/

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2018, 08:54:55 pm

(click to show/hide)

Spent a bit of time optimising mine and got it a bit faster. (I was storing the elf/goblin locations in a hash instead of the grid so my fill algorithm for the first step stuff was looping through each element of the hash for each cell it was checking, put them in a separate 2D array that I keep up to date and that part is 10 times faster)

Part b takes ~47s in perl using a binary search (handles the answer being anywhere between 3 and 200[1]) for my input.

101, 52, 27, 39, 33, 30, 28, 29

Each test takes between 3 and 7 seconds (on my puzzle input) so there's still a lot of work that could be done, but it's good enough for me now. Reimplementing in C would make it considerably faster I guess but ICBA.

1. Probably won't work if they needed to be 200 attack power but hey-ho.

Title: Re: Advent of Code
Post by: Greenbank on 18 December, 2018, 10:21:45 am

Nice to have a relatively simple one again today. Lucky as I have lots of real work to do!

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2018, 09:42:32 am

I suppose I did ask for a psuedo assembly language one.

(click to show/hide)

After a bit of inspection I guessed what it was doing and calculated the answer. Luckily I was right.

[EDIT] After some more looking at it any attempt to make a virtual CPU faster is pretty much pointless. For my input I'd need to process somewhere around 882 trillion instructions. Even at a healthy 1billion/second (i.e. a 1GHz virtual-CPU) that's still 245 hours (10 and a bit days).

Title: Re: Advent of Code
Post by: Greenbank on 20 December, 2018, 07:05:16 pm

(click to show/hide)

Oof, chased a parser bug for far too long (especially when I'd assumed the parser was fine and I was looking in some other code).

Absolutely lovely feeling when I finally found the last bug and out popped the map for my input. Going from there to the answer for part (a) was a few minutes, and then under a minute to get part (b).

Did wonder about the wording, had thought it was asking for the longest path that didn't repeat rooms rather than the longest shortest path.

But, far too long to get to from the input to a map. Ugh.

Code (perl) runs in under half a second.

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2018, 11:19:37 am

Interesting one today, but a bit of a slog to the answer.

(click to show/hide)

I identified the small loop that was taking the majority of the time and gave it a helping hand, ran much quicker after that.

The recent challenges have seemed harder than in recent years, I wonder if this is responsible for, what looks like, a drop in participation.

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2018, 11:57:09 am

Also liked this touch:

"Clearly, the Elves who wrote this system were worried that someone might introduce a bug while trying to emulate this system with a scripting language."

(click to show/hide)

Here's the first couple of instructions worth of my input shoved through my original perl code from day 19:-

Code: [Select]

$ cat inp.final | ../19/19.pl | head
iter=1 ip=0 [1, 0, 0, 0, 0, 0] seti 123 0 5 [1, 0, 0, 0, 0, 123]
iter=2 ip=1 [1, 0, 1, 0, 0, 123] bani 5 456 5 [1, 0, 1, 0, 0, 002]

So r5 (123) ANDed with '456' gives octal 002. Nice.

Title: Re: Advent of Code
Post by: Ben T on 21 December, 2018, 12:00:10 pm

Still stuck on day 17, havent' tried any subsequent ones - have had to go out to the shops for new jelly and nails as I keep running out, and start again in a new room with a fresh ceiling.

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2018, 03:02:13 pm

Quote from: Ben T on 21 December, 2018, 12:00:10 pm

Still stuck on day 17, havent' tried any subsequent ones - have had to go out to the shops for new jelly and nails as I keep running out, and start again in a new room with a fresh ceiling.

Ooh. What's the problem? Wrong answer, not fast enough or just can't get it to work properly at all?

I had a bug in mine where it wouldn't accept my answer for part (b), when I eventually fixed it I got the right answer for part (b) but the answer it gave for part (a) changed as well but my original (now incorrect) answer for part (a) was accepted.

Title: Re: Advent of Code
Post by: Ben T on 21 December, 2018, 08:07:53 pm

Quote from: Greenbank on 21 December, 2018, 03:02:13 pm

Quote from: Ben T on 21 December, 2018, 12:00:10 pm

Still stuck on day 17, havent' tried any subsequent ones - have had to go out to the shops for new jelly and nails as I keep running out, and start again in a new room with a fresh ceiling.

Ooh. What's the problem? Wrong answer, not fast enough or just can't get it to work properly at all?

I had a bug in mine where it wouldn't accept my answer for part (b), when I eventually fixed it I got the right answer for part (b) but the answer it gave for part (a) changed as well but my original (now incorrect) answer for part (a) was accepted.

I've come up with an answer but it doesn't accept it at all.
I have produced a pretty picture of what it looks like: https://1drv.ms/u/s!AtNSfl0sxZVlgZIQQ8xv9FsIru8Jww

I have got a loop which I can't figure out how to exit, but at the point where it is not finding any new tiles the situation is as the picture above (should open in paint or simple bmp editor), and it gets to that situation in under a second.
I guessed

(click to show/hide)

38026, and it said that was too high. So there must be some tiles in the above pic that are wet, but shouldn't be??  :-\ but can't see which. (I  then guessed 38025 as I thought the tap itself might give an off by one error, but it just said 'incorrect' and to wait 5 minutes, so I guess that must be too high as well.
My input is
https://1drv.ms/t/s!AtNSfl0sxZVlgZIRXFxaCnxLRvnHNg

code is https://github.com/bjtaylor1/AoC2018/blob/day17try2/Day17Vis/Program.cs but wouldn't try and read it, it's pretty indecipherable tbh!  :facepalm:

I could rewrite it but at the moment, either the puzzle's wrong, or there's something I'm fundamentally not understanding about the spec.

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2018, 08:25:11 pm

FWIW, my program agrees with yours for your input. I get the same answer and I can't see anything wrong in the output.

My previous version the program also gives the same answer (even though it exhibits a bug with my input).

I'd move on.

Title: Re: Advent of Code
Post by: Ben T on 21 December, 2018, 08:35:12 pm

Quote from: Greenbank on 21 December, 2018, 08:25:11 pm

FWIW, my program agrees with yours for your input. I get the same answer and I can't see anything wrong in the output.

My previous version the program also gives the same answer (even though it exhibits a bug with my input).

I'd move on.

Groan............... found it,

(click to show/hide)

the crucial bit is "To prevent counting forever, ignore tiles with a y coordinate smaller than the smallest y coordinate in your scan data or larger than the largest one."

This bit is misleading I think.
It's only counting larger than the largest y coordinate that prevents counting forever, but you also need to exclude tiles that are wet that are shallower than the shallowest bit of clay.

My shallowest bit of clay is at y coordinate 6, so my answer is 38021 and it has accepted that.

Must admit I did look on the subreddit for that. Can move on now, can't leave it incomplete!

Title: Re: Advent of Code
Post by: Ben T on 21 December, 2018, 08:40:17 pm

Ah - part 2 was easy for my algorithm.

(click to show/hide)

I had feared it was going to say "now, you suddenly realise that water pressure does matter ..."  ;D

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2018, 08:49:26 pm

Quote from: Ben T on 21 December, 2018, 08:35:12 pm

Groan............... found it,

(click to show/hide)

the crucial bit is "To prevent counting forever, ignore tiles with a y coordinate smaller than the smallest y coordinate in your scan data or larger than the largest one."

This bit is misleading I think.
It's only counting larger than the largest y coordinate that prevents counting forever, but you also need to exclude tiles that are wet that are shallower than the shallowest bit of clay.

My shallowest bit of clay is at y coordinate 6, so my answer is 38021 and it has accepted that.

Must admit I did look on the subreddit for that. Can move on now, can't leave it incomplete!

(click to show/hide)

Ah, that explains it, and my problem too, thanks!

As noted above I had a section where a little 1x3 section wasn't filled in properly:-

Code: [Select]

................|......................|............|...........
................|......................|............|...........
..#|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~#.#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~#.#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~#.#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~###~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#|..
..###########################################################|..
.............................................................|..

but I still got the correct answer for part (a). That was due to my input having the highest part of clay at y=4:-

$ grep "y=[0-5]\.\." inp.final
x=608, y=4..6
x=584, y=4..6

so that would mean I wouldn't count the 3 vertical bits of water.

Which is why my incorrect answer for part (a) was actually correct, the 3 missing bits of water were balanced by the 3 extra bits I was counting at the top. That was very lucky!

When I fixed the unfilled in bit it for part (b) I was only counting the standing water so my miscounting of flowing water didn't affect the answer.

Title: Re: Advent of Code
Post by: Greenbank on 22 December, 2018, 11:10:25 am

(click to show/hide)

BFS with a little twist, didn't have to consider items too far out of the original area (14 to the right of the target, nothing below the target, but everyone's input will be different obvs).

I kept track of 3-tuples ( x, y, current_equip -> min_time ) in a hash(map) pushing new items onto the end of a 'todo' list if I found a way to get to that tuple quicker. i.e.

initial item: 0,0,T -> 0

Then tries:-
* 0,0,C -> 7
* 0,0,N -> 7 can't do this as we can't have 'neither' equipment on a rocky square
* If 1,0 is wet then can't go from 0,0,T to 1,0,T.
* If 0,1 is rocky then we add 0,1,T -> 1
...etc...

Pulls 0,0,C -> 7 off list:-
* 0,0,T -> 14 is worse than existing 0,0,T -> 0
* Can't change to 0,0,N because 0,0 is rocky and you need either T or C equipment for rocky.
Try moving left, right, up, down, etc
...etc...

When pulling stuff off the 'todo' list I'd skip it if the current time taken was greater than my current record for getting to the target (if it had been reached). [Spent a bit of time getting the wrong answer as I wasn't ensuring the Torch was in use at the end, so I'd get a score of 38 for the example input at first.)

With an extra buffer of 20x20 onto my map past the target my perl script takes ~8s to get the answer. Can't be bothered to optimise it.
Adding an extra buffer of 1000x1000 onto my map makes it take 84s.

Title: Re: Advent of Code
Post by: Greenbank on 23 December, 2018, 11:04:15 am

Ooh, day 23 part b looks like a stinker, have ideas and not going to look anywhere for hints. Might take a while!

[EDIT] Got the answer for part b but not satisfied with my method at all. It doesn't work at all on the simple example given in the problem.

Some details in this spoiler.

(click to show/hide)

I'd assumed it was going to be a relatively straightforward rather than a contrived solution that was really difficult to locate, based on this I did:-

Found the co-ordinate of a nanobot that is in range of the most number of other nanobots. This was my starting x,y,z and was in range of 825 nanobots.

With my 'current' x,y,z I tried two things:-

a) Testing whether nearby points were in range of more nanobots and, if not,
b) trying to reduce x, y or z as much as possible (in terms of manhattan distance from the 0,0,0 origin) without letting the number of nanobots in range drop.

At first 'nearby' was 5000 points, i.e. I'd test:-
* x+5000,y,z
* x-5000,y,z
* x,y+5000,z
* x,y-5000,z
* x,y,z+5000
* x,y,z-5000

If any of those produced a higher number of nanobots in range then that was my new x,y,z for the next iteration.
If none of those produced a new higher number of nanobots in range I'd pick any of x-5000,y,z or x,y-5000,z or x,y,z-5000 for the next iteration as long as the number of robots in range didn't decrease.

And, as that found a local maxima I reduced it from 5000 to 500, then 50, then 10 and finally 1 to hone in on the final spot which was in range of 860 nanobots (for my input data).

(Oddly, starting it again at 0,0,0 with an initial diff of 1024*1024*1024 and halving that each time to hone in on the final solution, has me end up at a quite different set of x,y,z co-ords but with the same total manhattan distance as my original answer but in range of 914 nanobots. I guess there's something about the placing/sizes of the octohedrons described by each nanobots range that I'm just not able to visualise.)

All in all, I'm surprised this worked and gave me the right answer.

It doesn't work for the example given as it moves from 12,14,12 (3) to 11,14,12 (3) to 10,14,12 (4) and never finds 12,12,12 although 10,14,12 does have the same answer (in terms of manhattan distance of 36) as the proper answer.

Title: Re: Advent of Code
Post by: Ben T on 23 December, 2018, 06:55:44 pm

Quite enjoyed day 19.

(click to show/hide)

Once I had a certain amount of information a quick search on OEIS yielded the answer to what the algorithm was trying to do, but probably wouldn't have taken long to spot it without.

Title: Re: Advent of Code
Post by: Ben T on 23 December, 2018, 08:34:17 pm

Quote from: Greenbank on 20 December, 2018, 07:05:16 pm

(click to show/hide)

Oof, chased a parser bug for far too long (especially when I'd assumed the parser was fine and I was looking in some other code).

Absolutely lovely feeling when I finally found the last bug and out popped the map for my input. Going from there to the answer for part (a) was a few minutes, and then under a minute to get part (b).

Did wonder about the wording, had thought it was asking for the longest path that didn't repeat rooms rather than the longest shortest path.

But, far too long to get to from the input to a map. Ugh.

Code (perl) runs in under half a second.

(click to show/hide)

Nice use of a recursive algorithm for Day 20.

Didn't take too long at all, would have been even quicker if I'd realised that std::map::insert doesn't throw an exception if you try and insert a duplicate key, despite the fact that std::map::insert_or_assign exists  :-\ that had me thinking that because it hadn't thrown an exception, there must only be 1 possible route to each room.
Seems it behaves like std::set::insert, and just doesn't do anything if the key already exists.
Runs instantly https://github.com/bjtaylor1/AoC2018/blob/master/Day20/Day20.cpp.

Title: Re: Advent of Code
Post by: Ben T on 24 December, 2018, 03:27:03 pm

Done day 21... dog alone knows what the algorithm is trying to do, unlike 19 that there actually seems to be a point to it.

(click to show/hide)

Just seemed to be a case of short-cirtuiting the loop of lines 18-26, then noting the value of r4 whenever r0 is accessed, because r4 comparing to r0 is what causes the program to exit.
https://github.com/bjtaylor1/AoC2018/blob/master/Day21/Day21.cpp

Title: Re: Advent of Code
Post by: Pickled Onion on 24 December, 2018, 07:47:23 pm

Quote from: Greenbank on 23 December, 2018, 11:04:15 am

Ooh, day 23 part b looks like a stinker, have ideas and not going to look anywhere for hints. Might take a while!
[EDIT] Got the answer for part b but not satisfied with my method at all. It doesn't work at all on the simple example given in the problem.

My method was something similar but opposite results - it worked for the example but unfortunately not the real data  :(

Title: Re: Advent of Code
Post by: Ben T on 25 December, 2018, 07:24:28 pm

Quote from: Greenbank on 23 December, 2018, 11:04:15 am

Ooh, day 23 part b looks like a stinker, have ideas and not going to look anywhere for hints. Might take a while!

[EDIT] Got the answer for part b but not satisfied with my method at all. It doesn't work at all on the simple example given in the problem.

Some details in this spoiler.

(click to show/hide)

I'd assumed it was going to be a relatively straightforward rather than a contrived solution that was really difficult to locate, based on this I did:-

Found the co-ordinate of a nanobot that is in range of the most number of other nanobots. This was my starting x,y,z and was in range of 825 nanobots.

With my 'current' x,y,z I tried two things:-

a) Testing whether nearby points were in range of more nanobots and, if not,
b) trying to reduce x, y or z as much as possible (in terms of manhattan distance from the 0,0,0 origin) without letting the number of nanobots in range drop.

At first 'nearby' was 5000 points, i.e. I'd test:-
* x+5000,y,z
* x-5000,y,z
* x,y+5000,z
* x,y-5000,z
* x,y,z+5000
* x,y,z-5000

If any of those produced a higher number of nanobots in range then that was my new x,y,z for the next iteration.
If none of those produced a new higher number of nanobots in range I'd pick any of x-5000,y,z or x,y-5000,z or x,y,z-5000 for the next iteration as long as the number of robots in range didn't decrease.

And, as that found a local maxima I reduced it from 5000 to 500, then 50, then 10 and finally 1 to hone in on the final spot which was in range of 860 nanobots (for my input data).

(Oddly, starting it again at 0,0,0 with an initial diff of 1024*1024*1024 and halving that each time to hone in on the final solution, has me end up at a quite different set of x,y,z co-ords but with the same total manhattan distance as my original answer but in range of 914 nanobots. I guess there's something about the placing/sizes of the octohedrons described by each nanobots range that I'm just not able to visualise.)

All in all, I'm surprised this worked and gave me the right answer.

It doesn't work for the example given as it moves from 12,14,12 (3) to 11,14,12 (3) to 10,14,12 (4) and never finds 12,12,12 although 10,14,12 does have the same answer (in terms of manhattan distance of 36) as the proper answer.

To be honest I had absolutely no idea.
However if you read this (contains spoiler) (https://raw.githack.com/ypsu/experiments/master/aoc2018day23/vis.html), the methodology makes perfect sense and from the description of the method, I was able to code it in C++ (https://github.com/bjtaylor1/AoC2018/blob/master/Day23/Day23.cpp) purely from my understanding of the method, and without looking at his algorithm. But I've got to admit, I'm not sure I would have come up with that idea on my own.

(click to show/hide)

I guess it is a type of depth first search?

What slightly foxed me is the equivalence of a single point, to a cube of unit size.
The number of nanobots within reach of a any point in* a cube of side 2^n is the same as the number in reach of a single point (i.e., the answer) when n = 0 (i.e. cube is of size 1).

* where 'in' the cube means x >= cx and x < cx + size, with the "size -1" in https://github.com/bjtaylor1/AoC2018/blob/ccd4080553df5593c385a1b2605c8225ca00f320/Day23/Day23.cpp#L32-L34 bringing about the exclusive upper bound of the cube.

Would be quite interesting to genericize the algorithm to n dimensions.

Well done to anybody who got the answer without looking up a method.

Title: Re: Advent of Code
Post by: Pickled Onion on 26 December, 2018, 11:31:19 am

Quote from: Pickled Onion on 24 December, 2018, 07:47:23 pm

Quote from: Greenbank on 23 December, 2018, 11:04:15 am

Ooh, day 23 part b looks like a stinker, have ideas and not going to look anywhere for hints. Might take a while!
[EDIT] Got the answer for part b but not satisfied with my method at all. It doesn't work at all on the simple example given in the problem.

My method was something similar but opposite results - it worked for the example but unfortunately not the real data  :(

Finally got it.

(click to show/hide)

My method for homing in landed me in in an area in range of 936 nanobots which appeared to be small. It turned out to be a very thin and very long region. 1 x 1 x millions. At one end of the region it overlapped with a few more bots. My initial search had landed me at the opposite end  :(

Title: Re: Advent of Code
Post by: Greenbank on 27 December, 2018, 11:53:38 am

Finished now (didn't get a chance to do more than a few minutes during the last 3 days).

Wasted a bit of time with a misreading of the 24th but got it in 10 minutes this morning and part 2 followed on simply. Not a big fan of big wordy plods like this, but they're quite representative of real world coding with slightly imprecise specs and long slogs of boring programming!

Title: Re: Advent of Code
Post by: Ben T on 27 December, 2018, 05:08:35 pm

Quote from: Greenbank on 27 December, 2018, 11:53:38 am

Finished now (didn't get a chance to do more than a few minutes during the last 3 days).

Wasted a bit of time with a misreading of the 24th but got it in 10 minutes this morning and part 2 followed on simply. Not a big fan of big wordy plods like this, but they're quite representative of real world coding with slightly imprecise specs and long slogs of boring programming!

 :-\ :-\ Not sure where you work - but can I have a job there?!

Whilst I think it's nice that AoC has presented a dimension of difficulty in terms of having a verbose, complicated spec - I would disagree that they're representative - I would say that AoC specs are far, far better written and more concise than real world specs.
 :)

e.g. AoC
Spec: "During the target selection phase, each group attempts to choose one target. In decreasing order of effective power, groups choose their targets; in a tie, the group with the higher initiative chooses first. The attacking group chooses to target the group in the enemy army to which it would deal the most damage (after accounting for weaknesses and immunities, but not accounting for whether the defending group has enough units to actually receive all of that damage)."

Real world would be:
Spec: "The strongest [sic] attack first."
Dev: " 'Strongest' meaning? The one with the most power, or the most units?"
Sponsor: "Oh, er... the one with the most power."
Dev: "Ok."
Later:
Sponsor: "This is a BUG! Unit C has attacked before unit D!"
Dev: "Yes, well, they've both got the same power. As designed."
Sponsor: "Yes but D has got higher initiative!"
Dev: "You didn't say anything about higher initiative attacking first in the event of a tie."
Sponsor: "Well, that should have been obvious!"

Recent AoC problems like Day 24 test the skill of data modelling, as well as just procedural logic.

I don't think any of the specs have been ambiguous. Some have been confusing, particularly Day 17, which required reading every single bit of it very very carefully, with crucial detail being in the letter rather than the spirit of the rules, but I don't think any have actually required a leap of faith or reading between the lines, or been noticeably ambiguous.

Clarifications like 'not accounting for whether the defending group has enough units to actually receive all of that damage' are the exact sort of things that are missing from real world specs as it is the sort of thing only a developer would think about.
In reality, if you were programming a real army, some devs might decide that the sponsor wouldn't want to see a powerful unit "waste" an attack on one that is already nearly dead, and insert that into the logic, even though the sponsor didn't specify that - but other devs might not. Here, he's thought about it from the programmer's point of view and clarified it.

Title: Re: Advent of Code
Post by: Ben T on 27 December, 2018, 11:44:40 pm

What was a bit sneaky though was

(click to show/hide)

putting "immune" and "weakness" in a different order on some input data to others  ::-)

Title: Re: Advent of Code
Post by: SoreTween on 06 January, 2019, 10:39:20 am

Quote from: Greenbank on 13 December, 2018, 09:37:27 am

(click to show/hide)

Print out the totals at the end of each iteration for the first few hundred iterations

It's not the answer but it will lead you in the right direction, up to you whether you read it obviously.

(click to show/hide)

Oh ffs  :facepalm: Why didn't I think to look for a pattern there? I was on the point of giving up. Thanks Greenbank

Title: Re: Advent of Code
Post by: Greenbank on 08 January, 2019, 11:32:22 am

"271 people have gotten all 200 stars over the four years of #AdventOfCode."

https://twitter.com/ericwastl/status/1082420178510667781

:smug:

Title: Re: Advent of Code
Post by: Greenbank on 22 November, 2019, 09:04:53 am

9 days to go until #AdventOfCode 2019

(Already donated so I have my AOC++ badge for 2019).

Title: Re: Advent of Code
Post by: Greenbank on 01 December, 2019, 09:42:50 am

Day 1 2019.

Didn't read part b properly (as usual) and made the expected mistake, easily fixed though.

Find the first few days a bit underwhelming after the anticipation, looking forward to a nice meaty problem.

Title: Re: Advent of Code
Post by: Greenbank on 02 December, 2019, 09:26:17 am

Day 2 2019 (no need for spoiler tags yet).

"Good, the new computer seems to be working correctly! Keep it nearby during this mission - you'll probably use it again. Real Intcode computers support many more features than your new one, but we'll let you know what they are as you need them."

I guess this is going to be one of the themes for this year. I'll spend a bit of time making sure it's nicely cleaned up and ready for inclusion in the aoc/2019 directory rather than buried in a specific day's directory.

Title: Re: Advent of Code
Post by: Greenbank on 03 December, 2019, 10:50:40 am

Day 3 2019 (no spoiler tags required)

Today's small delay was caused by a typo in some regex. I initially had /^U(\d)+$/ instead of /^U(\d+)$/ when extracting the number of steps on each instruction (and copy-pasta'd for the other directions). Thankfully the basic test cases provided made it very easy to spot that there was a problem.

Title: Re: Advent of Code
Post by: vorsprung on 03 December, 2019, 05:27:53 pm

ICBA this year.  I am interviewing at the moment and have various "tech tasks" to do of random IT puzzles

"no, we don't mind what skills you have.  We are looking for a good attitude and general grasp.  Here's the tech task, should take 4-5 hours"  Yeah right 4-5 hours if I had EXACTLY the same experience as your inhouse staff :(

Title: Re: Advent of Code
Post by: Pickled Onion on 03 December, 2019, 06:32:07 pm

This year I'm doing them in C# instead of Perl. The gains from a nice test framework and intellisense are more than cancelled out by the sheer wordiness of it all.

Delay today caused by trying to dump all the points into Lists and do a Linq intersect to pop out all the crossings. Great for the tests, way too slow for the full puzzle - didn't expect to get hit by that on day 3. So had to go back and do it again properly. 174 lines of code + tests, would probably have been about ten in Perl.

Title: Re: Advent of Code
Post by: vorsprung on 03 December, 2019, 08:56:50 pm

Quote from: Pickled Onion on 03 December, 2019, 06:32:07 pm

This year I'm doing them in C# instead of Perl. ... 174 lines of code + tests, would probably have been about ten in Perl.

That's progress!

Title: Re: Advent of Code
Post by: Greenbank on 03 December, 2019, 11:48:29 pm

$ wc -l 3?.pl
  52 3a.pl
  58 3b.pl

I tend to copy the file when I start part b as I hack what I've done rather than trying to come up with a single program that does both. The difference between this particular day's a and b parts were 6 new lines in b (keeping track of steps to each point) and 4 lines changed (which dealt with keeping track of the minimum step values for a crossing instead of the minimum manhattan distance).

0 lines of tests. ;)

Title: Re: Advent of Code
Post by: Ben T on 04 December, 2019, 08:52:48 am

Quote from: Pickled Onion on 03 December, 2019, 06:32:07 pm

This year I'm doing them in C# instead of Perl. The gains from a nice test framework and intellisense are more than cancelled out by the sheer wordiness of it all.

Delay today caused by trying to dump all the points into Lists and do a Linq intersect to pop out all the crossings. Great for the tests, way too slow for the full puzzle - didn't expect to get hit by that on day 3. So had to go back and do it again properly. 174 lines of code + tests, would probably have been about ten in Perl.

I tried a linq intersect, found it slow, but then I applied an optimization: remove all points from wire A outside the bounding box of wire B. Remove all points from wire B outside the bounding box of wire A. Do it iteratively till you remove no more.
Ran in 28 seconds.
It is matching ~70,000 x 70,000 instead of ~150,000 x ~150,000.

Title: Re: Advent of Code
Post by: Greenbank on 04 December, 2019, 09:30:21 am

28 seconds?

(click to show/hide)

You only need to store the positions visited by one of the wires, not both.

Trace the route marking co-ordinates visited by wire A in a hash (using x,y as the key) storing the minimum number of steps to get to each point ( x,y -> <nosstep_A> )
   i.e. don't update it with a higher value if you revisit the same coordinate again with the same wire
Trace the route for co-ordinates visited by wire B
   if the coordinates exist in the hash as being visited by wire A then this is a crossing point, the hash contains the minimum number of steps to get there by wire A
      so we can compute both the manhattan distance for this point (x,y) and the number of steps to get there by both wires (as we get the minimum value for A for the hash and the value from B from our iteration).
      check if either of these is lower than our current minimum values (or we haven't had a minimum value yet) and update minimum value(s) if necessary

After tracing route B we have a minimum value for both manhattan distance and number of steps that we can output.

Simple perl program to do the above takes 0.2s for my input:-

Code: [Select]

$ cat inp | time ./3b_speed.pl
Wire: A had 144449 steps
Wire: B had 140121 steps
D: 303
S: 11222
0.19user 0.00system 0:00.20elapsed 99%CPU (0avgtext+0avgdata 88160maxresident)k
0inputs+0outputs (0major+6556minor)pagefaults 0swaps

[EDIT]Using this strategy you can early bail on the minimum number of steps calculation when you've traced B out for more steps than your existing minimum, but you can't bail early on the minimum manhattan distance answer as that could be right at the end of the trace of wire B.

Title: Re: Advent of Code
Post by: Ben T on 04 December, 2019, 12:53:43 pm

Quote from: Greenbank on 04 December, 2019, 09:30:21 am

28 seconds?

Yeah... I probably could have optimized it like you have but I didn't need to and it would have took me longer than 28 seconds to do it :)

Day 5 looks good, probably a recursive algorithm but haven't tried it yet

Title: Re: Advent of Code
Post by: Greenbank on 04 December, 2019, 01:25:38 pm

Quote from: Ben T on 04 December, 2019, 12:53:43 pm

Day 5 looks good, probably a recursive algorithm but haven't tried it yet

You see the future!

(Won't post any spoilers until most people have had a go.)

Title: Re: Advent of Code
Post by: Ben T on 04 December, 2019, 04:54:11 pm

Quote from: Greenbank on 04 December, 2019, 01:25:38 pm

Quote from: Ben T on 04 December, 2019, 12:53:43 pm

Day 5 looks good, probably a recursive algorithm but haven't tried it yet

You see the future!

(Won't post any spoilers until most people have had a go.)

(click to show/hide)

Day 5 would have been more interesting (but more time consuming) if there had been 12 (or anything more than about 8 or 9) numbers in the password rather than 6.

I was thinking along the lines of:
function count(digits)
  return count(digits : digits.last()) + count(digits : digits.last() + 1) + ... + count(digits : 9)


then shortcutting in some way if optimization was necessary.

As it is the obvious way is to run a check on each possible number as there are only of the order of 10^6.

(click to show/hide)

Code: [Select]

using System;
using System.Linq;
using System.Text.RegularExpressions;

namespace Day04
{
    class Program
    {
        static int inputStart = 265275; //my inputs
        static int inputEnd = 781584;

        static void Main()
        {
            var candidates = Enumerable.Range(inputStart, inputEnd + 1 - inputStart).ToArray();
            var c = candidates.Where(i => Matches(i));
            Console.WriteLine(c.Count());
        }

        static bool Matches(int x)
        {
            var s = x.ToString();
            for (int i = 1; i < s.Length; i++)
                if (s[i] < s[i - 1]) return false;
            s = Regex.Replace(s, "1{3,}|2{3,}|3{3,}|4{3,}|5{3,}|6{3,}|7{3,}|8{3,}|9{3,}", "");
            return Regex.IsMatch(s, "11|22|33|44|55|66|77|88|99");
        }
    }
}



Title: Re: Advent of Code
Post by: freeflow on 04 December, 2019, 04:59:47 pm

For me day 5 is in 12 hours time.  Passwords with doubles was day 4.

Title: Re: Advent of Code
Post by: Greenbank on 04 December, 2019, 05:03:10 pm

That was my joke about being able to see the future!

(He can't, he's just got the day wrong.)

Title: Re: Advent of Code
Post by: Ben T on 04 December, 2019, 05:57:35 pm

Quote from: Greenbank on 04 December, 2019, 05:03:10 pm

That was my joke about being able to see the future!

(He can't, he's just got the day wrong.)

I mean to be pedantic it should really be day 3, with 1st Dec being day 0  :D

(The " largest piece of ui", the timer, is on day 5 when you're actually on day 4)

Title: Re: Advent of Code
Post by: Greenbank on 04 December, 2019, 11:07:42 pm

Only because someone suggested it could be done with grep:-

(click to show/hide)

Code: [Select]

$ seq 158126 624574 | grep "^0*1*2*3*4*5*6*7*8*9*$" | grep "\([0-9]\)\1" | wc -l
1665
Tried to think of a cunning way to do part b purely with grep. And failed.

Aha - perl re's give me ! negative lookaheads:-

Code: [Select]

$seq 158126 624574 | grep "^0*1*2*3*4*5*6*7*8*9*$" | grep "\([0-9]\)\1" | grep -P '^((\d)\2(?!\2)\d*|\d*(\d)(?!\3)(\d)\4(?!\4)\d*)$' |  wc -l
1131

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2019, 11:38:25 am

2019 Day 5:

As usual the biggest problems are not reading it clearly enough and trying to jump in to get it done. That and silly copypasta errors.

The snippets of test case code was nice, they certainly helped me track down my mistake.

Title: Re: Advent of Code
Post by: Ben T on 05 December, 2019, 12:03:01 pm

Main mistake with day 5, was thinking that python might be a good language. Whoever heard of having to re-declare a variable's globalness in every function it is used in, FFS.   :facepalm:

Title: Re: Advent of Code
Post by: freeflow on 05 December, 2019, 03:27:02 pm

I might observe that Day 5 instructions include some artful misdirection

(click to show/hide)

Otherwise it does nothing is not the same as nothing happens >:(

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2019, 03:47:45 pm

Quote from: freeflow on 05 December, 2019, 03:27:02 pm

I might observe that Day 5 instructions include some artful misdirection

(click to show/hide)

Otherwise it does nothing is not the same as nothing happens >:(

(click to show/hide)

Tripped up by this?

Quote

Normally, after an instruction is finished, the instruction pointer increases by the number of values in that instruction. However, if the instruction modifies the instruction pointer, that value is used and the instruction pointer is not automatically increased.

Title: Re: Advent of Code
Post by: freeflow on 05 December, 2019, 03:52:08 pm

No.  5 & 6

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2019, 04:36:14 pm

BTW, I'm expecting INPUT and OUTPUT to go the same way that https://adventofcode.com/2017/day/18 did and you'll end up needing two copies of the 'computer' running at the same time swapping inputs/outputs and vice versa.

Title: Re: Advent of Code
Post by: Ben T on 05 December, 2019, 05:21:50 pm

Quote from: freeflow on 05 December, 2019, 03:27:02 pm

I might observe that Day 5 instructions include some artful misdirection

(click to show/hide)

Otherwise it does nothing is not the same as nothing happens >:(

(click to show/hide)

yeah, I agree:

By "Opcode 5 is jump-if-true: if the first parameter is non-zero, it sets the instruction pointer to the value from the second parameter. Otherwise, it does nothing."

Does "the second parameter" still exist if the first is zero? i.e., am I to read two parameters, and possibly ignore one, or read one, and if it's non-zero, read another? It matters to the eventual value of the instruction pointer.

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2019, 06:18:37 pm

(Replying to spoiler above)

Well, it only works with one interpretation.

An eyeball analysis of the test program should show that interpreting the other way quickly leads to unknown opcodes.

Title: Re: Advent of Code
Post by: freeflow on 05 December, 2019, 06:44:16 pm

I don't know if it was sneaky but misintepreting 5 and 6 led to code than ran all 4 test programs and gave the correct answers, but crapped out on two of the conditions of the longer 5th test program.  Most confusing.

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2019, 06:59:49 pm

Quote from: freeflow on 05 December, 2019, 06:44:16 pm

I don't know if it was sneaky but misintepreting 5 and 6 led to code than ran all 4 test programs and gave the correct answers, but crapped out on two of the conditions of the longer 5th test program.  Most confusing.

Based on previous years I think he specifically designs things like that into the puzzles.

I remember one puzzle (can't remember exactly which one or which year) that my hastily thrown together perl program would pass all of the example/test inputs but failed on my personal puzzle input. Turned out that the main puzzle input was specifically crafted to trick languages like perl that have lazy typing as it interpreted some of the integer values as octal, so incrementing something like "007" would get you "010" not "008" leading to very hard to find bugs.

Title: Re: Advent of Code
Post by: Ben T on 05 December, 2019, 07:42:15 pm

Yeah. The instructions also said it prints "a series of diagnostic error codes which should all be zero" and then prints the answer.
Mine printed a number 3 first, then a load of zeros, then the answer. But the 3 didn't seem to indicate I had a bug, as the answer was still right.
Could the errant 3 be a hint to a future puzzle that complains of "one of the spaceships' systems not working properly", I wonder...

There seems to be several different ways he can make the puzzles non-trivial - the main ones I've seen so far are (1) making the spec fairly complicated so you have to read it thoroughly, (2) is by making the data such that the 'obvious' / brute-force solution would never complete quickly enough, and an optimization or dynamic programming is required, (3) is by introducing a reverse-engineering requirement, like when the 'machine code' is in fact doing a loop with all its jumps and you have to figure out what the loop's trying to do.
There is the other one you mention of trying to trick specific languages, integer overflows are an obvious one. I quite enjoy the challenge imposed by that to be honest.

I personally enjoy (2) most. I don't enjoy (1) quite so much, and I find (3) difficult.

I sometimes do wonder whether he will introduce another one of making puzzles refer to past ones, possibly even implicitly.

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2019, 07:52:50 pm

Quote from: Ben T on 05 December, 2019, 07:42:15 pm

Yeah. The instructions also said it prints "a series of diagnostic error codes which should all be zero" and then prints the answer.
Mine printed a number 3 first, then a load of zeros, then the answer. But the 3 didn't seem to indicate I had a bug, as the answer was still right.
Could the errant 3 be a hint to a future puzzle that complains of "one of the spaceships' systems not working properly", I wonder...

If you give me your input I can run it through mine and see what I get. Here's my input:-

Code: [Select]

3,225,1,225,6,6,1100,1,238,225,104,0,1002,92,42,224,1001,224,-3444,224,4,224,102,8,223,223,101,4,224,224,1,224,223,223,1102,24,81,225,1101,89,36,224,101,-125,224,224,4,224,102,8,223,223,101,5,224,224,1,224,223,223,2,118,191,224,101,-880,224,224,4,224,1002,223,8,223,1001,224,7,224,1,224,223,223,1102,68,94,225,1101,85,91,225,1102,91,82,225,1102,85,77,224,101,-6545,224,224,4,224,1002,223,8,223,101,7,224,224,1,223,224,223,1101,84,20,225,102,41,36,224,101,-3321,224,224,4,224,1002,223,8,223,101,7,224,224,1,223,224,223,1,188,88,224,101,-183,224,224,4,224,1002,223,8,223,1001,224,7,224,1,224,223,223,1001,84,43,224,1001,224,-137,224,4,224,102,8,223,223,101,4,224,224,1,224,223,223,1102,71,92,225,1101,44,50,225,1102,29,47,225,101,7,195,224,101,-36,224,224,4,224,102,8,223,223,101,6,224,224,1,223,224,223,4,223,99,0,0,0,677,0,0,0,0,0,0,0,0,0,0,0,1105,0,99999,1105,227,247,1105,1,99999,1005,227,99999,1005,0,256,1105,1,99999,1106,227,99999,1106,0,265,1105,1,99999,1006,0,99999,1006,227,274,1105,1,99999,1105,1,280,1105,1,99999,1,225,225,225,1101,294,0,0,105,1,0,1105,1,99999,1106,0,300,1105,1,99999,1,225,225,225,1101,314,0,0,106,0,0,1105,1,99999,107,677,677,224,1002,223,2,223,1006,224,329,1001,223,1,223,1108,226,677,224,102,2,223,223,1006,224,344,101,1,223,223,1107,226,226,224,1002,223,2,223,1006,224,359,101,1,223,223,8,677,226,224,1002,223,2,223,1006,224,374,1001,223,1,223,1107,677,226,224,102,2,223,223,1005,224,389,1001,223,1,223,1008,677,677,224,1002,223,2,223,1006,224,404,1001,223,1,223,108,677,677,224,102,2,223,223,1005,224,419,1001,223,1,223,1107,226,677,224,102,2,223,223,1006,224,434,101,1,223,223,1008,226,226,224,1002,223,2,223,1006,224,449,1001,223,1,223,107,226,226,224,102,2,223,223,1006,224,464,1001,223,1,223,1007,677,226,224,1002,223,2,223,1006,224,479,1001,223,1,223,1108,226,226,224,102,2,223,223,1006,224,494,1001,223,1,223,8,226,226,224,1002,223,2,223,1005,224,509,1001,223,1,223,7,226,677,224,102,2,223,223,1005,224,524,101,1,223,223,1008,677,226,224,102,2,223,223,1005,224,539,101,1,223,223,107,226,677,224,1002,223,2,223,1006,224,554,1001,223,1,223,1108,677,226,224,102,2,223,223,1005,224,569,101,1,223,223,108,226,226,224,1002,223,2,223,1005,224,584,1001,223,1,223,7,677,226,224,1002,223,2,223,1005,224,599,1001,223,1,223,108,226,677,224,1002,223,2,223,1006,224,614,101,1,223,223,1007,677,677,224,1002,223,2,223,1006,224,629,101,1,223,223,7,677,677,224,102,2,223,223,1005,224,644,101,1,223,223,1007,226,226,224,1002,223,2,223,1006,224,659,1001,223,1,223,8,226,677,224,102,2,223,223,1005,224,674,1001,223,1,223,4,223,99,226

This (with an input of 1) gives 9 zeroes and then my answer of 9961446. With an input of 5 it gives 742621.

Quote from: Ben T on 05 December, 2019, 07:42:15 pm

There seems to be several different ways he can make the puzzles non-trivial - the main ones I've seen so far are (1) making the spec fairly complicated so you have to read it thoroughly, (2) is by making the data such that the 'obvious' / brute-force solution would never complete quickly enough, and an optimization or dynamic programming is required, (3) is by introducing a reverse-engineering requirement, like when the 'machine code' is in fact doing a loop with all its jumps and you have to figure out what the loop's trying to do.
There is the other one you mention of trying to trick specific languages, integer overflows are an obvious one. I quite enjoy the challenge imposed by that to be honest.

I personally enjoy (2) most. I don't enjoy (1) quite so much, and I find (3) difficult.

Roughly similar here. Finding the most appropriate algorithm is always nice. #3 always reminds me of days of old where I did more reverse engineering, it was never really that much "fun".

Title: Re: Advent of Code
Post by: Ben T on 05 December, 2019, 08:09:24 pm

Quote from: Greenbank on 05 December, 2019, 07:52:50 pm

Quote from: Ben T on 05 December, 2019, 07:42:15 pm

Yeah. The instructions also said it prints "a series of diagnostic error codes which should all be zero" and then prints the answer.
Mine printed a number 3 first, then a load of zeros, then the answer. But the 3 didn't seem to indicate I had a bug, as the answer was still right.
Could the errant 3 be a hint to a future puzzle that complains of "one of the spaceships' systems not working properly", I wonder...

If you give me your input I can run it through mine and see what I get. Here's my input:-

Code: [Select]

3,225,1,225,6,6,1100,1,238,225,104,0,1002,92,42,224,1001,224,-3444,224,4,224,102,8,223,223,101,4,224,224,1,224,223,223,1102,24,81,225,1101,89,36,224,101,-125,224,224,4,224,102,8,223,223,101,5,224,224,1,224,223,223,2,118,191,224,101,-880,224,224,4,224,1002,223,8,223,1001,224,7,224,1,224,223,223,1102,68,94,225,1101,85,91,225,1102,91,82,225,1102,85,77,224,101,-6545,224,224,4,224,1002,223,8,223,101,7,224,224,1,223,224,223,1101,84,20,225,102,41,36,224,101,-3321,224,224,4,224,1002,223,8,223,101,7,224,224,1,223,224,223,1,188,88,224,101,-183,224,224,4,224,1002,223,8,223,1001,224,7,224,1,224,223,223,1001,84,43,224,1001,224,-137,224,4,224,102,8,223,223,101,4,224,224,1,224,223,223,1102,71,92,225,1101,44,50,225,1102,29,47,225,101,7,195,224,101,-36,224,224,4,224,102,8,223,223,101,6,224,224,1,223,224,223,4,223,99,0,0,0,677,0,0,0,0,0,0,0,0,0,0,0,1105,0,99999,1105,227,247,1105,1,99999,1005,227,99999,1005,0,256,1105,1,99999,1106,227,99999,1106,0,265,1105,1,99999,1006,0,99999,1006,227,274,1105,1,99999,1105,1,280,1105,1,99999,1,225,225,225,1101,294,0,0,105,1,0,1105,1,99999,1106,0,300,1105,1,99999,1,225,225,225,1101,314,0,0,106,0,0,1105,1,99999,107,677,677,224,1002,223,2,223,1006,224,329,1001,223,1,223,1108,226,677,224,102,2,223,223,1006,224,344,101,1,223,223,1107,226,226,224,1002,223,2,223,1006,224,359,101,1,223,223,8,677,226,224,1002,223,2,223,1006,224,374,1001,223,1,223,1107,677,226,224,102,2,223,223,1005,224,389,1001,223,1,223,1008,677,677,224,1002,223,2,223,1006,224,404,1001,223,1,223,108,677,677,224,102,2,223,223,1005,224,419,1001,223,1,223,1107,226,677,224,102,2,223,223,1006,224,434,101,1,223,223,1008,226,226,224,1002,223,2,223,1006,224,449,1001,223,1,223,107,226,226,224,102,2,223,223,1006,224,464,1001,223,1,223,1007,677,226,224,1002,223,2,223,1006,224,479,1001,223,1,223,1108,226,226,224,102,2,223,223,1006,224,494,1001,223,1,223,8,226,226,224,1002,223,2,223,1005,224,509,1001,223,1,223,7,226,677,224,102,2,223,223,1005,224,524,101,1,223,223,1008,677,226,224,102,2,223,223,1005,224,539,101,1,223,223,107,226,677,224,1002,223,2,223,1006,224,554,1001,223,1,223,1108,677,226,224,102,2,223,223,1005,224,569,101,1,223,223,108,226,226,224,1002,223,2,223,1005,224,584,1001,223,1,223,7,677,226,224,1002,223,2,223,1005,224,599,1001,223,1,223,108,226,677,224,1002,223,2,223,1006,224,614,101,1,223,223,1007,677,677,224,1002,223,2,223,1006,224,629,101,1,223,223,7,677,677,224,102,2,223,223,1005,224,644,101,1,223,223,1007,226,226,224,1002,223,2,223,1006,224,659,1001,223,1,223,8,226,677,224,102,2,223,223,1005,224,674,1001,223,1,223,4,223,99,226

This (with an input of 1) gives 9 zeroes and then my answer of 9961446. With an input of 5 it gives 742621.

Hmm, cheers - ok just tried it again and it's not printing the phantom '3' now. Must have just been a debugging line I left in...cheers anyway

Title: Re: Advent of Code
Post by: Greenbank on 06 December, 2019, 09:30:17 am

Yet more "READ IT PROPERLY" fun today.

(click to show/hide)

"Between the objects they are orbiting - not between YOU and SAN."

Cost me 10 minutes trying to work out what was wrong with my program...

Title: Re: Advent of Code
Post by: freeflow on 06 December, 2019, 04:41:41 pm

Yup -2 and understanding the input data in part 2 finally got me there.

Title: Re: Advent of Code
Post by: Croft on 07 December, 2019, 10:29:05 am

Da7 7:

Quote from: Greenbank on 04 December, 2019, 01:25:38 pm

You see the future!

Quote from: Greenbank on 05 December, 2019, 04:36:14 pm

BTW, I'm expecting INPUT and OUTPUT to go the same way that https://adventofcode.com/2017/day/18 did and you'll end up needing two copies of the 'computer' running at the same time swapping inputs/outputs and vice versa.

You see the future (almost)!

Title: Re: Advent of Code
Post by: Greenbank on 07 December, 2019, 11:33:30 am

Indeed, but it was a nice twist on that.

My code to implement it was hideous.

(click to show/hide)

In the end I had one perl script to implement a single intcode computer which took its program and inputs from stdin, and shoved the output to stdout

Above that I had a program that would be given the phase settings and manage starting 5 intcode computer scripts, push the inputs in to each as and when required, read the outputs and pass them to the next computer, etc, watching for any one of them to exit with opcode 99 and keeping track of the last output

Above that I had a simple program to iterate through all of the possible phase settings and found the result with grep, awk and sort -n

Far from efficient but it got the job done, and I'm so glad I didn't have to do any deep debugging as that really wouldn't have been fun.

Title: Re: Advent of Code
Post by: Pickled Onion on 07 December, 2019, 07:15:24 pm

Interesting.

(click to show/hide)

My intcode computers had a queue for input and output, it was straightforward to make sure they didn't forget their state after giving up an output. The test suite from day 5 made refactoring safe.

Then I got hung up on the meaning of "repeatedly take input and produce output many times before halting". Was "halting" when they hit 99 or when they failed to amplify? Could they get stuck in an infinite loop? Does "repeatedly take input" mean they could use the same input more than once? I didn't anticipate them getting stuck waiting for an input that wasn't there (or crashing on account of an empty queueue).

In the end it was quick - no deeply nested loops like last year's one, or an unfeasibly large search space.

Title: Re: Advent of Code
Post by: freeflow on 08 December, 2019, 05:49:59 am

Bum. I am stymied on Day 7 Part 2. All current and historical tests for my computer give the correct results. Day 7 Part1 was correct at the first attempt. Part 2 tests pass. But part2  input doesn't give the correct answer. Pointers to wrinkles I may have missed are most welcome.

(click to show/hide)

This is my program code


3,8,1001,8,10,8,105,1,0,0,21,42,63,76,101,114,195,276,357,438,99999,3,9,101,2,9,9,102,5,9,9,1001,9,3,9,1002,9,5,9,4,9,99,3,9,101,4,9,9,102,5,9,9,1001,9,5,9,102,2,9,9,4,9,99,3,9,1001,9,3,9,1002,9,5,9,4,9,99,3,9,1002,9,2,9,101,5,9,9,102,3,9,9,101,2,9,9,1002,9,3,9,4,9,99,3,9,101,3,9,9,102,2,9,9,4,9,99,3,9,1001,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,101,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,101,1,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,1,9,4,9,99,3,9,102,2,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,102,2,9,9,4,9,99,3,9,102,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,1001,9,2,9,4,9,3,9,1002,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,1002,9,2,9,4,9,3,9,1002,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,1001,9,2,9,4,9,99,3,9,1001,9,1,9,4,9,3,9,101,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,102,2,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,1001,9,2,9,4,9,99,3,9,102,2,9,9,4,9,3,9,101,1,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,1002,9,2,9,4,9,3,9,1002,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,101,2,9,9,4,9,99
and the result I get is 291425470
If you get a different answer could you please say so BUT NOT WHAT YOUR ANSWER IS.  Thanks

Title: Re: Advent of Code
Post by: Pickled Onion on 08 December, 2019, 07:31:23 am

I get a smaller number.

Do your tests include a full run of all permutations on the last example, or just the permutation shown?

Title: Re: Advent of Code
Post by: freeflow on 08 December, 2019, 07:49:15 am

That is the maximum value I get when I run all 120 permutations of "567892".  Advent of Code says my result is too low.

Title: Re: Advent of Code
Post by: freeflow on 08 December, 2019, 10:14:31 am

Whizzed through day 8 :-D

Title: Re: Advent of Code
Post by: Greenbank on 08 December, 2019, 05:20:23 pm

Quote from: freeflow on 08 December, 2019, 05:49:59 am

If you get a different answer could you please say so BUT NOT WHAT YOUR ANSWER IS.  Thanks

I too get a different (lower) answer. If it's any help here's my input and what I get as an answer (as that isn't giving you the answer to your problem).

Code: [Select]

3,8,1001,8,10,8,105,1,0,0,21,46,55,68,89,110,191,272,353,434,99999,3,9,1002,9,3,9,1001,9,3,9,102,4,9,9,101,4,9,9,1002,9,5,9,4,9,99,3,9,102,3,9,9,4,9,99,3,9,1001,9,5,9,102,4,9,9,4,9,99,3,9,1001,9,5,9,1002,9,2,9,1001,9,5,9,1002,9,3,9,4,9,99,3,9,101,3,9,9,102,3,9,9,101,3,9,9,1002,9,4,9,4,9,99,3,9,1001,9,1,9,4,9,3,9,1001,9,1,9,4,9,3,9,102,2,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,2,9,4,9,3,9,1002,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,1001,9,2,9,4,9,99,3,9,102,2,9,9,4,9,3,9,101,2,9,9,4,9,3,9,101,2,9,9,4,9,3,9,1001,9,1,9,4,9,3,9,102,2,9,9,4,9,3,9,101,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,101,1,9,9,4,9,3,9,101,2,9,9,4,9,3,9,101,2,9,9,4,9,99,3,9,101,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,101,1,9,9,4,9,3,9,101,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,1001,9,1,9,4,9,3,9,101,2,9,9,4,9,99,3,9,102,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,101,1,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,1001,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,101,2,9,9,4,9,3,9,1001,9,1,9,4,9,99,3,9,1002,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,1001,9,1,9,4,9,3,9,101,1,9,9,4,9,3,9,101,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,102,2,9,9,4,9,99


Code: [Select]

$ ./7d.pl | sort -rn -k3 | head
57968 gives 3745599
57698 gives 3742019
75968 gives 3689151
75698 gives 3685571
57986 gives 3671647

And here are the values passed between each amplifier for phase arrangement 57968:-

(click to show/hide)

Code: [Select]

57968: Sending 0 to 0
57968: Sending 1 to 1
57968: Sending 3 to 2
57968: Sending 6 to 3
57968: Sending 12 to 4
57968: Sending 24 to 0
57968: Sending 25 to 1
57968: Sending 50 to 2
57968: Sending 52 to 3
57968: Sending 54 to 4
57968: Sending 108 to 0
57968: Sending 216 to 1
57968: Sending 217 to 2
57968: Sending 218 to 3
57968: Sending 220 to 4
57968: Sending 221 to 0
57968: Sending 223 to 1
57968: Sending 225 to 2
57968: Sending 226 to 3
57968: Sending 227 to 4
57968: Sending 454 to 0
57968: Sending 456 to 1
57968: Sending 912 to 2
57968: Sending 914 to 3
57968: Sending 1828 to 4
57968: Sending 3656 to 0
57968: Sending 7312 to 1
57968: Sending 7314 to 2
57968: Sending 14628 to 3
57968: Sending 14630 to 4
57968: Sending 29260 to 0
57968: Sending 29262 to 1
57968: Sending 58524 to 2
57968: Sending 117048 to 3
57968: Sending 234096 to 4
57968: Sending 234098 to 0
57968: Sending 468196 to 1
57968: Sending 936392 to 2
57968: Sending 1872784 to 3
57968: Sending 1872785 to 4
57968: Sending 1872787 to 0
57968: Sending 1872788 to 1
57968: Sending 1872789 to 2
57968: Sending 1872790 to 3
57968: Sending 1872792 to 4
57968: Sending 1872794 to 0
57968: Sending 1872796 to 1
57968: Sending 1872798 to 2
57968: Sending 3745596 to 3
57968: Sending 3745598 to 4
57968: Sending 3745599 to 0
57968 gives 3745599


Again, this is the answer to my input for day 7 not yours!

Title: Re: Advent of Code
Post by: Greenbank on 08 December, 2019, 05:21:51 pm

Day 8 nice and quick although there was a ~7 hour gap between part 1 and part 2 as I didn't get time to finish part 2 before I had to go out and was out most of the day.

Title: Re: Advent of Code
Post by: freeflow on 08 December, 2019, 06:45:04 pm

Thanks.  I get a different number to you so it seems I have a logic problem in by computer.  I also downloaded a solution in python which gave a different number to my computer.  So a bit of head scratching is the order of the day.

Title: Re: Advent of Code
Post by: freeflow on 09 December, 2019, 08:29:51 am

Day 9 completed successfully, but my computer is still giving the wrong result for Day7Part2

Title: Re: Advent of Code
Post by: Greenbank on 09 December, 2019, 09:05:31 am

Opposite problem for me, and it wasn't fixed in the 15 minutes I have this morning so I'll have to pick it up later this afternoon when I've done all of my chores.

[EDIT] Spotted it, fixed and day 9 part 2 ran without problems!

Title: Re: Advent of Code
Post by: freeflow on 09 December, 2019, 10:19:55 am

I'm working in VBA so much of today's problem solving time was spent ensuring appropriate variables were LongLong rather than Long. :demon:

Title: Re: Advent of Code
Post by: Ben T on 09 December, 2019, 12:43:09 pm

foxed by day 8 part 2  :-\

(click to show/hide)

 I assume it is an ASCII-art type question?

mine produces:



    X  X    X           X
      XXX         XX
     X             X
 X         XX X  X    X
 X X    X   X X   X   X
  X X   X       XX      X



(with X as "black" and space for white.)

 :-\ :-\

Title: Re: Advent of Code
Post by: Ben T on 09 December, 2019, 01:02:42 pm

Quote from: freeflow on 08 December, 2019, 05:49:59 am

Bum. I am stymied on Day 7 Part 2. All current and historical tests for my computer give the correct results. Day 7 Part1 was correct at the first attempt. Part 2 tests pass. But part2  input doesn't give the correct answer. Pointers to wrinkles I may have missed are most welcome.

(click to show/hide)

This is my program code


3,8,1001,8,10,8,105,1,0,0,21,42,63,76,101,114,195,276,357,438,99999,3,9,101,2,9,9,102,5,9,9,1001,9,3,9,1002,9,5,9,4,9,99,3,9,101,4,9,9,102,5,9,9,1001,9,5,9,102,2,9,9,4,9,99,3,9,1001,9,3,9,1002,9,5,9,4,9,99,3,9,1002,9,2,9,101,5,9,9,102,3,9,9,101,2,9,9,1002,9,3,9,4,9,99,3,9,101,3,9,9,102,2,9,9,4,9,99,3,9,1001,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,101,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,101,1,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,1,9,4,9,99,3,9,102,2,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,102,2,9,9,4,9,99,3,9,102,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,1001,9,2,9,4,9,3,9,1002,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,1002,9,2,9,4,9,3,9,1002,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,1001,9,2,9,4,9,99,3,9,1001,9,1,9,4,9,3,9,101,2,9,9,4,9,3,9,102,2,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,1,9,4,9,3,9,102,2,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,1001,9,2,9,4,9,3,9,102,2,9,9,4,9,3,9,1001,9,2,9,4,9,99,3,9,102,2,9,9,4,9,3,9,101,1,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,1002,9,2,9,4,9,3,9,1002,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,1001,9,2,9,4,9,3,9,101,2,9,9,4,9,3,9,1002,9,2,9,4,9,3,9,101,2,9,9,4,9,99
and the result I get is 291425470
If you get a different answer could you please say so BUT NOT WHAT YOUR ANSWER IS.  Thanks

(click to show/hide)

My program gives a smaller answer than 291425470 for your input.
The largest final output is an 8 digit number.
If you want to know which combination gives the largest final output for your input, but not what the final output is:

(click to show/hide)

8,5,6,9,7

Tip: add some exception handling maybe so that it highlights an unexpected situation, rather than just falling through to a 'default'  (which may be wrong)

Title: Re: Advent of Code
Post by: Greenbank on 09 December, 2019, 01:13:37 pm

Quote from: Ben T on 09 December, 2019, 12:43:09 pm

foxed by day 8 part 2  :-\

(click to show/hide)

 I assume it is an ASCII-art type question?

mine produces:

(click to show/hide)

Yes, ASCII art but it should produce 5 capital letters. For my input I get:-

Code: [Select]

$ cat inp | ./8b.pl  | tr 01 " *"
*  *  **  *  * ****  **
* *  *  * *  *    * *  *
**   *  * *  *   *  *  *
* *  **** *  *  *   ****
* *  *  * *  * *    *  *
*  * *  *  **  **** *  *

Which gives: KAUZA

Are you processing the layers in the right order?

Title: Re: Advent of Code
Post by: Ben T on 09 December, 2019, 04:37:39 pm

Quote from: Greenbank on 09 December, 2019, 01:13:37 pm

Quote from: Ben T on 09 December, 2019, 12:43:09 pm

foxed by day 8 part 2  :-\

(click to show/hide)

 I assume it is an ASCII-art type question?

mine produces:

(click to show/hide)

Yes, ASCII art but it should produce 5 capital letters. For my input I get:-

Code: [Select]

$ cat inp | ./8b.pl  | tr 01 " *"
*  *  **  *  * ****  **
* *  *  * *  *    * *  *
**   *  * *  *   *  *  *
* *  **** *  *  *   ****
* *  *  * *  * *    *  *
*  * *  *  **  **** *  *

Which gives: KAUZA

Are you processing the layers in the right order?

(click to show/hide)

Hmm, got it now - I realised what I've done wrong - wondered why it wasn't an exact multiple of 25x6... I got my program to read from stdin and copy & pasted it.
For some reason probably best only known to windows, the copy paste operation only transmitted the first 4,094 characters. When saved as a file and read back there were 15,000, which obviously is a multiple of 25x6.

Title: Re: Advent of Code
Post by: freeflow on 09 December, 2019, 06:18:26 pm

Finally got the correct answer for Day 7 part 2.  The logic in the computer was perfectly fine but obviously that was where I was spending my time.  The error was in how I collected the output when the computer was run in loop mode.  A very silly logic error but depressingly elusive.

Title: Re: Advent of Code
Post by: Pickled Onion on 09 December, 2019, 09:44:45 pm

Day 9: very clever. In "test mode" with input=1 it output 2 opcodes which pointed straight at the places where I had left the original day 5 code for finding the offset.

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2019, 08:34:06 am

I've got into a bad habit of checking the leaderboards of the top 100 to see how tricky the upcoming day is, the times shown there give me an idea how tough it's going to be.

I fear for the days where the top 100 hasn't been solved by the time I get everything else done (school run this morning) before I can look at it, hasn't happened yet.

Not that bad today but part 2 is obviously relatively involved.

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2019, 09:41:23 am

That was fun.

(click to show/hide)

Things used:-

naive gcd algorithm
arctan for polar co-ordinates

Title: Re: Advent of Code
Post by: Ben T on 10 December, 2019, 10:54:20 am

Day 9 a bit bloody tenuous to say the least... had to look on the reddit and instantly found a reference to "the 203 error" which was what I had run into, despite passing all the tests. But quite clever how it actually tells you which instruction there is a problem with. I thought by mention of "large numbers" but no indication as to how large, he might make the tests handle >32bit, but <64 bit numbers but deliberately require >64 bit numbers in the final solution, I was braced for that... but seemingly not for slight misinterpretation of how read/write parameters are handled.
Don't think I've got time to do day 10 today, spent long enough not doing actual work as it is :)

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2019, 02:06:19 pm

BTW, Eric's talk about AoC is well worth a watch: https://www.youtube.com/watch?v=gibVyxpi-qA

Will be late to Day 11 thanks to school running club and then an eye test.

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2019, 12:28:22 pm

Day 11. Found a bug in opcode 3 of all places. Left wondering how it ever worked. Done though, will go through and rejig things properly as this Intcode computer is not going anywhere.

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2019, 09:46:46 pm

What haven't we had yet?

* Reverse engineering? (Almost certainly we'll be presented with an Intcode computer that even with the most optimal implementation will still take far too long to run in normal time, so we'll have to work out what it is doing and then optimise that)

* SAT solver

* An A* type solver (heavy on the backtracking)

* Something geometric (especially if it's 3D)

What else?

Title: Re: Advent of Code
Post by: Greenbank on 12 December, 2019, 08:27:17 am

Well Day 12 part 2 seems fun. Haven't worked out what the trick is yet.

[EDIT] Worked out what the trick is!

Rejigged it a bit:-

Code: [Select]

$ cat inp | time ./12d.pl
A: *elided*
B: *elided to avoid spoilers*
0.78user 0.00system 0:00.78elapsed 100%CPU (0avgtext+0avgdata 9472maxresident)k
0inputs+0outputs (0major+631minor)pagefaults 0swaps

Might rewrite it in C to see how fast I can make it go...

Code: [Select]

$ cat inp | time ./12d
A: *elided*
B: *elided to avoid spoilers*
0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 2176maxresident)k
0inputs+0outputs (0major+170minor)pagefaults 0swaps

Ping!

Finer grained timings:-

Code: [Select]

$ cat inp | ./12d 1000
*output elided to avoid spoilers*
init = 126 usec total
a = 218 usec total
calc = 8628 usec total
b = 8644 usec total

So initialisation (parsing the file) is taking 126 usec.
Calculating part a and outputting the answer is taking 92 usec.
Part b takes 8426 usec with the bulk of that in an initial computation and 16 usec in a secondary computation.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2019, 10:18:45 am

Day 13 is awesome.

Title: Re: Advent of Code
Post by: Greenbank on 14 December, 2019, 05:07:02 am

GN: I'm up as the puzzle opens.

BN: I'm absolutely shitfaced.

GN: I'll have a look at the puzzle anyway, you never know...

BN: There are lots of words and symbols and things that I really can't comprehend right now

GN/BN: Dqvnk

P.S. Day 13 was awesome

Title: Re: Advent of Code
Post by: Greenbank on 14 December, 2019, 02:32:21 pm

Glad it was a gentle one today (day 14). Not sure my hungover brain would have coped with anything trickier.

Title: Re: Advent of Code
Post by: Ben T on 15 December, 2019, 08:56:56 pm

Just catching up, yes like day 13...was almost lamenting use of a console app but then found there is a SetCursorPosition function which prevents having to redraw and can animate it in a non-flickery way :)

Title: Re: Advent of Code
Post by: Greenbank on 16 December, 2019, 01:06:06 am

Late to it today as I'd been out all day at a family party. Chased a few silly bugs in a dreadful implementation but got it done.

The way I'd implemented meant it was only a very small change required to do part 2.

Loving the use of IntCode computers to provide inputs (i.e. the maze) that can't be analysed directly.

(click to show/hide)

2445 moves to discover the entire map, CPU time was 2.783s including the IntCode computer process time

Title: Re: Advent of Code
Post by: Greenbank on 16 December, 2019, 04:18:04 pm

Day 16.

Easy!

What? Eh? What?! Ah.

Title: Re: Advent of Code
Post by: Greenbank on 16 December, 2019, 06:47:22 pm

(click to show/hide)

Started off with a Breadth-First-Search (BFS algorithm) but memories of previous challenges made me think that I might end up needing more than that, so I chose a slightly more optimal algorithm, mostly:-
a) If there's an adjacent unexplored square to the current location, attempt to explore it
b) If all 4 adjacent squares are known then find the nearest unexplored square and move towards it (*)
...repeat until there are no unexplored squares...

* The "move towards bit" is the interesting one. I measured the distances to the unexplored squares by doing a BFS from the current square keeping track of the previous square on each step, i.e. the previous square for say (0,1) was (0,0). That meant that when I found the lowest square I could trace back the minimum moves required to get there so I knew which one to make the robot take next.

Once the entire maze was mapped out the answers were simple to calculate:-
part 1) Run the BFS starting from the co-ordinates of the oxygen tank and the answer was the minimum-distance it would take to travel back to the origin (0,0)
part 2) Using the same BFS results (starting from the co-ordinates of the oxygen tank) the answer was the maximum minimum-distance found in the search

Title: Re: Advent of Code
Post by: freeflow on 16 December, 2019, 07:32:25 pm

Finally completed day 10 part 2.  I got stuck for a long time because I was getting the correct answer for the test case but the list of test cases only matched my output in a few places.  Importantly the 200th answer in the test case was correct and when I chanced my actual input it actually delivered the correct response.

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2019, 11:16:22 am

Quote from: freeflow on 16 December, 2019, 07:32:25 pm

Finally completed day 10 part 2.  I got stuck for a long time because I was getting the correct answer for the test case but the list of test cases only matched my output in a few places.  Importantly the 200th answer in the test case was correct and when I chanced my actual input it actually delivered the correct response.

(click to show/hide)

Not sure how you implemented it but a likely cause if you converted things to polar co-ordinates is that one of the computed co-ordinates for an item that is directly up or down will be slightly off, meaning it is processed out of order.

Taking the test case and removing my hard coding to fix this:-

I use atan2() to convert to polar in radians, converting to degrees, adding 90 degrees and normalising to range of [0,360) :-

0,-1 -> -1.5707963267949 -> 359.99999989716

This means the items directly vertically "above" the starting point are processed last in the rotation rather than first as it should be 0 degrees.

This was fixed by:-

Code: [Select]

return( 0 ) if( $x == 0 && $y < 0 );

The first 20 asteroids that get [sic] vaporized in the big test example by my program (which might be equally incorrect!) are:-

Code: [Select]

Trying: 0,-1 (0) - The 1 asteroid to be vaporized is at 11,12
Trying: 1,-12 (4.76364159332945) - The 2 asteroid to be vaporized is at 12,1
Trying: 1,-11 (5.19442881083029) - The 3 asteroid to be vaporized is at 12,2
Trying: 1,-9 (6.34019165031464) - The 4 asteroid to be vaporized is at 12,4
Trying: 1,-8 (7.12501625420333) - The 5 asteroid to be vaporized is at 12,5
Trying: 1,-7 (8.13010226060595) - The 6 asteroid to be vaporized is at 12,6
Trying: 2,-13 (8.74616216970912) - The 7 asteroid to be vaporized is at 13,0
Trying: 1,-6 (9.46232211599789) - The 8 asteroid to be vaporized is at 12,7
Trying: 2,-11 (10.304846377701) - The 9 asteroid to be vaporized is at 13,2
Trying: 1,-5 (11.3099323841037) - The 10 asteroid to be vaporized is at 12,8
Trying: 3,-13 (12.994616703925) - The 11 asteroid to be vaporized is at 14,0
Trying: 1,-4 (14.0362433811252) - The 12 asteroid to be vaporized is at 13,5
Trying: 3,-11 (15.2551186176493) - The 13 asteroid to be vaporized is at 14,2
Trying: 2,-7 (15.9453958163031) - The 14 asteroid to be vaporized is at 13,6
Trying: 3,-10 (16.6992441502352) - The 15 asteroid to be vaporized is at 14,3
Trying: 4,-13 (17.1027288857551) - The 16 asteroid to be vaporized is at 15,0
Trying: 1,-3 (18.434948741147) - The 17 asteroid to be vaporized is at 14,4
Trying: 4,-11 (19.983106441894) - The 18 asteroid to be vaporized is at 15,2
Trying: 3,-8 (20.5560451402322) - The 19 asteroid to be vaporized is at 14,5
Trying: 5,-13 (21.0375109466207) - The 20 asteroid to be vaporized is at 16,0

and 191-200 are:-

Code: [Select]

Trying: -4,-9 (336.037510895201) - The 191 asteroid to be vaporized is at 7,4
Trying: -3,-7 (336.801409357004) - The 192 asteroid to be vaporized is at 8,6
Trying: -5,-12 (337.380134923273) - The 193 asteroid to be vaporized is at 6,1
Trying: -2,-5 (338.198590385896) - The 194 asteroid to be vaporized is at 9,8
Trying: -4,-11 (340.016893352426) - The 195 asteroid to be vaporized is at 7,2
Trying: -1,-3 (341.565051053173) - The 196 asteroid to be vaporized is at 10,10
Trying: -4,-13 (342.897270908565) - The 197 asteroid to be vaporized is at 7,0
Trying: -3,-10 (343.300755644085) - The 198 asteroid to be vaporized is at 8,3
Trying: -2,-7 (344.054603978017) - The 199 asteroid to be vaporized is at 9,6
Trying: -3,-11 (344.744881176671) - The 200 asteroid to be vaporized is at 8,2
ANSWER = 802


Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2019, 11:24:32 am

...Catching up from yesterday (did it yesterday but didn't have time to post about it)...

(click to show/hide)

Got the answer but in a half arsed way that wouldn't work for all possible inputs, also takes a bit longer than it should really (~16 seconds or so).

Will go back and redo the algorithm properly. I'm 99% sure I know how to write the far more optimal version that would handle all possible inputs.

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2019, 11:24:40 am

Day 17. Another example of READ THE TEXT, then READ IT AGAIN.

I spent 15 minutes banging my head against random things before realising I was doing something stupid.

(click to show/hide)

Could have been so much trickier.

The "obvious" route, of going straight across each intersection, might have led to a final set of instructions that could not be compressed to fit the input instruction rules.

Having to then go back and make the first part of part 2 output every possible permutation until one that could be compressed adequately would have been less fun.

Or, even more tricky, a new instruction that means R8 could become R1 S7 (with S being straight-on) or R2,S6 or R3,S5 or R3,S3,S2 or R3,S1,S2,S2, etc.

(I hope this doesn't appear as a later challenge.)

At least I automated the compression part rather than doing it manually (which was tempting just to get an answer in quickly).

Title: Re: Advent of Code
Post by: freeflow on 17 December, 2019, 08:53:45 pm

I have test cases for asteroids lying on the X and Y axes so that I don't run into that problem.

Title: Re: Advent of Code
Post by: Greenbank on 18 December, 2019, 02:18:28 pm

(click to show/hide)

Keeping track of states and minimum distance to reach that state is all well and good, but you've got to remember to check said store if you want to stop wasting time checking inefficient paths.

Fixed that and it returned the desired result(s) in 42.2s and 79.5s, so far from optimal.

Again it could have been so much trickier if there had been multiple paths (with different door combinations) between certain keys.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2019, 09:45:30 am

(click to show/hide)

Nice to have something (relatively) simple to give me some time to do some real work!

Spent a bit too long chasing a stupid bug in my initial code for part 2 and decided to rewrite it with a much simpler algorithm that worked way faster and also worked first time.

Added an option to my IntCode computer to have it reset to original state when it gets opcode 99 so I didn't need to keep starting new processes (it runs as a separate script and does stuff with stdin/stdout). In the end I only check 3585 different positions.

I should probably rewrite the IntCode computer in C to make it much faster. Never know what is coming around the corner...

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2019, 11:57:36 am

Quote from: Greenbank on 11 December, 2019, 09:46:46 pm

What haven't we had yet?

* Reverse engineering? (Almost certainly we'll be presented with an Intcode computer that even with the most optimal implementation will still take far too long to run in normal time, so we'll have to work out what it is doing and then optimise that)

This is still looming.

I was also thinking, on my commute in, about various IntCode related trickiness that could be thrown in:-
* Storing things at huge memory increments, i.e. storing at address 10,000,000, then 20,000,000 and so on up to some large number. Anyone who uses an array (or auto-expanding array) for memory will be slowly stuffed.
* Storing things at really huge memory locations, i.e. 9,000,000,000,000,000,000 (i.e. just below 2^63) - again, anyone using a basic array for memory is toast
* Playing on the edge of 32-bit or 64-bit numbers, e.g. something that creates numbers greater than 2^31 but less than 2^32 so that anything that uses signed 32-bit integers blows up. Likewise for signed 64-bit integers. Some intermediate result is 2^63 < x < 2^64 which will cause almost impossible to spot bugs as the result may still look plausible

My mitigations so far are:-
* I use a hash for my memory so it doesn't matter how big the numbers get, although it's slightly slower than using an array
* I use perl so I get automatic use of signed 64-bit integers although you need to be careful how you print out really large numbers as the defaults flick to E notation at ~19 digits

Future mitigations are:-
* Rewrite in C to be faster although that makes storing sparse memory locations in a hash a bit more work
* Still relatively slow due to the interprocess-communication so I should really have a perl version that can instantiate and run multiple IntCode computers in the same process
* Store low memory (0-1,000,000) in an array for speed and anything else in a hash
* Attempt to spot over/under-flow in calculations and exit if spotted
* Option to use 32-bit signed ints (for speed), 64-bit signed ints (where necessary), and libgmp for arbitrary length integers (assuming this becomes a problem later on)

(I don't like the idea of using libgmp or another library, I've done all of the problems so far without using any extra libraries/modules bar IPC::Open2 to be able to talk to my IntCode computer run as a separate process.)

Title: Re: Advent of Code
Post by: Greenbank on 20 December, 2019, 01:26:57 pm

(click to show/hide)

Had to do a minor bit of rejigging as I'd assumed that portal letter ordering didn't matter (i.e. AB was the same as BA) and thankfully had added a check that I wasn't adding a portal that already existed (my final input had a pair of RF portals and a pair of FR portals).

From reading the subreddit I see some people had inputs with unique letter pairings in them, that would have made it a bit easier I guess.

But yet another BFS although a slight twist this time. Part 2 wasn't tricky for me given the way I'd implemented it, just needed to add "level" to my state and minimum distance cache and only allow use of outer portals on levels > 0

Adding a bit of debug to my script I see the most number of nodes I have queued up for my BFS algorithm to ponder is only 175 and the search goes 25 levels down (although no idea how far my actual path takes as I don't record it).

Expecting a horror show tomorrow or Sunday though.

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2019, 03:15:29 pm

Enjoyed today (2019 day 21). Got my 9yo daughter to help me out with the logic for the first bit, especially good as you could see the results of trying different bits of logic.

She lost interest for part 2 though and, quite rightly, said "It's just more of the same, just a bit harder" and went back to programming with Scratch on her Raspberry Pi.

Title: Re: Advent of Code
Post by: Greenbank on 22 December, 2019, 12:43:47 pm

Quote from: Greenbank on 20 December, 2019, 01:26:57 pm

Expecting a horror show tomorrow or Sunday though.

Always fun to see the leaderboards and see that part 2 has taken a long time for the 100th person (>2h in this case). Not sure if I'll have time to do it this afternoon before I have to go out.

(click to show/hide)

Also not helpful wasting 15 minutes by not reading the actual question being asked for part 1. I was trying to answer "What card is in position 2019?" and not "What position is card 2019?"

Doh.

Title: Re: Advent of Code
Post by: Greenbank on 22 December, 2019, 02:25:54 pm

(click to show/hide)

Wow.

I think this one will weed out an awful lot of people as it is heavy on the number theoretical side of maths and also requires specialist programming knowledge to be able to do the required calculations.

I was lucky I spotted the first bit quite quickly but plowing through the maths required for the general solution took me a bit longer than it should have.

Having both a Comp Sci degree and Maths degree and a specific interest in Number Theory was very helpful indeed.

(click to show/hide)

First thing was noticing that all of the operations result in an equation of the form n = A*x + B mod D where A,B values of 1,0 give the identity operation of: n=(1*A)+0, D is the size of the deck

Cuts just change the offset (B) accordingly (keeping it mod D)

Dealing into a new stack just negates the multiplier (A) with a tweak to the offset B.

A deal with increment N multiples the multiplier (A) by N being careful to mod this resulting value by D to stop it getting too large.

The equations for two consecutive instructions can then be combined into a single equation with different A and B values. If two consecutive instructions can be combined into one than all the instructions can be combined into a single expression of the form:-

new_pos = (A * old_pos) + B mod D

The inverse of this can then be calculated such that old_pos = (A' * new_pos ) + B' mod D allow you to work backwards to see which card ends up in any particular position (i.e. 2020) after one iteration.

(I used a simple C program using libgmp to do the arbitrary sized integer stuff and also mpz_invert for modular inverses.)

Then it's a bit of maths to work out how to calculate (A' * x ) + B' mod D over 101741582076661 iterations:-

Hint: With f(x) = A'x+B' mod D you can look at f(f(x)) and f(f(f(x))) to work out the pattern and the general term for fⁿ(x).

Then it's a case of plugging in the calculated values of A',B' into the resulting formula to get the answer (again I used a C program that used libgmp to provide the modular exponentiation functions [mpz_powm] to make this relatively simple.)

Title: Re: Advent of Code
Post by: Ben T on 24 December, 2019, 11:23:35 pm

day 16 been grriiiiiiinnnnding away since, well, day 16. Think I might have to stop it.  :-[

Title: Re: Advent of Code
Post by: Ben T on 27 December, 2019, 02:45:07 pm

Quote from: Ben T on 24 December, 2019, 11:23:35 pm

day 16 been grriiiiiiinnnnding away since, well, day 16. Think I might have to stop it.  :-[

Day 16 part 2 a nice trick, very quickly realised the dynamic programming way of calculating the second half of the message but was stuck for ages on how to extend that to calculate the first half of the message...only just realised the method which is that

(click to show/hide)

you don't actually need to even know the first half of the message, in fact you don't need to know anything other than the last ~ 10%-15% of the message depending on what the first 7 digits are. Calculate the position to read from at the start and then stop the inner loop there.

Title: Re: Advent of Code
Post by: Davef on 30 December, 2019, 12:58:32 pm

Thanks for drawing my attention to this. I have really enjoyed doing it. I wasted hours with a fault reading my puzzle inputs. a spurious line break overwrote the character at offset 2000.  It had no effect until day 21 and 25 when my intcode computers worked nearly perfectly ... but not quite.

Title: Re: Advent of Code
Post by: Greenbank on 30 December, 2019, 05:35:27 pm

I plan on going back and uploading various versions of the code.
a) The hacked version I used just to complete the challenge (usually in perl but sometimes in C)
b) A cleaned up version of the above
c) A very clean version written in another language (C or maybe go)

I'll see if I can do this for 2015-2018 too although I may pick a different new language for each year (go and Rust are on my list)

(I have all 250 stars, be interesting to see the stats on how many people have done that. There were 362 people with 200 stars by April 2019: https://twitter.com/ericwastl/status/1116561274379259904 )

Title: Re: Advent of Code
Post by: Greenbank on 04 January, 2020, 09:37:40 am

Quote from: Greenbank on 30 December, 2019, 05:35:27 pm

(I have all 250 stars, be interesting to see the stats on how many people have done that. There were 362 people with 200 stars by April 2019: https://twitter.com/ericwastl/status/1116561274379259904 )

As of recently only 283 have all 250 stars:-

https://twitter.com/ericwastl/status/1213134461229031424

Title: Re: Advent of Code
Post by: Ashaman42 on 31 March, 2020, 10:57:44 am

Well I made a start at AoC 2019 in January to learn some new skills for work and to occupy slow spots at work. Got halfway through Day 3 and stalled somewhat - mostly due to work getting busy.

Well given the current lockdown and the fact I can't do much of my job from home I started again from scratch. I'm up to Day 5 now and plodding away. I don't really know how to program so it's a lot of Googling and head scratching. I'm pretty sure in days 1 - 3 I made exactly the same mistakes as I managed the first time round  ::-)

I'm also fairly sure that some of what I'm doing is completely the opposite of best practise but there we go. Definitely doing something wrong as each run of my day 3 solution with the full input takes well over an hour to chug through.

Currently programming in C++ via Visual Studio Community 2019.

Title: Re: Advent of Code
Post by: Greenbank on 31 March, 2020, 11:08:27 am

Quote from: Ashaman42 on 31 March, 2020, 10:57:44 am

Definitely doing something wrong as each run of my day 3 solution with the full input takes well over an hour to chug through.

If you can describe here in words how your algorithm works then someone here can give pointers...

Title: Re: Advent of Code
Post by: Ashaman42 on 31 March, 2020, 11:10:30 am

Cheers  :thumbsup:

I'll probably take you up on that at some point. Probably not today as I'm hip deep in day 5 and I think I'm getting somewhere with it. May as well keep on when I'm on a roll  ;D

Title: Re: Advent of Code
Post by: vorsprung on 31 March, 2020, 11:52:57 am

Quote from: Greenbank on 31 March, 2020, 11:08:27 am

Quote from: Ashaman42 on 31 March, 2020, 10:57:44 am

Definitely doing something wrong as each run of my day 3 solution with the full input takes well over an hour to chug through.

If you can describe here in words how your algorithm works then someone here can give pointers...

given that he is coding in C++ pointers are the problem

Title: Re: Advent of Code
Post by: Davef on 31 March, 2020, 01:40:33 pm

If you get stuck I have all 49 solutions in  Microsoft c++ and can give some hints.

I also have some ludicrously large intcode programs.


Sent from my iPad using Tapatalk

Title: Re: Advent of Code
Post by: Greenbank on 12 November, 2020, 07:30:16 am

Not long to go...I hope Eric has been busy.

Title: Re: Advent of Code
Post by: Ben T on 12 November, 2020, 01:30:36 pm

could do with it this month really :)

Title: Re: Advent of Code
Post by: Greenbank on 30 November, 2020, 02:36:51 pm

Tomorrow...

Title: Re: Advent of Code
Post by: R_nger on 01 December, 2020, 08:33:07 am

Broken ?

"We'll be right back!"

Title: Re: Advent of Code
Post by: Greenbank on 01 December, 2020, 08:39:16 am

I think the input generator is broken for some people.

Ah, he's posted over on reddit to say it was just his AWS instances running out of resources and shutting down. All due to the site being utterly swamped in the first few seconds after day 1 went live.

(I'm happy that happens at 5am UK time as I'm not interested in trying to get into the top 100.)

I got my input and was able to get both stars.

Title: Re: Advent of Code
Post by: Diver300 on 01 December, 2020, 11:26:42 am

Eric really has managed to set up the perfect conditions for an unintentional DDoS attack on his servers.

I thought that today's puzzle was a bit simple.

Title: Re: Advent of Code
Post by: Greenbank on 01 December, 2020, 11:54:02 am

The first two or three days are usually very gentle.

There's still plenty of scope for different approaches to even this simple problem though, some more efficient than others.

(Mine runs nigh on instantaneously even when I tell it to look for more than 4 numbers that add to 2020 - there is a 4 number solution for my input - no solutions other numbers though.)

Title: Re: Advent of Code
Post by: grams on 01 December, 2020, 01:00:44 pm

I did mine in Google Sheets with Vlookup. Managed to bodge it to find the four number solution too.

It runs with much fan noise and beachballing, like all great programs.

Title: Re: Advent of Code
Post by: Ben T on 01 December, 2020, 01:04:26 pm

(click to show/hide)

select n1.num * n2.num * n3.num from Day1 n1, Day1 n2, Day1 n3 where n1.num >= n2.num and n2.num >= n3.num and n1.num+n2.num+n3.num = 2020

Title: Re: Advent of Code
Post by: Greenbank on 01 December, 2020, 02:40:03 pm

(click to show/hide)

Don't normally do them in python but decided to give it a go.

Final spoiler, only click here if you want to see the code: https://gist.github.com/alexgreenbank/55daaa31c84974e1971af2e40e207784

Title: Re: Advent of Code
Post by: Davef on 01 December, 2020, 02:56:00 pm

I am redoing it in nostalgic intcode.

Title: Re: Advent of Code
Post by: Davef on 01 December, 2020, 03:33:54 pm

http://cloud.tapatalk.com/s/5fc661d8a8566/day1.txt (http://cloud.tapatalk.com/s/5fc661d8a8566/day1.txt)
If anyone wants to test their intcode computer from last year attached is this years day1 part 1 solution in intcode. It reads 200 lines from stdin and then produces the answer. It is large as it includes a pile of unneeded utility code.

Title: Re: Advent of Code
Post by: Pingu on 01 December, 2020, 05:02:31 pm

Day 1 done. Maybe I'll quit while I'm ahead.

Title: Re: Advent of Code
Post by: Greenbank on 02 December, 2020, 08:15:52 am

Once again it pays to read the problem description, including the bit highlighted in bold.

Title: Re: Advent of Code
Post by: Ben T on 02 December, 2020, 10:29:33 am

two lines of easily maintainable code  ;)

(click to show/hide)

awk -F'[ :-]' 'NF { print $5"\t^[^"$3"]*("$3"[^"$3"]*){" $1","$2"}[^"$3"]*$" }' day2.txt | awk '{ if($1 ~ $2) print $1 }' | wc -l

awk -F'[ :-]' 'NF { print substr($5,$1,1) "\t" substr($5,$2,1) "\t" $3 }' day2.txt | awk 'NF { print sub($3,"",$1) + sub($3,"",$2) }' | grep 1 | wc -l

Title: Re: Advent of Code
Post by: grams on 02 December, 2020, 11:08:15 am

Another victory for Google Sheets:
https://docs.google.com/spreadsheets/d/17LXRC-kEewCl3K1mvA1dzWJE8geZx9bK78o2fClZc0g

Title: Re: Advent of Code
Post by: freeflow on 02 December, 2020, 01:15:30 pm

Bah humbug.  Day2 with VBA using an interface and injected code!!!!!

Title: Re: Advent of Code
Post by: Greenbank on 02 December, 2020, 02:11:35 pm

Some ugly / semi-minimalist perl:-

(click to show/hide)

#!/usr/bin/perl

while( <> ) {
        @o = split( /\W+/ );
        %l=();
        map { $l{$_}++ } split( //, $o[3] );
        $r[0]++ if( $l{$o[2]} >= $o[0] && $l{$o[2]} <= $o[1] );
        $r[1]++ if( substr( $o[3], $o[0]-1, 1 ) eq $o[2] xor substr( $o[3], $o[1]-1, 1 ) eq $o[2] );
}
print "@r\n";

(I know it can be code golfed to a lot less than that, but that's about as minimalist as I'd go before it starts to become a puzzle rather than recognisable code.)

Title: Re: Advent of Code
Post by: Pingu on 02 December, 2020, 06:08:22 pm

Day 2 done  :thumbsup: I'm not brave enough to share my crappy JS coding though  :)

Title: Re: Advent of Code
Post by: tonycollinet on 02 December, 2020, 08:27:53 pm

Well this is rather fun. Not done any coding outside of simple VBA for years (about 20), and I'm trying this as a vehicle for learning python.

Day one:

(click to show/hide)

expense=[1956,1994,457,1654,2003,1902,1741,1494,1597,1129,1146,1589,1989,1093,1881,1288,1848,1371,1508,1035,1813,1335,1634,1102,1262,1637,1048,1807,1270,1528,1670,1803,1202,1294,1570,1640,1484,1872,1140,1207,1485,1781,1778,1772,1334,1267,1045,1194,1873,1441,1557,1414,1123,1980,1527,1591,1665,1916,1662,1139,1973,1258,1041,1134,1609,1554,1455,1124,1478,1938,1759,1281,1410,1511,930,1319,1302,1827,1216,1404,1460,2002,1590,1817,1341,1631,1608,1382,1158,1594,1049,1804,1555,1753,447,1021,1079,609,1766,1327,1851,1052,1737,1175,1043,1945,1573,1113,1724,1203,1856,1682,1623,1135,1015,1423,1412,1315,1375,1895,1351,1530,1758,1445,1518,1819,1567,1305,1919,1952,1432,1099,1476,1883,1871,1900,1442,1393,1214,1283,1538,1391,1008,1109,1621,1876,1998,1032,1324,1927,481,1732,1370,1683,1199,1465,1882,1293,1671,1456,1197,1506,1381,1469,1830,1957,1850,1184,1564,1170,1943,1131,1867,1208,1788,1337,1722,1760,1651,1069,1574,1959,1770,66,1190,1606,1899,1054,980,1693,1173,1479,1333,1579,1720,1782,1971,1438,1178,1306]
 
for index, num1 in enumerate(expense):
    for num2 in expense[index+1:]:
        if num1+num2 == 2020:
            print (num1, num2, num1+num2, num1*num2)

***************
And day 2: (for day two, I learned to read the input data from a text file into a list rather than declaring the data in the list)

(click to show/hide)

input_file = open("2aInput.txt", "r")
input_as_list = [(line.strip()).split() for line in input_file]
input_file.close()

valid=0

for password in input_as_list:
    occur = 0
    num1 = int(password[0].rsplit("-")[0])
    num2 = int(password[0].rsplit("-")[1])
    letter = password [1][0]
    if password[2][num1-1]==letter:occur+=1
    if password[2][num2-1]==letter:occur+=1
    if occur ==1: valid +=1

print (valid)

Title: Re: Advent of Code
Post by: tonycollinet on 02 December, 2020, 08:38:58 pm

Quote from: Greenbank on 02 December, 2020, 02:11:35 pm

Some ugly / semi-minimalist perl:-

(click to show/hide)

#!/usr/bin/perl

while( <> ) {
        @o = split( /\W+/ );
        %l=();
        map { $l{$_}++ } split( //, $o[3] );
        $r[0]++ if( $l{$o[2]} >= $o[0] && $l{$o[2]} <= $o[1] );
        $r[1]++ if( substr( $o[3], $o[0]-1, 1 ) eq $o[2] xor substr( $o[3], $o[1]-1, 1 ) eq $o[2] );
}
print "@r\n";

(I know it can be code golfed to a lot less than that, but that's about as minimalist as I'd go before it starts to become a puzzle rather than recognisable code.)

Call that recognisable? Let me give you a layman's  ;D ;D ;D :) ::-) ::-) ::-) ;D ;D ;D :facepalm:

Title: Re: Advent of Code
Post by: Greenbank on 03 December, 2020, 11:15:27 am

(click to show/hide)

Today's lesson is arrays and the modulo operator.

Still waiting for the first nasty one.

Title: Re: Advent of Code
Post by: freeflow on 03 December, 2020, 04:57:01 pm

Yes.  The introduction is quite gentle this year.

Title: Re: Advent of Code
Post by: Pingu on 03 December, 2020, 06:16:09 pm

Day 3 done  :)

I've been putting my amateur JS code efforts here: http://www.pinniped.plus.com/AoC/index.htm

Title: Re: Advent of Code
Post by: Pingu on 03 December, 2020, 06:31:50 pm

Quote from: Greenbank on 03 December, 2020, 11:15:27 am

Today's lesson is arrays and the modulo operator...

Could you put hints in a Spoiler, please?

Title: Re: Advent of Code
Post by: tonycollinet on 03 December, 2020, 08:14:22 pm

Quote from: Pingu on 03 December, 2020, 06:16:09 pm

Day 3 done  :)

I've been putting my amateur JS code efforts here: http://www.pinniped.plus.com/AoC/index.htm

There is no source to view (firefox)

Title: Re: Advent of Code
Post by: Pingu on 03 December, 2020, 08:17:53 pm

Quote from: tonycollinet on 03 December, 2020, 08:14:22 pm

Quote from: Pingu on 03 December, 2020, 06:16:09 pm

Day 3 done  :)

I've been putting my amateur JS code efforts here: http://www.pinniped.plus.com/AoC/index.htm

There is no source to view (firefox)

Ctrl-u or right-click > View source

Title: Re: Advent of Code
Post by: tonycollinet on 03 December, 2020, 11:18:38 pm

Ahhhhh - of course  ;D

Title: Re: Advent of Code
Post by: Greenbank on 04 December, 2020, 11:00:06 am

Quote from: Pingu on 03 December, 2020, 06:31:50 pm

Quote from: Greenbank on 03 December, 2020, 11:15:27 am

Today's lesson is arrays and the modulo operator...

Could you put hints in a Spoiler, please?

Ah, ok, sorry, will do.

(click to show/hide)

And today we have regex parsing.

(click to show/hide)

"They aren't actually passport details, instead they are instructions for a special kind of computer ..."

Title: Re: Advent of Code
Post by: Ben T on 04 December, 2020, 11:41:23 am

Found day 4 a bit boring to be honest.
Reading arbitrary rules and writing validation code is a bit too much like actual work... :-\

Title: Re: Advent of Code
Post by: Ben T on 04 December, 2020, 11:43:37 am

Quote from: Greenbank on 04 December, 2020, 11:00:06 am

(click to show/hide)

"They aren't actually passport details, instead they are instructions for a special kind of computer ..."

Quote

(click to show/hide)

the presence of colours makes me think it might make a picture. Years in fact being pixel positions, perhaps

Title: Re: Advent of Code
Post by: grams on 04 December, 2020, 02:01:51 pm

Still sticking with Google Sheets until they force me to stop.

Day 3:
https://docs.google.com/spreadsheets/d/1­7_5yPJ8oNENFlRtqBnbCOLqE50RDK5QlLC_3p1v8­Csg/edit

Day 4:
https://docs.google.com/spreadsheets/d/1Gj7tgbzQUkiwS5_wJ62lvNfRNmbqBpAjdYLCAD1ulQw/edit

Title: Re: Advent of Code
Post by: freeflow on 04 December, 2020, 04:35:52 pm

Day04 has me scratching my head.  My VBA (with interfaces and code injection!!)  works OK with the test  data but fails on the real stuff < mumble mumble mumble go read the question again again again again>

Title: Re: Advent of Code
Post by: Pingu on 04 December, 2020, 04:45:42 pm

Day 4 done.

http://www.pinniped.plus.com/AoC/index.htm

Title: Re: Advent of Code
Post by: Pingu on 04 December, 2020, 04:50:12 pm

Quote from: grams on 04 December, 2020, 02:01:51 pm

Still sticking with Google Sheets until they force me to stop.

Do you have a link to your Day 1 solution?

Title: Re: Advent of Code
Post by: Greenbank on 04 December, 2020, 04:57:11 pm

Quote from: Pingu on 04 December, 2020, 04:50:12 pm

Quote from: grams on 04 December, 2020, 02:01:51 pm

Still sticking with Google Sheets until they force me to stop.

Do you have a link to your Day 1 solution?

He posted it elsewhere: https://docs.google.com/spreadsheets/d/1joA1oMsoGaDCwX0u8CAK7IUuMeFqyfLEYzzIWzGB1d0/edit#gid=0

Title: Re: Advent of Code
Post by: Pingu on 04 December, 2020, 05:12:17 pm

Quote from: Greenbank on 04 December, 2020, 04:57:11 pm

Quote from: Pingu on 04 December, 2020, 04:50:12 pm

Quote from: grams on 04 December, 2020, 02:01:51 pm

Still sticking with Google Sheets until they force me to stop.

Do you have a link to your Day 1 solution?

He posted it elsewhere: https://docs.google.com/spreadsheets/d/1joA1oMsoGaDCwX0u8CAK7IUuMeFqyfLEYzzIWzGB1d0/edit#gid=0

Ta  :thumbsup:

Title: Re: Advent of Code
Post by: vorsprung on 04 December, 2020, 10:08:26 pm

I spent all day writing 4 unit tests for a react state filter

So excuse me if ICBA

Title: Re: Advent of Code
Post by: tonycollinet on 05 December, 2020, 12:06:51 am

Quote from: Ben T on 04 December, 2020, 11:41:23 am

Found day 4 a bit boring to be honest.
Reading arbitrary rules and writing validation code is a bit too much like actual work... :-\

This

Though I am using it as an excuse to learn

(click to show/hide)

regular expressions

Title: Re: Advent of Code
Post by: Pingu on 05 December, 2020, 12:19:57 am

Quote from: Ben T on 04 December, 2020, 11:41:23 am

Found day 4 a bit boring to be honest.
Reading arbitrary rules and writing validation code is a bit too much like actual work... :-\

I learnt more about how JSON works  :)

Title: Re: Advent of Code
Post by: Ben T on 05 December, 2020, 11:15:21 am

(click to show/hide)

sed -E 's/([R|L]{3})/ \1/g' | sed -E 's/[F|L]/0/g; s/[B|R]/1/g' | perl -lane 'print oct("0b"."@F[0,2]")." ".oct("0b"."@F[1,2]")' | awk '{print $1*8+$2}' | awk 'BEGIN{max=0} {if ($1>0+max) max=$1} END {print max}'

./day5.sh < day5.txt

part 2 just replace the last awk with 'sort -n' and look through the list, with the help of 'select * from Day5 d where not exists (select * from Day5 d2 where d2.num = d.num + 1 );' (answer is the lowest row returned + 1)

Title: Re: Advent of Code
Post by: Greenbank on 05 December, 2020, 11:57:08 am

(click to show/hide)

Quote from: Ben T on 05 December, 2020, 11:15:21 am

sed -E 's/([R|L]{3})/ \1/g' | sed -E 's/[F|L]/0/g; s/[B|R]/1/g' | perl -lane 'print oct("0b"."@F[0,2]")." ".oct("0b"."@F[1,2]")' | awk '{print $1*8+$2}' | awk 'BEGIN{max=0} {if ($1>0+max) max=$1} END {print max}'

No need to split things up, just treat the whole input as a single binary number. Also use tr instead of sed. Use sort -rn and head -1 to find the max.

cat 5.inp | tr FLBR 0011 | perl -lane 'print oct("0b".$_)' | sort -rn | head -1

Title: Re: Advent of Code
Post by: Pingu on 05 December, 2020, 01:17:49 pm

Day 5 done.

http://www.pinniped.plus.com/AoC/index.htm

Title: Re: Advent of Code
Post by: Ben T on 05 December, 2020, 02:59:39 pm

Quote from: Greenbank on 05 December, 2020, 11:57:08 am

(click to show/hide)

Quote from: Ben T on 05 December, 2020, 11:15:21 am

sed -E 's/([R|L]{3})/ \1/g' | sed -E 's/[F|L]/0/g; s/[B|R]/1/g' | perl -lane 'print oct("0b"."@F[0,2]")." ".oct("0b"."@F[1,2]")' | awk '{print $1*8+$2}' | awk 'BEGIN{max=0} {if ($1>0+max) max=$1} END {print max}'

No need to split things up, just treat the whole input as a single binary number. Also use tr instead of sed. Use sort -rn and head -1 to find the max.

cat 5.inp | tr FLBR 0011 | perl -lane 'print oct("0b".$_)' | sort -rn | head -1

(click to show/hide)

Interesting. Would however argue that using awk to get the max is more performant than sort because it only requires one pass, at the expense of less simplicity.

Title: Re: Advent of Code
Post by: tonycollinet on 05 December, 2020, 09:16:21 pm

Day 5 relatively trivial.

(click to show/hide)

input_file = open("5aInput.txt", "r")
#input_as_list = [(line.strip()).split() for line in input_file]
input_as_list = [line.strip() for line in input_file]
input_file.close()


max_id = 0
min_id = 1024
ids = []
for ticket in input_as_list:
    id = 0
    for bitnum in range (10):
        index = 9 - bitnum
        bit = ticket[index]
        if bit =="B" or bit == "R":id += 2 ** bitnum
    if id > max_id: max_id = id
    if id < min_id: min_id = id
    ids.append(id)
   
print (min_id, max_id)

for id in range (min_id, max_id):
    if not id in ids: print ("Missing ID is ", id)

EDIT: or more efficiently with direct conversion...

(click to show/hide)

to binary:


input_file = open("5aInput.txt", "r")
#input_as_list = [(line.strip()).split() for line in input_file]
input_as_list = [line.strip() for line in input_file]
input_file.close()


max_id = 0
min_id = 1024
ids = []
for ticket in input_as_list:
    ticket = ticket.replace("B","1")
    ticket = ticket.replace("F","0")
    ticket = ticket.replace("R","1")
    ticket = ticket.replace("L","0")
    id = int(ticket,2)

    if id > max_id: max_id = id
    if id < min_id: min_id = id
    ids.append(id)
   
print (min_id, max_id)

for id in range (min_id, max_id):
    if not id in ids: print ("Missing ID is ", id)

Title: Re: Advent of Code
Post by: grams on 05 December, 2020, 10:49:03 pm

Day 5 probably the easiest spreadsheet yet:
https://docs.google.com/spreadsheets/d/1urBVcFFAz4HzJshKldFKtgobE_Zi8DGGNgY4Na5ATHw/edit?usp=sharing

Title: Re: Advent of Code
Post by: Pingu on 05 December, 2020, 11:01:24 pm

Quote from: grams on 05 December, 2020, 10:49:03 pm

Day 5 probably the easiest spreadsheet yet:
https://docs.google.com/spreadsheets/d/1urBVcFFAz4HzJshKldFKtgobE_Zi8DGGNgY4Na5ATHw/edit?usp=sharing

Loving the spreadsheet solutions :thumbsup: You are Dido Harding AICMFP  :D

Title: Re: Advent of Code
Post by: tonycollinet on 05 December, 2020, 11:08:48 pm

Quote from: grams on 05 December, 2020, 10:49:03 pm

Day 5 probably the easiest spreadsheet yet:
https://docs.google.com/spreadsheets/d/1urBVcFFAz4HzJshKldFKtgobE_Zi8DGGNgY4Na5ATHw/edit?usp=sharing

So - your data set is different than mine - bigger even. Does that mean each participant gets their own data?

Title: Re: Advent of Code
Post by: Pingu on 05 December, 2020, 11:16:47 pm

Quote from: tonycollinet on 05 December, 2020, 11:08:48 pm

Quote from: grams on 05 December, 2020, 10:49:03 pm

Day 5 probably the easiest spreadsheet yet:
https://docs.google.com/spreadsheets/d/1urBVcFFAz4HzJshKldFKtgobE_Zi8DGGNgY4Na5ATHw/edit?usp=sharing

So - your data set is different than mine - bigger even. Does that mean each participant gets their own data?

Yes

Title: Re: Advent of Code
Post by: tonycollinet on 06 December, 2020, 12:20:02 am

That is very cool.

The creators obviously put a lot of work into that.

Title: Re: Advent of Code
Post by: Greenbank on 06 December, 2020, 09:43:32 am

Day 6 was nowhere near as difficult as I expected.

(click to show/hide)

Luckily the way I'd chosen to implement part 1 made adapting it for part 2 relatively easy.

(This doesn't often happen, so I'll take it.)

I'd read in each group and incremented an entry in a hash for each letter that was contained in the hash.

Part 1 was simply summing the number of keys in the hash each time (and clearing the hash between groups).

For part 2 I just had to add a count the number of people in the group (the number of lines that made it up) and then count the number of keys in the hash that were the same as the number of people in the group.

Both answers correct first time too.

Also a simple "grep "[^a-z]" 6.inp" showed me there were no characters other than lower case a-z and so I didn't have to bother with any code to deal with unexpected situations. That and checking the last line was a blank line so that the last group wasn't forgotten about (if I only kicked off the processing when reading in a blank line).

Title: Re: Advent of Code
Post by: tonycollinet on 06 December, 2020, 09:44:38 am

Day 6 complete.

I have to say Python has an incredibly rich set of functionality. Almost every operation I need to do has a pre-defined method.

(click to show/hide)

input_file = open("6aInput.txt", "r")
#input_as_list = [(line.strip()).split() for line in input_file]
input_as_list = [line.strip() for line in input_file]
input_file.close()

groups = []
group = []
sumCountsAny = 0
sumCountsAll = 0

for line in input_as_list:
    if len (line)==0:
        groups.append (group)
        group = []
    else:
        group.append (line)
           
groups.append (group)   

# Any person answered question yes
# for group in groups:
#     groupSummarised = "".join(set("".join(group)))
#     sumCountsAny += len (groupSummarised)
#     print (group, groupSummarised, len (groupSummarised),sumCountsAny)
   
# All people answered question yes
for group in groups:
    groupSummarisedSet = set.intersection(*[set(x) for x in group])
    sumCountsAll += len (groupSummarisedSet)
    print (group, groupSummarised, len (groupSummarised),sumCountsAll)
   
print (sumCountsAny, sumCountsAll)

Title: Re: Advent of Code
Post by: grams on 06 December, 2020, 10:22:47 am

Day 6: Still spreadsheeting
https://docs.google.com/spreadsheets/d/1VXcXG-N5KLMXUIs0Tdb7ObusNgZVVFaLnjdTCfD4AsA/edit?usp=sharing

I cocked up this time because this is the first dataset that's longer than 1000 lines (Google Sheets default size) and I handed bothered filling down my formulae.

Title: Re: Advent of Code
Post by: Pingu on 06 December, 2020, 12:24:06 pm

Day 6 done.

http://www.pinniped.plus.com/AoC/index.htm

Title: Re: Advent of Code
Post by: grams on 07 December, 2020, 01:16:23 pm

Day 7:

Spent much longer wrestling with the shitty lookup functions (VLOOKUP and MATCH) then I did with making recursion work.

https://docs.google.com/spreadsheets/d/11cUvSGYl9NT2-3prdotWaXyiD_-DfIFLJmeRujuxXwQ/edit?usp=sharing

Title: Re: Advent of Code
Post by: Greenbank on 07 December, 2020, 02:14:26 pm

Luckily part 2 didn't ask about the shiny purple bag:

BAG: shiny purple = 365714937810

Still waiting for a humdinger.

Title: Re: Advent of Code
Post by: Davef on 07 December, 2020, 02:30:45 pm

Just done days 2 through 7. Not very exciting so far.

Title: Re: Advent of Code
Post by: Pickled Onion on 07 December, 2020, 07:29:53 pm

Just done 2016 day 11. Had a mental block on it at the time, not sure why, it was fairly straightforward when I actually started coding it, with some interesting puzzles over optimisation.

Title: Re: Advent of Code
Post by: tonycollinet on 07 December, 2020, 09:14:56 pm

Well, as a relative novice, today had me scratching my head a little.

Getting head around recursion is tricky. I also had a function return statement that prevented the function processing anything other than the first "subbag" - which took nearly an hour to find.

Even just working out how to parse the input takes some time if you've never done it before.

Still - got there in the end.

(click to show/hide)

def bagContains (bag, bagName):
    for subbag in bag [1:]:
        if subbag[1]==bagName:
            return True
    return False
   

containingBags = []
def findContainingBags (bagName):
    count = 0
    countSG = 0
    for bag in bags:
        if bagContains (bag, bagName):
            containingBags.append(bag[ 0 ] )
            count += 1
            count += findContainingBags (bag[ 0 ] )
    return count

def countBagsInside (bagname):
    count = 0
    for bag in bags:
        if bag[0] == bagname:
            for subbag in bag [1:]:
                count += int (subbag [ 0 ] )         
                count += int (subbag [ 0 ] ) * countBagsInside (subbag [1] )
    return count           

input_file = open("7aInput.txt", "r")
#input_as_list = [(line.strip()).split() for line in input_file]
input_as_list = [line.strip() for line in input_file]
input_file.close()


bags = []

#parse input into bag list structure
for line in input_as_list:
    bag = []
    subbags = []
    bag.append(line.split(" bags contain ")[0])
    subbags= (line.split(" bags contain ")[1].split(", "))
    for subbag in subbags:
        subbag = subbag.replace(".","")
        subbag = subbag.replace(" bags","")
        subbag = subbag.replace(" bag","")
        subbag = subbag.replace("no","0")
        bag.append (subbag.split(" ",1))   
    bags.append (bag)
   
dummy = findContainingBags ("shiny gold")
print ("Part 1: Number of bags containing a shiny gold bag is", len(set(containingBags)))

print ("Part 2: Total bags inside a shiny gold bag is ", countBagsInside ("shiny gold"))

Title: Re: Advent of Code
Post by: Davef on 08 December, 2020, 09:42:23 am

A little more interesting today. I can see there could be some fun ahead.

Title: Re: Advent of Code
Post by: Greenbank on 08 December, 2020, 09:45:47 am

Indeed, the beginnings of the VM.

(click to show/hide)

I'll probably spin out the execution code to a separate source file that can be included by future days.

I'll include a bunch of other stuff that might come up, such as input/output queues, ability to execute multiple instances of the VM at once, etc

These are all things that have come up in previous years.

Title: Re: Advent of Code
Post by: Davef on 08 December, 2020, 09:50:19 am

I was thinking Gödel’s incompleteness theorem and the Turing halting problem. It might inspire you to go back to your bookshelf.

Title: Re: Advent of Code
Post by: Ben T on 08 December, 2020, 10:01:58 am

I bloody hate these ones where you have to try and reverse engineer the machine code to find out what it's doing. For day 8 it was quite easy to test whether it's an infinite loop or not, as the program is effectively immutable. It's the ones where it jumps by the amount of a variable that are annoying.

Title: Re: Advent of Code
Post by: Greenbank on 08 December, 2020, 10:09:25 am

I kind of like this ones.

I end up rewriting it in something like perl and then replacing the instructions/jumps/branches with higher level constructs (while loops, for loops, etc) and then working out what the code is doing (such as painfully slowly implementing Eulers totient or phi function or similar).

Title: Re: Advent of Code
Post by: Greenbank on 08 December, 2020, 10:17:31 am

Quote from: Davef on 08 December, 2020, 09:50:19 am

I was thinking Gödel’s incompleteness theorem and the Turing halting problem. It might inspire you to go back to your bookshelf.

And my degree(s). I did a fair bit on both of those in each of them.

Looking forward to some other problems like:-
* a big nasty number theory problem (like the Chinese Remainder Theorem inspired one [2017 day 13], or the famous Space Cards [2019 day 22]).
* an A* or SAT style solver
* ...probably in a maze of some sort
* Writing something to interactively play a game (like Breakout [2019 day 13])
* A 3D (or even 4D) problem

Title: Re: Advent of Code
Post by: Ben T on 08 December, 2020, 11:07:48 am

Quote from: Greenbank on 08 December, 2020, 10:09:25 am

I kind of like this ones.

I end up rewriting it in something like perl and then replacing the instructions/jumps/branches with higher level constructs (while loops, for loops, etc) and then working out what the code is doing (such as painfully slowly implementing Eulers totient or phi function or similar).

I'll usually just leave it grinding away in C++ on my old ubuntu laptop unless it's literally going to take years.  :)

Title: Re: Advent of Code
Post by: grams on 08 December, 2020, 11:52:56 am

Day 8 done:
https://docs.google.com/spreadsheets/d/1QLnJ--jc1d18qHiwcO1QXnqyaoG078-09HlYiXvoA_0/edit#gid=1072555748

I started doing part 2 by inspection, but that seemed against the spirit of it. So executed it 500 times in one spreadsheet instead. Fan is still spinning.

Title: Re: Advent of Code
Post by: tonycollinet on 08 December, 2020, 07:51:37 pm

Day 8 done.

Quite liked this one - though tied myself up with failing to modify global variables in a function. Eventually found the "global" statement.

(click to show/hide)

executed multiple runs, incrementing the code address at which the instruction would be changed each run. Later halved the number of runs by starting at the maximum address, and decrementing that each run.

I could reduce it further by checking the selected address is nop or jmp, but can't be bothered  :D

******
def resetProgram():
    global addr
    global acc
    global program
   
    addr = 0
    acc = 0
    for index, code in enumerate (program):
        program [index][2] = 0
       

input_file = open("8aInput.txt", "r")
#input_as_list = [(line.strip()).split() for line in input_file]
input_as_list = [line.strip() for line in input_file]
input_file.close()


program = []

#parse input into program memory - third item of line is instruction execution count
for line in input_as_list:
    codeLine = []
    codeLine = [line.split(" ")[0],int(line.split(" ")[1]), 0]
    program.append (codeLine)

addr = 0
acc = 0
addrToChange = len(program) - 1
runcount = 0

#Execute program
while addr < len(program):
# setup instruction

    inst = program[addr][0]
    if addr == addrToChange:
        if inst == "nop" :
            inst = "jmp"
            print ("address ",addr, "nop changed to jmp")
        elif inst == "jmp" :
            inst = "nop"
            print ("address ",addr, "jmp changed to nop")
    param = program[addr][1]


#check for pass termination or execute instruction
    program[addr][2]+=1
    if program[addr][2] > 1:
        print (acc, runcount, addrToChange)   
        resetProgram()
        runcount +=1
        addrToChange -=1
    else:   
    #execute instruction     
        if inst == "jmp": addr+= param
        elif inst == "acc":
            acc+= param
            addr+=1
        else:
            addr+=1

       
print (acc)

Title: Re: Advent of Code
Post by: Greenbank on 09 December, 2020, 07:59:08 am

Day 9 underwhelming.

Lucky as I've got a busy day.

Title: Re: Advent of Code
Post by: tonycollinet on 09 December, 2020, 08:56:44 am

Key learning point for day 9, as in most tests:

Read the fecking question  ::-) ::-)

Title: Re: Advent of Code
Post by: Greenbank on 09 December, 2020, 05:36:11 pm

Had the time to redo my day 9 properly.

(click to show/hide)

Usual paranoia that the O(n) sliding window algorithm used in part 2 may not always work (it does as long as you don't have any negative numbers).

Title: Re: Advent of Code
Post by: Diver300 on 10 December, 2020, 07:13:34 am

Day 10 was quite interesting.

(click to show/hide)

I did part 1 on a spreadsheet, where sorting is two clicks.

For part 2 I realised that each time there is a step of 3 jolts, it effectively splits the problem into "above" and "below" the 3 jolt gap.

I then saw that the biggest run of 1-jolt gaps was 4, and I worked out how many ways there are to cover runs of 1 to 4 1-jolt gaps by writing down the possibilities. It's only 7 for a run of 4.

Then I used the spreadsheet to work out the lengths or the runs of 1-jolt gaps, used a look-up to find how many ways that run can be covered. The answer was just the product of all those look-up results.

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2020, 08:43:02 am

Spent far too long on part 2 as I was distracted by a work call where I had to be paying attention for most of it.

Got the answer with similar observations to Diver300 above.

Title: Re: Advent of Code
Post by: Davef on 10 December, 2020, 09:42:00 am

I am not sure a solution that only works with a subset of the possibilities even if it happens to work for your data set is satisfactory.

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2020, 09:55:12 am

Well yes, getting the two stars the bare minimum, but I rarely ever stop there.

Other things to consider are:
a) Does it handle exceptions or assume the input data is clean?
b) Will it work on slightly different input (eg, what would your code for today [2020 Day 10] have done if the input consisted of the numbers to 1 to 8)?
c) Will it be performant on pathalogical cases of inputs of the same magnitude
d) Will it be performant/correct on inputs of a much greater magnitude
...etc...

Title: Re: Advent of Code
Post by: Ben T on 10 December, 2020, 10:43:22 am

(click to show/hide)

Code: [Select]

        static async Task Run(string[] args)
        {
            long desiredTotal = long.Parse(args[0]);

            var numbers = new List<long>();
            string line;
            while((line = await Console.In.ReadLineAsync()) != null)
            {
                numbers.Add(long.Parse(line));
                while(numbers.Sum() > desiredTotal)
                {
                    numbers.RemoveAt(0);
                }

                if(numbers.Sum() == desiredTotal)
                {
                    await Console.Out.WriteLineAsync($"{numbers.Min() + numbers.Max()}");
                    return;
                }
            }
        }


(click to show/hide)

part 1:
sort -n day10.txt | awk '{if($1-prev==1) ones++; if($1-prev==3) threes++; prev=$1} END {print ones*(threes+1)}'

part 2: pretty standard combinations alg (apart from to change int->long when it overflowed and returned a negative)

Code: [Select]

    public class Day10
    {
        private static ConcurrentDictionary<long[], long> cache = new ConcurrentDictionary<long[], long>(new Comparer());
        public static async Task Run(string[] args)
        {
            var numbersList = new List<long>();
            string line;
            while((line = await Console.In.ReadLineAsync()) != null)
            {
                numbersList.Add(long.Parse(line));
            }
            numbersList.Insert(0, 0);
            numbersList.Add(numbersList.Max() + 3);
            numbersList.Sort();
            var combinations = cache.GetOrAdd(numbersList.ToArray(), CalculateCombinations);
            await Console.Out.WriteLineAsync(combinations.ToString());
        }

        private static long CalculateCombinations(long[] remaining)
        {
            if(remaining.Length <= 1) return 1;
            long combinations = 0;
            for(var i = 1; i < remaining.Length; i++)
            {
                if(remaining[i] <= remaining[0] + 3)
                    combinations += cache.GetOrAdd(remaining.Skip(i).ToArray(), CalculateCombinations);
                else break;
            }
            return combinations;
        }

    }

    class Comparer : IEqualityComparer<long[]>
    {
        public bool Equals([AllowNull] long[] x, [AllowNull] long[] y) => x.SequenceEqual(y);

        public int GetHashCode([DisallowNull] long[] obj)
        {
            int hashCode = 31;
            foreach(var i in obj) hashCode = HashCode.Combine(hashCode, i);
            return hashCode;
        }
    }



Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2020, 10:50:44 am

(click to show/hide)

Tweaked my code to handle pathalogical cases:-

Code: [Select]

$ seq 1 73 | time ./10.pl
Part 1: d1=73 d3=1 tot=73
Part 2: 12903063846126135669
0.00user 0.00system 0:00.00elapsed 50%CPU (0avgtext+0avgdata 9248maxresident)k
0inputs+0outputs (0major+617minor)pagefaults 0swaps
(Any more than 73 and the output is > 2^64 and I can't be bothered to deal with that.)

Before the tweaks my solution would take more than second to do the output for an input of 1..30, no chance of it ever returning with an input of 1..73

Title: Re: Advent of Code
Post by: grams on 10 December, 2020, 01:05:46 pm

Day 9:
https://docs.google.com/spreadsheets/d/1­aRLwJyPDhppCY4Xuy6ciW_zAutiHcRFAGpK4CkQF­yy4/edit?usp=sharing

Day 10 part 2:
https://docs.google.com/spreadsheets/d/1­2uXNKlJWxkxXb80ATMF3YRxS9fdXDgycL_ViGti3­gu0/edit?usp=sharing

I populated the lookup tab by figuring out what numbers would make the two examples work. That was enough to make the real data work.

Quote from: Davef on 10 December, 2020, 09:42:00 am

I am not sure a solution that only works with a subset of the possibilities even if it happens to work for your data set is satisfactory.

I think they must deliberately generate the data to allow simpler approaches to work. Seems unnecessary to go beyond that.

It is just for fun after all.

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2020, 01:27:38 pm

Quote from: grams on 10 December, 2020, 01:05:46 pm

I think they must deliberately generate the data to allow simpler approaches to work. Seems unnecessary to go beyond that.

It is just for fun after all.

Indeed, as I said above, there's a challenge in going beyond it. (But then that's easier for me as programming has been my job for years.)

And, without going beyond the two stars you may not learn about lovely things such as:

(click to show/hide)

Tribonacci numbers

Title: Re: Advent of Code
Post by: tonycollinet on 10 December, 2020, 01:52:34 pm

Well that (day 10) had me scratching my head for a bit.

Quote from: Davef on 10 December, 2020, 09:42:00 am

I am not sure a solution that only works with a subset of the possibilities even if it happens to work for your data set is satisfactory.

The data is set up so that you have to do it that way....

(click to show/hide)

My 'exhaustive' combination method was generating about 100K solutions per second. Assuming a trillion possible answers, this  was going to take about 10 (24 hour) days to complete and then would probably have been wrong the first time around (in fact, the actual answer was >>1 trillion - I'd have been waiting more than 100 years :) ).

The first part of the question is designed to show the way. You are asked to calculate how many step 3's there are. These then become the points within the data that allow you to break it into a multiple of some much smaller combination sets.

(click to show/hide)

def FindCombinations (jolt,target,start):
    global data
    global solutionCount
    newJolt = 0
   
    for index, adaptj in enumerate( data [start:] ):
        jdif = adaptj - jolt
        if jdif < 4 and jdif >0:
            newJolt = jolt+jdif
            if newJolt == target:
                solutionCount +=1
                return True
            elif newJolt < target:
                FindCombinations (newJolt, target, start+index)
    return False

# start
input_file = open("10aInput.txt", "r")
#data = [(line.strip()).split() for line in input_file]
data = [int(line.strip()) for line in input_file]
input_file.close()

data.sort()

# part 1
jolt = 0
difCounters = [0,0,0,0]

for adapterJ in data:
    jdif = adapterJ - jolt
    if jdif < 4 and jdif >= 0:
        jolt += jdif
        difCounters [ jdif ] += 1
    else:
        print (jolt, adapterJ, "ERROR ERROR ERROR")
        break

difCounters [3]+= 1 #built in adapter
jolt += 3
   
print (jolt, difCounters, difCounters [1]* difCounters [3]) #part 1 answer


#part 2
#find targets
targets = [[0,0,0]]

for index, jolt in enumerate (data):
    if index+1 < len(data) and data[index+1]==jolt+3:
        targets.append ([jolt, index, 0])

#add final targets for internal adapter
       
targets.append ([data[len(data)-1],len(data)-1,0])

print (targets)
solutionCount = 0
totalSolutions = 0

for tIndex in range (1, len (targets)):
    startJolt = targets [tIndex-1] [ 0 ]
    targetJolt = targets [tIndex] [ 0 ]
    dataStart = targets [tIndex-1] [1]
    FindCombinations ( startJolt, targetJolt, dataStart )
    targets [tIndex][2] = solutionCount
    solutionCount = 0
    if tIndex == 1:
        totalSolutions = targets [1][2]
    else:
        totalSolutions = totalSolutions * targets [tIndex][2]
 
print (targets)
print (totalSolutions) #answer part 2

Title: Re: Advent of Code
Post by: Davef on 10 December, 2020, 02:10:40 pm

How do you do this spoiler malarkey ?

Title: Re: Advent of Code
Post by: tonycollinet on 10 December, 2020, 02:12:00 pm

Click the Sp button next to the

Quote

quote

button.

Title: Advent of Code
Post by: Davef on 10 December, 2020, 02:18:38 pm

Single sequential pass, ‘one line’ solution to day 10 part 2.

(click to show/hide)

// works with sequences of up to 7 ones so
// more than enough for sample input
// single pass with freaky obfuse arithmetic !

__int64 part2(int *a, int n)
{
__int64 r=1;

qsort(a, n, sizeof(int), s);

int c = -1;
for (; n; a++) if (c += a[1]-*a==1,!--n||a[1]-*a==3) { r*=c>=0?(2<<c)-(c*c-c>>1):1;c=-2; }

return r;
}

Edit: Realised it was a bit longwinded so abbreviated
Edit: could remove the curly brackets and use comma operator, but that might make it less readable.

Title: Re: Advent of Code
Post by: Ben T on 10 December, 2020, 02:47:00 pm

Quote from: Davef on 10 December, 2020, 02:10:40 pm

How do you do this spoiler malarkey ?

[spoiler]the code[/spoiler]

Title: Re: Advent of Code
Post by: Davef on 10 December, 2020, 02:47:47 pm

Quote from: Ben T on 10 December, 2020, 02:47:00 pm

Quote from: Davef on 10 December, 2020, 02:10:40 pm

How do you do this spoiler malarkey ?

[spoiler]the code[/spoiler]

Thanks. Done now. See above.

Title: Re: Advent of Code
Post by: Diver300 on 11 December, 2020, 08:00:01 am

Day 11 done.

I keep making the mistake of writing something like:-

Code: [Select]

} while ( done = 0 ) when I mean

Code: [Select]

} while ( done == 0 )

Title: Re: Advent of Code
Post by: Davef on 11 December, 2020, 08:28:49 am

Quote from: grams on 10 December, 2020, 01:05:46 pm

Day 9:
https://docs.google.com/spreadsheets/d/1­aRLwJyPDhppCY4Xuy6ciW_zAutiHcRFAGpK4CkQF­yy4/edit?usp=sharing

Day 10 part 2:
https://docs.google.com/spreadsheets/d/1­2uXNKlJWxkxXb80ATMF3YRxS9fdXDgycL_ViGti3­gu0/edit?usp=sharing

I populated the lookup tab by figuring out what numbers would make the two examples work. That was enough to make the real data work.

Quote from: Davef on 10 December, 2020, 09:42:00 am

I am not sure a solution that only works with a subset of the possibilities even if it happens to work for your data set is satisfactory.

I think they must deliberately generate the data to allow simpler approaches to work. Seems unnecessary to go beyond that.

It is just for fun after all.

I agree - but the fact there is a simple solution because of a quirk of the data - it would be nice if that quirk was guaranteed by the spec. It would only need one more sentence that would not really give much away.

Title: Re: Advent of Code
Post by: Davef on 11 December, 2020, 09:18:26 am

Quote from: Diver300 on 11 December, 2020, 08:00:01 am

Day 11 done.

I keep making the mistake of writing something like:-

Code: [Select]

} while ( done = 0 ) when I mean

Code: [Select]

} while ( done == 0 )

If you habitually write it as (0==done) then if you forget an = you get a compiler error . Personally I prefer (!done)

Title: Re: Advent of Code
Post by: Diver300 on 11 December, 2020, 09:40:13 am

Quote from: Davef on 11 December, 2020, 09:18:26 am

Quote from: Diver300 on 11 December, 2020, 08:00:01 am

Day 11 done.

I keep making the mistake of writing something like:-

Code: [Select]

} while ( done = 0 ) when I mean

Code: [Select]

} while ( done == 0 )

If you habitually write it as (0==done) then if you forget an = you get a compiler error . Personally I prefer (!done)

I'll try the (0==done) route.

Title: Re: Advent of Code
Post by: Davef on 11 December, 2020, 09:54:42 am

Quote from: Diver300 on 11 December, 2020, 09:40:13 am

Quote from: Davef on 11 December, 2020, 09:18:26 am

Quote from: Diver300 on 11 December, 2020, 08:00:01 am

Day 11 done.

I keep making the mistake of writing something like:-

Code: [Select]

} while ( done = 0 ) when I mean

Code: [Select]

} while ( done == 0 )

If you habitually write it as (0==done) then if you forget an = you get a compiler error . Personally I prefer (!done)

I'll try the (0==done) route.

As I read “!” as “not” .... while (!done) out loud is “while not done”

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2020, 10:06:39 am

Quote from: Davef on 11 December, 2020, 09:18:26 am

Quote from: Diver300 on 11 December, 2020, 08:00:01 am

Day 11 done.

I keep making the mistake of writing something like:-

Code: [Select]

} while ( done = 0 ) when I mean

Code: [Select]

} while ( done == 0 )

If you habitually write it as (0==done) then if you forget an = you get a compiler error . Personally I prefer (!done)

Personally I think "0 == done" looks ugly, I much prefer the "!done" option but if I have to check for a specific value I still write "done == 1256" rather than "1256 == done".

If you use the right compiler options you get a warning for

Code: [Select]

} while ( done = 0 ), plus a load of other warnings for things you probably need to fix too:-

Code: [Select]

$ cat x.c
int main(void)
{
        int x=0;
        do { } while( x = 0 );
}
$ gcc x.c -o x
$ gcc -ansi -pedantic -Wall x.c -o x
x.c: In function ‘main’:
x.c:4:2: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
x.c:5:1: warning: control reaches end of non-void function [-Wreturn-type]


Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2020, 01:32:14 pm

2020 day 11 done easily enough, but I haven't worked out the right trick to make it fast. (Bit busy with real work at the mo.)

Forgot the "cellular automata" item from the list of expected AoC challenges.

Title: Re: Advent of Code
Post by: grams on 11 December, 2020, 01:40:06 pm

Day 11 Part 1 is here. It takes about 20 minutes to recalculate 100 iterations, if it doesn't crash, and that's with hardcoding the cell references to make it easier*. I had a typo in my adjacent seat calculating formula that didn't cause a problem on the test data and had to redo all of it. Grrrr.

https://docs.google.com/spreadsheets/d/1QYtHllA3OYWupEnHUZmtXDV07zLlpniRcSfaBZpyDPg/edit?usp=sharing

(click to show/hide)

Not sure I can be arsed doing part 2. But it looks like you only have to calculate which 8 seats each seat cares about once, which should make it no slower than part 1.

(* will, if Google Sheets has a proper recalculations optimiser. I'm increasingly doubtful it does)

Title: Re: Advent of Code
Post by: Davef on 11 December, 2020, 01:40:31 pm

Perhaps it was a tribute the great John Conway who sadly died earlier this year.

Title: Re: Advent of Code
Post by: Greenbank on 11 December, 2020, 02:28:16 pm

All of the previous AoC years have had a similar puzzle at some point in them I think.

Some time next year I'm going to go through all of the years and reimplement them in a few different languages, I'll also take the time to classify them so I can see how common individual things come up.

I may even write a load of template code/functions[1] ready to have a go at getting on the top 100 leaderboard, however I don't think I can be arsed getting up and having my brain ready and switched on for 5am even for a few days let alone every day.

1. This is how the majority of the top 100 get such fast times. Preparation (based on guesswork and experience) and then knowing which template would be best used as a basis for each puzzle...

Title: Re: Advent of Code
Post by: tonycollinet on 11 December, 2020, 06:15:27 pm

Quote from: grams on 11 December, 2020, 01:40:06 pm

Day 11 Part 1 is here. It takes about 20 minutes to recalculate 100 iterations,

Really? - mine is taking about 5 seconds for 102 iterations of part one. Haven't got round to part 2 yet.

Title: Re: Advent of Code
Post by: grams on 11 December, 2020, 06:18:42 pm

Quote from: tonycollinet on 11 December, 2020, 06:15:27 pm

Really? - mine is taking about 5 seconds for 102 iterations of part one. Haven't got round to part 2 yet.

That's for a Google Sheet with two million cells running in a browser tab.

More efficient approaches are no doubt available.

Title: Re: Advent of Code
Post by: Davef on 11 December, 2020, 06:24:46 pm

Quote from: tonycollinet on 11 December, 2020, 06:15:27 pm

Quote from: grams on 11 December, 2020, 01:40:06 pm

Day 11 Part 1 is here. It takes about 20 minutes to recalculate 100 iterations,

Really? - mine is taking about 5 seconds for 102 iterations of part one. Haven't got round to part 2 yet.

63 trillion iterations of a 100,000 by 100,000 grid might take a while.

https://conwaylife.com/wiki/Pi_calculator

Title: Re: Advent of Code
Post by: grams on 11 December, 2020, 09:50:35 pm

OK, did day 11 part 2:
https://docs.google.com/spreadsheets/d/1mfMTK1UA9qBIduBxIRKw92QYtu95AZ6LUPiETdR_uZA/edit?usp=sharing

(click to show/hide)

Basically I'm making strings of the available seats in each of the 8 directions, searching for the first one in the string  and figuring out its offset in my array, which is easy to substitute into the same formulae from part1. The working out how to do it is trivial compared to waiting for it all to recalculate.

It's so slow now I used someone else's python code to verify I was getting the right answers, which made the whole thing extra pointless.

Title: Re: Advent of Code
Post by: tonycollinet on 12 December, 2020, 12:14:43 am

Quote from: grams on 11 December, 2020, 06:18:42 pm

Quote from: tonycollinet on 11 December, 2020, 06:15:27 pm

Really? - mine is taking about 5 seconds for 102 iterations of part one. Haven't got round to part 2 yet.

That's for a Google Sheet with two million cells running in a browser tab.

More efficient approaches are no doubt available.

Ah - fair enough.

Title: Re: Advent of Code
Post by: tonycollinet on 12 December, 2020, 08:33:24 am

So time constraints meant that I've only just completed day 11 p2.

(click to show/hide)

I used recursion again for the Part 2 scan along the line of sight. Really liking how it simplifies this sort of repetitive stuff.

I could also reduce code lines by combining P1 and P2 with a conditional section on part number, but can't be bothered. And for execution time, this way will be (marginally) faster anyway.
******************************
def TestSeatP1 (row, col):
    global seats
    num_col = len (seats

• )

    num_row = len (seats)

#set up matrix for valid test
    test_valid = [[row>0 and col>0,row>0, row>0 and col<num_col - 1],
                  [col>0,False,col<num_col-1],
                  [row<num_row-1 and col>0,row<num_row-1,col<num_col-1 and row<num_row-1]]
   
#examine surrounding seats
    count_occupied = 0
    for rs in range (3):
        for cs in range (3):
            if test_valid[rs][cs]:
                seat_val = seats[row+rs-1][col+cs-1]
                if seat_val == "#":
                    count_occupied += 1
   
    return (count_occupied)                   

def ScanP2 (row, col, rcnt, ccnt):
#set up matrix for valid test
    num_col = len (seats

• )

    num_row = len (seats)
    test_valid = [[row>0 and col>0,row>0, row>0 and col<num_col - 1],
                  [col>0,False,col<num_col-1],
                  [row<num_row-1 and col>0,row<num_row-1,col<num_col-1 and row<num_row-1]]
    if test_valid [rcnt][ccnt]:
        seat_val = seats[row+rcnt-1][col+ccnt-1]
        if seat_val == ".":
            return ScanP2 (row+rcnt-1,col+ccnt-1,rcnt, ccnt)
        else:
            return seat_val
    else:
        return "E"


def TestSeatP2 (row, col):
    global seats
    num_col = len (seats

• )

    num_row = len (seats)

#examine surrounding seats
    count_occupied = 0
    for rs in range (3):
        for cs in range (3):
            if ScanP2 (row, col, rs, cs) == "#":
                count_occupied += 1
   
    return (count_occupied)                   

# start get data
input_file = open("11Input.txt", "r")
#data = [(line.strip()).split() for line in input_file]
seats = [line.strip() for line in input_file]
input_file.close()

#take a copy for part 2
original_seats = seats.copy()

# part 1

changed = True
iterations = 0
seats_new = []
while changed:
    print ("part 1", iterations)
#     for index, row in enumerate (seats):
#         if index<10:
#             print (row)
    num_changes = 0
    num_occupied = 0
    seats_new = seats.copy()
   
   
    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            occupied = TestSeatP1 (row,col)
            if now == "#" and occupied >= 4:
                new = "L"
                num_changes+= 1
            elif now == "L" and occupied == 0:
                new = "#"
                num_changes += 1
            else:
                new = now
            seats_new [row] = seats_new[row][:col]+ new + seats_new [row][col+1:]


    seats = seats_new.copy()
   
   
    if num_changes == 0:
        changed = False
    else:
        iterations += 1

    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            if now == "#":num_occupied += 1
part1Ans = num_occupied
part1Iterations = iterations


# part 2
seats = original_seats.copy ()

changed = True
iterations = 0
seats_new = []
while changed:
    print ("part 2", iterations)
#     for index, row in enumerate (seats):
#         if index<10:
#             print (row)
    num_changes = 0
    num_occupied = 0
    seats_new = seats.copy()
   
   
    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            occupied = TestSeatP2 (row,col)
            if now == "#" and occupied >= 5:
                new = "L"
                num_changes+= 1
            elif now == "L" and occupied == 0:
                new = "#"
                num_changes += 1
            else:
                new = now
            seats_new [row] = seats_new[row][:col]+ new + seats_new [row][col+1:]


    seats = seats_new.copy()
   
   
    if num_changes == 0:
        changed = False
    else:
        iterations += 1

    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            if now == "#":num_occupied += 1
part2Ans = num_occupied
part2Iterations = iterations

print ("Part 1: No iterations ", part1Iterations,"Number occupied: ", part1Ans)
print ("Part 2: No iterations ", part2Iterations,"Number occupied: ", part2Ans)

Title: Advent of Code
Post by: Davef on 12 December, 2020, 11:02:53 am

Quote from: tonycollinet on 12 December, 2020, 08:33:24 am

So time constraints meant that I've only just completed day 11 p2.

(click to show/hide)

I used recursion again for the Part 2 scan along the line of sight. Really liking how it simplifies this sort of repetitive stuff.

I could also reduce code lines by combining P1 and P2 with a conditional section on part number, but can't be bothered. And for execution time, this way will be (marginally) faster anyway.
******************************
def TestSeatP1 (row, col):
    global seats
    num_col = len (seats

• )

    num_row = len (seats)

#set up matrix for valid test
    test_valid = [[row>0 and col>0,row>0, row>0 and col<num_col - 1],
                  [col>0,False,col<num_col-1],
                  [row<num_row-1 and col>0,row<num_row-1,col<num_col-1 and row<num_row-1]]
   
#examine surrounding seats
    count_occupied = 0
    for rs in range (3):
        for cs in range (3):
            if test_valid[rs][cs]:
                seat_val = seats[row+rs-1][col+cs-1]
                if seat_val == "#":
                    count_occupied += 1
   
    return (count_occupied)                   

def ScanP2 (row, col, rcnt, ccnt):
#set up matrix for valid test
    num_col = len (seats

• )

    num_row = len (seats)
    test_valid = [[row>0 and col>0,row>0, row>0 and col<num_col - 1],
                  [col>0,False,col<num_col-1],
                  [row<num_row-1 and col>0,row<num_row-1,col<num_col-1 and row<num_row-1]]
    if test_valid [rcnt][ccnt]:
        seat_val = seats[row+rcnt-1][col+ccnt-1]
        if seat_val == ".":
            return ScanP2 (row+rcnt-1,col+ccnt-1,rcnt, ccnt)
        else:
            return seat_val
    else:
        return "E"


def TestSeatP2 (row, col):
    global seats
    num_col = len (seats

• )

    num_row = len (seats)

#examine surrounding seats
    count_occupied = 0
    for rs in range (3):
        for cs in range (3):
            if ScanP2 (row, col, rs, cs) == "#":
                count_occupied += 1
   
    return (count_occupied)                   

# start get data
input_file = open("11Input.txt", "r")
#data = [(line.strip()).split() for line in input_file]
seats = [line.strip() for line in input_file]
input_file.close()

#take a copy for part 2
original_seats = seats.copy()

# part 1

changed = True
iterations = 0
seats_new = []
while changed:
    print ("part 1", iterations)
#     for index, row in enumerate (seats):
#         if index<10:
#             print (row)
    num_changes = 0
    num_occupied = 0
    seats_new = seats.copy()
   
   
    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            occupied = TestSeatP1 (row,col)
            if now == "#" and occupied >= 4:
                new = "L"
                num_changes+= 1
            elif now == "L" and occupied == 0:
                new = "#"
                num_changes += 1
            else:
                new = now
            seats_new [row] = seats_new[row][:col]+ new + seats_new [row][col+1:]


    seats = seats_new.copy()
   
   
    if num_changes == 0:
        changed = False
    else:
        iterations += 1

    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            if now == "#":num_occupied += 1
part1Ans = num_occupied
part1Iterations = iterations


# part 2
seats = original_seats.copy ()

changed = True
iterations = 0
seats_new = []
while changed:
    print ("part 2", iterations)
#     for index, row in enumerate (seats):
#         if index<10:
#             print (row)
    num_changes = 0
    num_occupied = 0
    seats_new = seats.copy()
   
   
    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            occupied = TestSeatP2 (row,col)
            if now == "#" and occupied >= 5:
                new = "L"
                num_changes+= 1
            elif now == "L" and occupied == 0:
                new = "#"
                num_changes += 1
            else:
                new = now
            seats_new [row] = seats_new[row][:col]+ new + seats_new [row][col+1:]


    seats = seats_new.copy()
   
   
    if num_changes == 0:
        changed = False
    else:
        iterations += 1

    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            if now == "#":num_occupied += 1
part2Ans = num_occupied
part2Iterations = iterations

print ("Part 1: No iterations ", part1Iterations,"Number occupied: ", part1Ans)
print ("Part 2: No iterations ", part2Iterations,"Number occupied: ", part2Ans)

All that typing takes a while.

(click to show/hide)

// count number ‘adjacent’ to x,y in each of 8 directions, unlimited distance
int countadjacent8x(const CSparse& a, int x0, int y0, int val, int w, int h)
{
int ret = 0;

for (int dx = -1; dx <= 1; dx++)
for (int dy = -1; dy <= 1; dy++)
{
if (!dx&&!dy) continue; // the 9th unwanted NULL direction

for (int x=x0+dx,y=y0+dy ; (x>=0)&&(y>=0)&&(x<=w)&&(y<=h) ; x+=dx,y+=dy) 
{
int c = a.get(x,y);

if (c==val) ret++; // found one
if (c) break; // hit something so on to next direction
}
}

return ret;
}

// produce next iteration from a into b, returns number of changes
int d11iterb(const CSparse& a, CSparse& b, int w, int h)
{
int ret = 0;

for (int x=0; x<=w; x++)
for (int y=0; y<=h;y++)
{
int c = a.get(x,y);

if (c)
{
int n = countadjacent8x(a,x,y,'#',w,h);
if (((c=='L')&&(n==0))||((c=='#')&&(n>=5)))
{
c =‘#’+’L'-c;  // toggle between # and L
ret++;
}

b.set(x,y,c);
}
}

return ret;
}

Title: Re: Advent of Code
Post by: grams on 12 December, 2020, 11:12:29 am

Day 12 is oddly simple:
https://docs.google.com/spreadsheets/d/1NyEKHBwBLrFNKyLmZ63jB8CxNB6vBg3_ci3R9WBDgPM/edit?usp=sharing

(click to show/hide)

Did finally find a use for matrix transformations we spent far too long on in school. "use" being relative here.

Title: Re: Advent of Code
Post by: Arellcat on 12 December, 2020, 11:21:28 am

Quote from: Afasoas on 11 December, 2015, 01:04:01 pm

Code: [Select]

user@cinelli ~ $ python -V
Python 2.7.6


Woah, slow down, Einstein.  ???

This may be why I am not a programmer, although I do like a good spreadsheet.

Title: Re: Advent of Code
Post by: Davef on 12 December, 2020, 12:42:18 pm

Quote from: grams on 12 December, 2020, 11:12:29 am

Day 12 is oddly simple:
https://docs.google.com/spreadsheets/d/1NyEKHBwBLrFNKyLmZ63jB8CxNB6vBg3_ci3R9WBDgPM/edit?usp=sharing

(click to show/hide)

Did finally find a use for matrix transformations we spent far too long on in school. "use" being relative here.

My terse version

(click to show/hide)

int x=0,y=0; // ship position
int v=10,w=1; // way point position

for (int i = 0; i < nn; i++)
{
const char *s = a;
char c = s[0];      // command
int d = atoi(s+1);  // amount

switch (c)
{
case 'N': w += d; break;
case 'E': v += d; break;
case 'W': v -= d; break;
case 'S': w -= d; break;
case 'F': x += v * d; y += w * d; break;
case 'L': d =  360-d;
case 'R': d /= 90; while (d--){w-=v;v+=w;w-=v;}
}

}
ret = abs(x)+abs(y);

Title: Re: Advent of Code
Post by: Diver300 on 12 December, 2020, 01:20:58 pm

Quote from: grams on 12 December, 2020, 11:12:29 am

Day 12 is oddly simple:
https://docs.google.com/spreadsheets/d/1NyEKHBwBLrFNKyLmZ63jB8CxNB6vBg3_ci3R9WBDgPM/edit?usp=sharing

(click to show/hide)

Did finally find a use for matrix transformations we spent far too long on in school. "use" being relative here.

I used a spreadsheet as well.

(click to show/hide)

I used sin and cos for the rotations, but I only ever used multiples of 90 degrees. The x and y components were separately multiplied by the H parameter

Title: Re: Advent of Code
Post by: grams on 12 December, 2020, 01:28:50 pm

Quote from: Davef on 12 December, 2020, 12:42:18 pm

snip

Tactical fallthrough. Nice.

Title: Advent of Code
Post by: Davef on 12 December, 2020, 02:37:02 pm

(click to show/hide)

Bizarre way of rotating clockwise by 90 degrees using 3 translations parallel to axes

(https://uploads.tapatalk-cdn.com/20201212/1a17545ed98cd225c1e180935a382c1f.jpg)

Or if you dislike infix
y = y - x
x = x + y
y = y - x

Title: Re: Advent of Code
Post by: Ben T on 12 December, 2020, 03:04:46 pm

Quote from: Greenbank on 11 December, 2020, 01:32:14 pm

2020 day 11 done easily enough, but I haven't worked out the right trick to make it fast. (Bit busy with real work at the mo.)

Forgot the "cellular automata" item from the list of expected AoC challenges.

Really? not sure how "fast" you want it, mine takes about a second although that's in debug and probably includes compilation, they all take that - so I think the actual calculation, if I produced a release binary it would probably be sub-second.

my code is distinctly 'pedestrian', but reasonably efficient enough

(click to show/hide)

Code: [Select]

    public class Day11
    {
        public static async Task Part1(string[] args)
        {
            var matrix = await Matrix.Parse(Console.In);

            int changes;
            do
            {
                matrix = Iterate(matrix, out changes);
            } while(changes > 0);

            await Console.Out.WriteLineAsync(matrix.Cells.Count(c => c.Value == '#').ToString());
        }

        public static async Task Part2(string[] args)
        {
            var matrix = await Matrix.Parse(Console.In);

            int changes;
            do
            {
                matrix = IteratePart2(matrix, out changes);
            } while(changes > 0);

            await Console.Out.WriteLineAsync(matrix.Cells.Count(c => c.Value == '#').ToString());
        }

        private static Matrix Iterate(Matrix m, out int changes)
        {
            changes = 0;
            var newMatrix = new Matrix(m);
            foreach(var c in m.Cells)
            {
                var adjacents = m.AdjacentsIncludingDiagonal(c.Key).ToArray();
                if(c.Value == 'L' && !adjacents.Any(a => m.Cells[a] == '#'))
                {
                    newMatrix.Cells[c.Key] = '#';
                    changes++;
                }
                else if(c.Value == '#' && adjacents.Count(a => m.Cells[a] == '#') >= 4)
                {
                    newMatrix.Cells[c.Key] = 'L';
                    changes++;
                }
            }
            return newMatrix;
        }

        private static Matrix IteratePart2(Matrix m, out int changes)
        {
            changes = 0;
            var newMatrix = new Matrix(m);
            foreach(var c in m.Cells)
            {
                var visible = m.SightlinesIncludingDiagonal(c.Key, '.');
                if(c.Value == 'L' && !visible.Any(a => m.Cells[a] == '#'))
                {
                    newMatrix.Cells[c.Key] = '#';
                    changes++;
                }
                else if(c.Value == '#' && visible.Count(a => m.Cells[a] == '#') >= 5)
                {
                    newMatrix.Cells[c.Key] = 'L';
                    changes++;
                }
            }
            return newMatrix;
        }
    }



where 'Matrix' is a reusable component in my generic library AoCTools:

Code: [Select]

    public class Matrix
    {
        public Matrix() {}

        public Matrix(Matrix matrixToClone)
        {
            Cells = matrixToClone.Cells.ToDictionary(x => x.Key, x => x.Value);
            Length = matrixToClone.Length;
            Height = matrixToClone.Height;
        }

        public readonly Dictionary<MatrixCoord, char> Cells = new Dictionary<MatrixCoord, char>();
        public int Length{get; private set;}
        public int Height{get;private set;}

        public static async Task<Matrix> Parse(TextReader reader)
        {
            var matrix = new Matrix();
            string line;
            int? lineLength = null;
            int y = 0;
            while(!string.IsNullOrEmpty(line = await reader.ReadLineAsync()))
            {
                if(lineLength.HasValue && line.Length != lineLength.Value) throw new InvalidOperationException("Mismatched line lengths");
                lineLength = line.Length;
                for(int x = 0; x < line.Length; x++)
                {
                    matrix.Cells.Add(new MatrixCoord(x, y), line[x]);
                }
                y++;
            }
            matrix.Length = lineLength.Value;
            matrix.Height = y;
            return matrix;
        }

        public IEnumerable<MatrixCoord> AdjacentsIncludingDiagonal(MatrixCoord coord)
        {
            for(int dx = -1; dx <= 1; dx++)
            {
                for(int dy = -1; dy <= 1; dy++)
                {
                    var ox = coord.X + dx;
                    var oy = coord.Y + dy;
                    if(dx == 0 && dy == 0) continue; // this one
                    if(ox < 0 || oy < 0 || ox >= Length || oy >= Height) continue; //out of bounds
                    yield return new MatrixCoord(ox, oy);
                }
            }
        }

        public IEnumerable<MatrixCoord> SightlinesIncludingDiagonal(MatrixCoord coord, char space)
        {
            for(int dx = -1; dx <= 1; dx++)
            {
                for(int dy = -1; dy <= 1; dy++)
                {
                    if(dx == 0 && dy == 0) continue; // this one
                    for(int m = 1;;m++)
                    {
                        var ox = coord.X + m*dx;
                        var oy = coord.Y + m*dy;
                        if(ox < 0 || oy < 0 || ox >= Length || oy >= Height) break; //out of bounds
                        var oc = new MatrixCoord(ox, oy);
                        if(Cells[oc] != space)
                        {
                            yield return oc;
                            break;
                        }
                    }
                }
            }
        }
    }

    public struct MatrixCoord
    {
        public MatrixCoord(int x, int y)
        {
            X = x;
            Y = y;
        }

        public int X{get;}
        public int Y{get;}

        public override bool Equals(object obj)
        {
            return obj is MatrixCoord coord &&
                   X == coord.X &&
                   Y == coord.Y;
        }

        public override int GetHashCode()
        {
            int hashCode = 1861411795;
            hashCode = hashCode * -1521134295 + X.GetHashCode();
            hashCode = hashCode * -1521134295 + Y.GetHashCode();
            return hashCode;
        }
    }


the "trick", which you've probably seen, I recognised it instantly from previous similar problems, is

(click to show/hide)

immutability, don't modify it in place but create a copy (it says in the instructions all transformations happen simultaneously)

Curious enough to see if you can do it in fewer clock cycles, even if you don't need to

Title: Re: Advent of Code
Post by: tonycollinet on 12 December, 2020, 04:00:41 pm

Quote from: Davef on 12 December, 2020, 11:02:53 am

Quote from: tonycollinet on 12 December, 2020, 08:33:24 am

So time constraints meant that I've only just completed day 11 p2.

(click to show/hide)

I used recursion again for the Part 2 scan along the line of sight. Really liking how it simplifies this sort of repetitive stuff.

I could also reduce code lines by combining P1 and P2 with a conditional section on part number, but can't be bothered. And for execution time, this way will be (marginally) faster anyway.
******************************
def TestSeatP1 (row, col):
    global seats
    num_col = len (seats

• )

    num_row = len (seats)

#set up matrix for valid test
    test_valid = [[row>0 and col>0,row>0, row>0 and col<num_col - 1],
                  [col>0,False,col<num_col-1],
                  [row<num_row-1 and col>0,row<num_row-1,col<num_col-1 and row<num_row-1]]
   
#examine surrounding seats
    count_occupied = 0
    for rs in range (3):
        for cs in range (3):
            if test_valid[rs][cs]:
                seat_val = seats[row+rs-1][col+cs-1]
                if seat_val == "#":
                    count_occupied += 1
   
    return (count_occupied)                   

def ScanP2 (row, col, rcnt, ccnt):
#set up matrix for valid test
    num_col = len (seats

• )

    num_row = len (seats)
    test_valid = [[row>0 and col>0,row>0, row>0 and col<num_col - 1],
                  [col>0,False,col<num_col-1],
                  [row<num_row-1 and col>0,row<num_row-1,col<num_col-1 and row<num_row-1]]
    if test_valid [rcnt][ccnt]:
        seat_val = seats[row+rcnt-1][col+ccnt-1]
        if seat_val == ".":
            return ScanP2 (row+rcnt-1,col+ccnt-1,rcnt, ccnt)
        else:
            return seat_val
    else:
        return "E"


def TestSeatP2 (row, col):
    global seats
    num_col = len (seats

• )

    num_row = len (seats)

#examine surrounding seats
    count_occupied = 0
    for rs in range (3):
        for cs in range (3):
            if ScanP2 (row, col, rs, cs) == "#":
                count_occupied += 1
   
    return (count_occupied)                   

# start get data
input_file = open("11Input.txt", "r")
#data = [(line.strip()).split() for line in input_file]
seats = [line.strip() for line in input_file]
input_file.close()

#take a copy for part 2
original_seats = seats.copy()

# part 1

changed = True
iterations = 0
seats_new = []
while changed:
    print ("part 1", iterations)
#     for index, row in enumerate (seats):
#         if index<10:
#             print (row)
    num_changes = 0
    num_occupied = 0
    seats_new = seats.copy()
   
   
    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            occupied = TestSeatP1 (row,col)
            if now == "#" and occupied >= 4:
                new = "L"
                num_changes+= 1
            elif now == "L" and occupied == 0:
                new = "#"
                num_changes += 1
            else:
                new = now
            seats_new [row] = seats_new[row][:col]+ new + seats_new [row][col+1:]


    seats = seats_new.copy()
   
   
    if num_changes == 0:
        changed = False
    else:
        iterations += 1

    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            if now == "#":num_occupied += 1
part1Ans = num_occupied
part1Iterations = iterations


# part 2
seats = original_seats.copy ()

changed = True
iterations = 0
seats_new = []
while changed:
    print ("part 2", iterations)
#     for index, row in enumerate (seats):
#         if index<10:
#             print (row)
    num_changes = 0
    num_occupied = 0
    seats_new = seats.copy()
   
   
    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            occupied = TestSeatP2 (row,col)
            if now == "#" and occupied >= 5:
                new = "L"
                num_changes+= 1
            elif now == "L" and occupied == 0:
                new = "#"
                num_changes += 1
            else:
                new = now
            seats_new [row] = seats_new[row][:col]+ new + seats_new [row][col+1:]


    seats = seats_new.copy()
   
   
    if num_changes == 0:
        changed = False
    else:
        iterations += 1

    for row in range (len (seats)):
        for col in range (len(seats[0])):
            now = seats [row][col]
            if now == "#":num_occupied += 1
part2Ans = num_occupied
part2Iterations = iterations

print ("Part 1: No iterations ", part1Iterations,"Number occupied: ", part1Ans)
print ("Part 2: No iterations ", part2Iterations,"Number occupied: ", part2Ans)

All that typing takes a while.

(click to show/hide)

// count number ‘adjacent’ to x,y in each of 8 directions, unlimited distance
int countadjacent8x(const CSparse& a, int x0, int y0, int val, int w, int h)
{
int ret = 0;

for (int dx = -1; dx <= 1; dx++)
for (int dy = -1; dy <= 1; dy++)
{
if (!dx&&!dy) continue; // the 9th unwanted NULL direction

for (int x=x0+dx,y=y0+dy ; (x>=0)&&(y>=0)&&(x<=w)&&(y<=h) ; x+=dx,y+=dy) 
{
int c = a.get(x,y);

if (c==val) ret++; // found one
if (c) break; // hit something so on to next direction
}
}

return ret;
}

// produce next iteration from a into b, returns number of changes
int d11iterb(const CSparse& a, CSparse& b, int w, int h)
{
int ret = 0;

for (int x=0; x<=w; x++)
for (int y=0; y<=h;y++)
{
int c = a.get(x,y);

if (c)
{
int n = countadjacent8x(a,x,y,'#',w,h);
if (((c=='L')&&(n==0))||((c=='#')&&(n>=5)))
{
c =‘#’+’L'-c;  // toggle between # and L
ret++;
}

b.set(x,y,c);
}
}

return ret;
}

(click to show/hide)

Alright, smartypants
To be fair - mine includes both parts. And the reading of input data. (I couldn't see that in yours - in fact I think I can only see two function definitions, but that might be just my lack of familiarity with C ).

....Oh, yes - and is built by a novice  ;D

Title: Re: Advent of Code
Post by: tonycollinet on 12 December, 2020, 04:19:20 pm

Day 12:
I provided for calculation of arbitrary turn angles - I'm hoping tomorrow will have similar with non 90 degree turns.  ;D

(click to show/hide)

import math

def sign(x):
    if x > 0:
        return 1.
    elif x < 0:
        return -1.
    elif x == 0:
        return 1.
    else:
        return x

def getHeadingDeg (n,e):
    quad = [sign (n), sign (e)]
    NE = [1,1]
    SE = [-1,1]
    SW = [-1,-1]
    NW = [1,-1]
   
    if n == 0:
        angle = 90
    else:
        angle = math.degrees(math.atan(abs(e)/abs(n)))
   
    if quad == NE: angle = angle
    elif quad == SE: angle = 180-angle
    elif quad == SW: angle = 180+angle
    elif quad == NW: angle = 360-angle
    return angle

# start get data
input_file = open("12Input.txt", "r")
#data = [(line.strip()).split() for line in input_file]
cmnds = [[line.strip()[:1],int(line.strip()[1:])] for line in input_file]
input_file.close()

# #part 1

heading = 90 #east
nPos = 0
ePos = 0

for cmd in cmnds:
    if cmd[ 0 ]=="N":
        nPos += cmd[1]
    elif cmd [ 0 ]=="S":
        nPos -= cmd[1]
    elif cmd [ 0 ]=="E":
        ePos += cmd[1]
    elif cmd [ 0 ]=="W":
        ePos -= cmd[1]
    elif cmd [ 0 ]=="L":
        heading -= cmd[1]
        if heading < 0:heading += 360
    elif cmd [ 0 ]=="R":
        heading += cmd [1]
        if heading >=360: heading -=360
    elif cmd [ 0 ]=="F":
        nPos += round(cmd [1] * math.cos(math.radians(heading)))
        ePos += round(cmd [1] * math.sin(math.radians(heading)))
       
print ("********************************")
print ("North ",nPos,"East", ePos, abs(nPos)+abs(ePos))
print ("********************************")
#part 2

nWay = 1
eWay = 10
nPos = 0
ePos = 0

for cmd in cmnds:
    if cmd[ 0 ]=="N":
        nWay += cmd[1]
    elif cmd [ 0 ]=="S":
        nWay -= cmd[1]
    elif cmd [ 0 ]=="E":
        eWay += cmd[1]
    elif cmd [ 0 ]=="W":
        eWay -= cmd[1]
    elif cmd [ 0 ]=="L":
        angWayDeg = getHeadingDeg (nWay, eWay)
        dstWay = math.sqrt(nWay ** 2 + eWay ** 2)
        angWayDeg -= cmd[1]
        nWay = round(dstWay * math.cos(math.radians(angWayDeg)))
        eWay = round(dstWay * math.sin(math.radians(angWayDeg)))
    elif cmd [ 0 ]=="R":
        angWayDeg = getHeadingDeg (nWay, eWay)
        dstWay = math.sqrt(nWay ** 2 + eWay ** 2)
        angWayDeg += cmd[1]
        nWay = round(dstWay * math.cos(math.radians(angWayDeg)))
        eWay = round(dstWay * math.sin(math.radians(angWayDeg)))

    elif cmd [ 0 ]=="F":
        nPos += cmd [1] * nWay
        ePos += cmd [1] * eWay
   
       
print ("********************************")
print ("North ",nPos,"East", ePos, abs(nPos)+abs(ePos))
print ("********************************")

Title: Re: Advent of Code
Post by: Ben T on 12 December, 2020, 04:48:42 pm

Quote from: tonycollinet on 12 December, 2020, 04:19:20 pm

Day 12:
I provided for calculation of arbitrary turn angles - I'm hoping tomorrow will have similar with non 90 degree turns.  ;D

The reason you know it won't have is because you (probably) won't end up with integer coordinates.
Problems usually only deal in integers, full stop. They (only very occasionally) use floating point numbers, but then it will be obvious it's a "floating points" question and it will be floating points throughout.
It's very rare to have one that's mainly integers, but you might sometimes have to round off.

Title: Re: Advent of Code
Post by: Davef on 12 December, 2020, 05:08:35 pm

Quote from: Ben T on 12 December, 2020, 03:04:46 pm

Quote from: Greenbank on 11 December, 2020, 01:32:14 pm

2020 day 11 done easily enough, but I haven't worked out the right trick to make it fast. (Bit busy with real work at the mo.)

Forgot the "cellular automata" item from the list of expected AoC challenges.

Really? not sure how "fast" you want it, mine takes about a seconds although that's in debug and probably includes compilation, they all take that - so I think the actual calculation, if I produced a release binary it would probably be sub-second.

my code is distinctly 'pedestrian', but reasonably efficient enough

(click to show/hide)

Code: [Select]

    public class Day11
    {
        public static async Task Part1(string[] args)
        {
            var matrix = await Matrix.Parse(Console.In);

            int changes;
            do
            {
                matrix = Iterate(matrix, out changes);
            } while(changes > 0);

            await Console.Out.WriteLineAsync(matrix.Cells.Count(c => c.Value == '#').ToString());
        }

        public static async Task Part2(string[] args)
        {
            var matrix = await Matrix.Parse(Console.In);

            int changes;
            do
            {
                matrix = IteratePart2(matrix, out changes);
            } while(changes > 0);

            await Console.Out.WriteLineAsync(matrix.Cells.Count(c => c.Value == '#').ToString());
        }

        private static Matrix Iterate(Matrix m, out int changes)
        {
            changes = 0;
            var newMatrix = new Matrix(m);
            foreach(var c in m.Cells)
            {
                var adjacents = m.AdjacentsIncludingDiagonal(c.Key).ToArray();
                if(c.Value == 'L' && !adjacents.Any(a => m.Cells[a] == '#'))
                {
                    newMatrix.Cells[c.Key] = '#';
                    changes++;
                }
                else if(c.Value == '#' && adjacents.Count(a => m.Cells[a] == '#') >= 4)
                {
                    newMatrix.Cells[c.Key] = 'L';
                    changes++;
                }
            }
            return newMatrix;
        }

        private static Matrix IteratePart2(Matrix m, out int changes)
        {
            changes = 0;
            var newMatrix = new Matrix(m);
            foreach(var c in m.Cells)
            {
                var visible = m.SightlinesIncludingDiagonal(c.Key, '.');
                if(c.Value == 'L' && !visible.Any(a => m.Cells[a] == '#'))
                {
                    newMatrix.Cells[c.Key] = '#';
                    changes++;
                }
                else if(c.Value == '#' && visible.Count(a => m.Cells[a] == '#') >= 5)
                {
                    newMatrix.Cells[c.Key] = 'L';
                    changes++;
                }
            }
            return newMatrix;
        }
    }



where 'Matrix' is a reusable component in my generic library AoCTools:

Code: [Select]

    public class Matrix
    {
        public Matrix() {}

        public Matrix(Matrix matrixToClone)
        {
            Cells = matrixToClone.Cells.ToDictionary(x => x.Key, x => x.Value);
            Length = matrixToClone.Length;
            Height = matrixToClone.Height;
        }

        public readonly Dictionary<MatrixCoord, char> Cells = new Dictionary<MatrixCoord, char>();
        public int Length{get; private set;}
        public int Height{get;private set;}

        public static async Task<Matrix> Parse(TextReader reader)
        {
            var matrix = new Matrix();
            string line;
            int? lineLength = null;
            int y = 0;
            while(!string.IsNullOrEmpty(line = await reader.ReadLineAsync()))
            {
                if(lineLength.HasValue && line.Length != lineLength.Value) throw new InvalidOperationException("Mismatched line lengths");
                lineLength = line.Length;
                for(int x = 0; x < line.Length; x++)
                {
                    matrix.Cells.Add(new MatrixCoord(x, y), line[x]);
                }
                y++;
            }
            matrix.Length = lineLength.Value;
            matrix.Height = y;
            return matrix;
        }

        public IEnumerable<MatrixCoord> AdjacentsIncludingDiagonal(MatrixCoord coord)
        {
            for(int dx = -1; dx <= 1; dx++)
            {
                for(int dy = -1; dy <= 1; dy++)
                {
                    var ox = coord.X + dx;
                    var oy = coord.Y + dy;
                    if(dx == 0 && dy == 0) continue; // this one
                    if(ox < 0 || oy < 0 || ox >= Length || oy >= Height) continue; //out of bounds
                    yield return new MatrixCoord(ox, oy);
                }
            }
        }

        public IEnumerable<MatrixCoord> SightlinesIncludingDiagonal(MatrixCoord coord, char space)
        {
            for(int dx = -1; dx <= 1; dx++)
            {
                for(int dy = -1; dy <= 1; dy++)
                {
                    if(dx == 0 && dy == 0) continue; // this one
                    for(int m = 1;;m++)
                    {
                        var ox = coord.X + m*dx;
                        var oy = coord.Y + m*dy;
                        if(ox < 0 || oy < 0 || ox >= Length || oy >= Height) break; //out of bounds
                        var oc = new MatrixCoord(ox, oy);
                        if(Cells[oc] != space)
                        {
                            yield return oc;
                            break;
                        }
                    }
                }
            }
        }
    }

    public struct MatrixCoord
    {
        public MatrixCoord(int x, int y)
        {
            X = x;
            Y = y;
        }

        public int X{get;}
        public int Y{get;}

        public override bool Equals(object obj)
        {
            return obj is MatrixCoord coord &&
                   X == coord.X &&
                   Y == coord.Y;
        }

        public override int GetHashCode()
        {
            int hashCode = 1861411795;
            hashCode = hashCode * -1521134295 + X.GetHashCode();
            hashCode = hashCode * -1521134295 + Y.GetHashCode();
            return hashCode;
        }
    }


the "trick", which you've probably seen, I recognised it instantly from previous similar problems, is

(click to show/hide)

immutability, don't modify it in place but create a copy (it says in the instructions all transformations happen simultaneously)

Curious enough to see if you can do it in fewer clock cycles, even if you don't need to

that is the way I am doing it (with the slight optimisation of discarding the dots from the matrix to reduce the number of elements ). It is not however an efficient way of solving the problem. You will need to get a slower computer to see the benefits.

Title: Re: Advent of Code
Post by: Greenbank on 12 December, 2020, 05:13:27 pm

Quote from: Ben T on 12 December, 2020, 04:48:42 pm

Quote from: tonycollinet on 12 December, 2020, 04:19:20 pm

Day 12:
I provided for calculation of arbitrary turn angles - I'm hoping tomorrow will have similar with non 90 degree turns.  ;D

The reason you know it won't have is because you (probably) won't end up with integer coordinates.
Problems usually only deal in integers, full stop. They (only very occasionally) use floating point numbers, but then it will be obvious it's a "floating points" question and it will be floating points throughout.
It's very rare to have one that's mainly integers, but you might sometimes have to round off.

Two variants then that would still be possible given care:-

a) Angles of 30, 45 or 60 degrees. You've then only got to also keep track of 1/2s, sqrt(2) and sqrt(3) as well as integers. The input would be chosen so that the end point (or answer) ends up on an integer set of co-ordinates
b) Movements along arbitrary angles that cancel out, e.g.

R47
F10
R90
F1
R90
F1
R90
F1
L90
F9
R133

Which (if I've got it right) should leave you in the initial state.

Title: Re: Advent of Code
Post by: Ben T on 12 December, 2020, 06:20:20 pm

Theoretically it would be possible for intermediate points to be floating point (or multiples of sqrt(2) etc) if he was being mean, but experience tells you he doesn't generally set questions where the description generally talks in integers, and the answer is an integer, but you are expected to have to deal with floating point numbers for intermediate points.

I may yet be proved wrong :)

My general strategy is make an assumption, and structure the code such that it throws an exception if the assumption is wrong.

Title: Advent of Code
Post by: Davef on 12 December, 2020, 06:52:02 pm

Different approach to day 11 part 2. Throws away the 2D grid and just keeps numbered seats ....

(click to show/hide)

int day11b(CSparse& a, int w, int h)
{
int ret = 0;

// go thru matrix and number the seats, starting at 1
int i = 1;
int nn = 0;
POSITION pos = a.GetStartPosition();
while (pos)
{
int x,y,v;
a.GetNextAssoc(pos,x,y,v);
if (v=='L')
{
nn++;
a.set(x,y,i);
i++;
}
}

int *state   = new int[nn+1]; // the state of each of the nn seats plus an extra at 0
int *net = new int[(nn+1)*8]; // the connectivity network - each seat depends on up to 8
int *changes   = new int[nn+1]; // the seats changed on this iteration
state[0] = 0;

// initialise neighbour network - just the once
for (int x0=0; x0<=w; x0++)
for (int y0=0; y0<=h;y0++)
{
int idx = a.get(x0,y0);
if (idx)
{
state[idx] = 0;

idx *= 8;     // e.g. 100..107

for (int dx = -1; dx <= 1; dx++)
for (int dy = -1; dy <= 1; dy++)
{
if (!dx&&!dy) continue; // the 9th unwanted NULL direction

int c = 0;
for (int x=x0+dx,y=y0+dy; !c&&(x>=0)&&(y>=0)&&(x<=w)&&(y<=h); x+=dx,y+=dy) 
c=a.get(x,y);
net[idx++] = c;
}
}
}

    // phew, all set up, lets start iterating
for (int iter = 0;;iter++)
{
int changeidx = 0;
int occupied = 0;

// for each seat
for (int i = 1; i <= nn; i++)
{
// count neighbours
int n = 0;
for (int j = 0; j < 8; j++)
n += state[net[i*8+j]];

int c = state;
occupied += c;
if ((!c&&(n==0))||(c&&(n>=5)))
changes[changeidx++] = i;
}

// apply the changes
for (i = 0; i < changeidx; i++)
state[changes] ^= 1; // toggle between # and L

if (!changeidx) return occupied;
}

return ret;
}

This reduces the work in each iteration dramatically

Title: Re: Advent of Code
Post by: Croft on 12 December, 2020, 06:58:39 pm

Quote from: tonycollinet on 12 December, 2020, 04:19:20 pm

Day 12:
I provided for calculation of arbitrary turn angles - I'm hoping tomorrow will have similar with non 90 degree turns.  ;D

(click to show/hide)

Top tip: If you're going for the floating point trig approach, you can use atan2 rather than atan and having to handle quadrants.

Also, should you ever need a sign(x) function in Python, you can use math.copysign(1,x)

Title: Re: Advent of Code
Post by: Croft on 12 December, 2020, 07:06:53 pm

Quote from: Greenbank on 12 December, 2020, 05:13:27 pm

Two variants then that would still be possible given care:-

a) Angles of 30, 45 or 60 degrees. You've then only got to also keep track of 1/2s, sqrt(2) and sqrt(3) as well as integers. The input would be chosen so that the end point (or answer) ends up on an integer set of co-ordinates
b) Movements along arbitrary angles that cancel out, e.g.

R47
F10
R90
F1
R90
F1
R90
F1
L90
F9
R133

Which (if I've got it right) should leave you in the initial state.

I wonder if there might be an integer approach for arbitrary integer angles using taxicab geometry. http://sites.science.oregonstate.edu/~tevian/physics/taxicab/taxicab.pdf (http://sites.science.oregonstate.edu/~tevian/physics/taxicab/taxicab.pdf)

You can define trig functions in Manhattan space using modulo arithmetic, which I think would give you a pretty good degree of precision when scaled by a large integer. But your mathematical intuition is much better than mine, so perhaps you'd have a stronger idea as to whether this would be possible.

Title: Re: Advent of Code
Post by: tonycollinet on 12 December, 2020, 08:30:12 pm

Quote from: Croft on 12 December, 2020, 06:58:39 pm

Quote from: tonycollinet on 12 December, 2020, 04:19:20 pm

Day 12:
I provided for calculation of arbitrary turn angles - I'm hoping tomorrow will have similar with non 90 degree turns.  ;D

(click to show/hide)

Top tip: If you're going for the floating point trig approach, you can use atan2 rather than atan and having to handle quadrants.

Also, should you ever need a sign(x) function in Python, you can use math.copysign(1,x)

Will look at those - thanks.

Title: Re: Advent of Code
Post by: grams on 12 December, 2020, 08:44:06 pm

Quote from: Croft on 12 December, 2020, 06:58:39 pm

(click to show/hide)

Top tip: If you're going for the floating point trig approach, you can use atan2 rather than atan and having to handle quadrants.

Also, should you ever need a sign(x) function in Python, you can use math.copysign(1,x)

(click to show/hide)

You can jump directly to the new x and y using the rotation matrix (https://en.wikipedia.org/wiki/Rotation_matrix) formula. No dicking about calculating intermediate distances or angles.

Title: Re: Advent of Code
Post by: Diver300 on 13 December, 2020, 08:13:20 am

Day 13 is more about maths than programming

(click to show/hide)

I used a really crude spreadsheet to find a way of combining the input data.
ID13 with and offset of 1 combined with ID59 with and offset of 4 can be combined and considered to be a single bus with ID 767 with offset of 417.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2020, 09:38:04 am

(click to show/hide)

Indeed, there's a name for it that should make it easier to look up and implement:-

(click to show/hide)

Chinese Remainder Theorem
And a further spoiler would be:

(click to show/hide)

There's no need to implement LCM (Least Common Multiple) as each of the bus numbers are prime so the lcm of any pair is just their product

I had the CRT algorithm from 2017 day 13 so it was just a quick copy of that.

The only real work remaining was building the individual relations properly before combining them.

Title: Re: Advent of Code
Post by: grams on 13 December, 2020, 11:30:01 am

Are they trying to make me learn things? Fuck that.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2020, 12:53:51 pm

Yep, and so this will be one of the first days with a big drop off between 1 star and 2 stars.

As I said on our internal company #advent-of-code Slack channel, today's problem is firmly over to the right of this scale:-

<------ "Programming" ----------------- "Computer Science" ---------------- "Discrete Mathematics" ------>

There's usually a good 2 or 3 each year that require something not usually covered in general "programming" or "Comp Sci".

Ob-xkcd:-

(https://imgs.xkcd.com/comics/purity.png)

Title: Advent of Code
Post by: Davef on 13 December, 2020, 12:54:07 pm

Day 13 part 2, keeping to my terse programming, 1 loop, 1ish lines, no function calls, no Chinese takeaways.

(click to show/hide)

// _a[] is array of nn ints with x replaced with 1
// const int x=1;
// int _a[] = {67,7,x,59,61};
// int *a = _a;
// int nn=5;

__int64 t = 1;
__int64 s = 1;

for (int c = 0; c < nn; )
{ t+=(*a==1)?0:s;s*=((t+c)%*a)?1: (c++,*a++) ; }

return t;

I seem to have smileys. How to I get rid ?

This is quite efficient. For my part 2 data it loops 1000 times which is microseconds.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2020, 12:56:18 pm

Quote from: Davef on 13 December, 2020, 12:54:07 pm

I seem to have smileys. How to I get rid ?

Modify the post, expand the "Additional Options" box below it, check the "Don't use smileys" checkbox.

Title: Re: Advent of Code
Post by: Davef on 13 December, 2020, 01:01:19 pm

Quote from: Greenbank on 13 December, 2020, 12:56:18 pm

Quote from: Davef on 13 December, 2020, 12:54:07 pm

I seem to have smileys. How to I get rid ?

Modify the post, expand the "Additional Options" box below it, check the "Don't use smileys" checkbox.

I don’t seem to have those options. I put some spaces in. Is there some [] tags you can use? Even with the extra spaces I feel I am within the 80 character limit so I can keep the source code on one punch card.

Title: Re: Advent of Code
Post by: Croft on 13 December, 2020, 01:41:12 pm

Quote from: Greenbank on 13 December, 2020, 12:53:51 pm

Yep, and so this will be one of the first days with a big drop off between 1 star and 2 stars.

As I said on our internal company #advent-of-code Slack channel, today's problem is firmly over to the right of this scale:-

<------ "Programming" ----------------- "Computer Science" ---------------- "Discrete Mathematics" ------>

There's usually a good 2 or 3 each year that require something not usually covered in general "programming" or "Comp Sci".

Not sure I agree. It doesn’t require knowledge of that theorem and is quite computable with a fairly simple approach. Davef’s is a nice example of that.

We often see a similar pattern develop around the mid and later puzzles. The fastest and most experienced people spot a theory or solution from computer science or maths, share their observations on reddit. Others struggle for a bit, consult reddit, see lots of discussion on theorem X, and assume it is required for solution.

Eric is quite careful not to require such knowledge to derive a solution, even if it can help. We saw similar last year with the Slam Shuffle (day 22) that did allow solutions without detailed knowledge of modular arithmetic, even if it made spotting a solution easier.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2020, 01:42:30 pm

Quote from: Davef on 13 December, 2020, 01:01:19 pm

I don’t seem to have those options. I put some spaces in. Is there some [] tags you can use? Even with the extra spaces I feel I am within the 80 character limit so I can keep the source code on one punch card.

Are you using a browser to view the forum or something like Tapatalk?

You should be able to avoid it using code tags I guess.

Code: [Select]

Does this appear as a smiley? 8)


Title: Advent of Code
Post by: Davef on 13 December, 2020, 01:57:45 pm

If anyone is interested in how my simple solution to 13 day 2 works ...

(click to show/hide)

The basic problem is to find a (very large) number that satisfies some rule.

Suppose your numbers are 17 67 231 ...

The initial approach is to start at 1 and keep trying with increments of 1

After 17 attempts you find the number 17 which satisfies your first requirement (but unfortunately no others). You could carry on looking one at a time for something that matches the first and second requirement, but you can skip some as you quickly realise only every 17th number will satisfy criteria 1, so you can change your step size to 17 and carry on until you find an answer that satisfies 17 and 67. At this point you can increase your step size to 17x67 and when you find the next 17x67x231

You are soon leaping through the numbers skipping billions at a time.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2020, 02:11:20 pm

Quote from: Croft on 13 December, 2020, 01:41:12 pm

Quote from: Greenbank on 13 December, 2020, 12:53:51 pm

Yep, and so this will be one of the first days with a big drop off between 1 star and 2 stars.

As I said on our internal company #advent-of-code Slack channel, today's problem is firmly over to the right of this scale:-

<------ "Programming" ----------------- "Computer Science" ---------------- "Discrete Mathematics" ------>

There's usually a good 2 or 3 each year that require something not usually covered in general "programming" or "Comp Sci".

Not sure I agree. It doesn’t require knowledge of that theorem and is quite computable with a fairly simple approach. Davef’s is a nice example of that.

We often see a similar pattern develop around the mid and later puzzles. The fastest and most experienced people spot a theory or solution from computer science or maths, share their observations on reddit. Others struggle for a bit, consult reddit, see lots of discussion on theorem X, and assume it is required for solution.

Eric is quite careful not to require such knowledge to derive a solution, even if it can help. We saw similar last year with the Slam Shuffle (day 22) that did allow solutions without detailed knowledge of modular arithmetic, even if it made spotting a solution easier.

Sure, but my point is that in pretty much every case the solutions that people come up with (like Davef's above) are just implementing simple (and/or non-optimal) cases of the underlying theorem.

(click to show/hide)

Such an algorithm wouldn't be guaranteed to return the lowest possible answer if not all of the bus numbers were pairwise co-prime. (Eric has obviously chosen the bus numbers to be primes in everyone's input so that it is much easier.)

If you want to just get the two stars on each day and stop then that's fine, but you're missing out on learning something extra (which is one of the other goals of Eric's puzzles). It's entirely optional though.

For example, Davef's solution may complete part 2 in ~1000 iterations (rather than trillions), but it's possible to get the answer in a lot fewer iterations than that.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2020, 02:32:53 pm

Quote from: Davef on 13 December, 2020, 01:57:45 pm

If anyone is interested in how my simple solution to 13 day 2 works ...

(click to show/hide)

The basic problem is to find a (very large) number that satisfies some rule.

Suppose your numbers are 17 67 231 ...

The initial approach is to start at 1 and keep trying with increments of 1

After 17 attempts you find the number 17 which satisfies your first requirement (but unfortunately no others). You could carry on looking one at a time for something that matches the first and second requirement, but you can skip some as you quickly realise only every 17th number will satisfy criteria 1, so you can change your step size to 17 and carry on until you find an answer that satisfies 17 and 67. At this point you can increase your step size to 17x67 and when you find the next 17x67x231

You are soon leaping through the numbers skipping billions at a time.

(click to show/hide)

I think the differences I'm talking about are easily summed up by how people's code would handle a seemingly simple input that's designed to be difficult for solutions that don't use the ideal underlying algorithm/theorem. For example, how does your code handle this pathological input:-

3,1000000000000037

You can see that trying to find a solution for the 1000000000000037 bus by counting up 3 at a time is not going to be computeable in a reasonable timeframe.

The more people attempt to 'optimise' it by going "ah, but with big values like this I can see that I can spot that and skip a whole bunch of values in one go and make it much faster" the more they are actually working their way towards the "proper" generalised algorithm/theorem that works in an optimal manner in all cases.

Title: Advent of Code
Post by: Davef on 13 December, 2020, 02:37:41 pm

Quote from: Greenbank on 13 December, 2020, 02:32:53 pm

Quote from: Davef on 13 December, 2020, 01:57:45 pm

If anyone is interested in how my simple solution to 13 day 2 works ...

(click to show/hide)

The basic problem is to find a (very large) number that satisfies some rule.

Suppose your numbers are 17 67 231 ...

The initial approach is to start at 1 and keep trying with increments of 1

After 17 attempts you find the number 17 which satisfies your first requirement (but unfortunately no others). You could carry on looking one at a time for something that matches the first and second requirement, but you can skip some as you quickly realise only every 17th number will satisfy criteria 1, so you can change your step size to 17 and carry on until you find an answer that satisfies 17 and 67. At this point you can increase your step size to 17x67 and when you find the next 17x67x231

You are soon leaping through the numbers skipping billions at a time.

(click to show/hide)

I think the differences I'm talking about are easily summed up by how people's code would handle a seemingly simple input that's designed to be difficult for solutions that don't use the ideal underlying algorithm/theorem. For example, how does your code handle this pathalogical input:-

3,1000000000000037

You can see that trying to find a solution for the 1000000000000037 bus by counting up 3 at a time is not going to be computeable in a reasonable timeframe.

The version I initially wrote sorted the numbers and worked largest first. It made little difference on the sample so I posted a simplified version.

Longer version with presorting (should start with step=a[0] too)

(click to show/hide)

int *idx = new int[nn];
        int nz = 0;

for (i = 0; i < nn; i++)
idx = i;

c_idx = a;
 qsort(idx, nn, sizeof(int), comp13);

for (i = 0; i < nn; i++)
{
if (!a[idx]) break;
DoLogF("%d", idx);
}

nn = i;

DoLogF("nn reduced to %d", i);

// start with the largest
__int64 t = 1;
__int64 step = 1;

int found = 0;
for (; found < nn; )
{
t += step;
int ii = idx[found];
int id = a[idx[found]];
if (((t+ii)%id)==0) { found++; step *= id; }
}

Title: Re: Advent of Code
Post by: Croft on 13 December, 2020, 02:43:08 pm

Quote from: Greenbank on 13 December, 2020, 02:11:20 pm

Sure, but my point is that in pretty much every case the solutions that people come up with (like Davef's above) are just implementing simple (and/or non-optimal) cases of the underlying theorem.

I agree, which is what I really like about AoC. It is possible to get those gold stars (and so not necessarily a drop-off in puzzle competitions), but the process encourages us to find out more. What better way for to introduce Theorem X by inviting us to 'discover' it via our own implementation that uses a (possibly compromised) version of it? This is pretty much the gold standard in teaching - "create" is better than "discover" is better than "show" is better than "tell".

This year's so far has been better than most in that respect. Few have been hard in the sense of preventing casual programmers from finding a solution, but many have invited further thought on ways of refining / generalising.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2020, 02:50:57 pm

Quote from: Davef on 13 December, 2020, 02:37:41 pm

The version I initially wrote sorted the numbers and worked largest first. It made little difference on the sample so I posted a simplified version.

Sure, but I wrote that particular pathological case specifically for the version of the algorithm you posted.

I know your algorithm would work (and be much quicker than most) for all of the example inputs within AoC but, as I've said before, I'm talking about people choosing to use AoC to learn how to solve the general case and not just get the two stars each day before moving on.

If you provided an algorithm that worked largest case first I can provide a different pathological case that will attempt to maximise runtime for that version of the algorithm.

For most problems this back and forth can be repeated again and again until the program tends to be an implementation of the optimal algorithm.

You should try the https://onlinejudge.org/ coding puzzles. The difference between AoC and those is that with the OnlineJudge ones you don't get to see the final input your program is tested against, you submit your code (in whatever language you want) for that one. The examples that are given are all quite simplistic and the input your program is actually tested on is specifically crafted to stretch the designs of most programs to the limit. It's much harder when anything less than an optimal solution just comes back with "Time exceeded, execution aborted" each time.

Title: Re: Advent of Code
Post by: Croft on 13 December, 2020, 02:57:43 pm

Quote from: Greenbank on 13 December, 2020, 02:11:20 pm

(click to show/hide)

Such an algorithm wouldn't be guaranteed to return the lowest possible answer if not all of the bus numbers were pairwise co-prime.

(click to show/hide)

Maybe I'm missing something, but surely if the bus numbers are not pairwise co-prime, there is no solution regardless of algorithm (e.g. {5,10} will never arrive a minute apart).

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2020, 03:15:45 pm

Quote from: Croft on 13 December, 2020, 02:57:43 pm

Quote from: Greenbank on 13 December, 2020, 02:11:20 pm

(click to show/hide)

Such an algorithm wouldn't be guaranteed to return the lowest possible answer if not all of the bus numbers were pairwise co-prime.

(click to show/hide)

Maybe I'm missing something, but surely if the bus numbers are not pairwise co-prime, there is no solution regardless of algorithm (e.g. {5,10} will never arrive a minute apart).

(click to show/hide)

Correct that there can't be a solution to {5,10} but what about:-

5,x,x,x,x,10

?

(I think I've got the right amount of x's for it to have a solution)

Title: Re: Advent of Code
Post by: Croft on 13 December, 2020, 03:19:51 pm

Ah, yes of course ^.

That kind of sloppy thinking on my part is why I'll never be any good at those blind coding challenges.

Title: Re: Advent of Code
Post by: grams on 13 December, 2020, 04:25:57 pm

Day 13:
https://docs.google.com/spreadsheets/d/1AqziDqaSP6ThPImbihOYHoUNlIHToVUPxhCX_A_a2ks/edit?usp=sharing

(click to show/hide)

I could sort of see the pattern but couldn't get it straight in my head until I read Davef's comment about skipping billions at a time.

It worked on all the test samples but got stuck on the real data. I spent ages thinking I'd run into a floating point rounding error in google sheets, or maybe it needed thousands of iterations.

But running Davef's C code* against mine I discovered that reusing the "next bus" approach from Part 1 (rounding up using CEILING()) wasn't working when it was the third bus that matched the pattern (bus 17 in 40 minutes). I changed that to a MOD(), which almost worked but it turns out the MOD function has an artificial limit, so I had to roll my own. I finally got the right answer.

(* btw int nn=sizeof(_a)/sizeof(int); makes putting in test data much easier)

And I haven't learnt anything new about primes.

Title: Re: Advent of Code
Post by: tonycollinet on 13 December, 2020, 05:17:42 pm

Well Day13 stretched my capability to logic to it's limit. My head now officially hurts. I'm in the camp of no comp_sci training, and weak engineering maths so just have to puzzle it out. ;D

Pleased I didn't look at spoilers though.

(click to show/hide)

import math

def CalcLcm(a, b):
    return abs(a*b) // math.gcd(a, b)
# start get data
input_file = open("13Input.txt", "r")
data = [(line.strip()).split(",") for line in input_file]
input_file.close()

depart = int(data[0][0])
busses = data [1]

max = depart
min = [0,max]
int_busses = []
for bus in busses:
    if bus != "x":
        wait = int(bus)-depart % int(bus)
    if wait < min [1]: min = [ int(bus), wait]
    if bus !="x": print (bus, wait, min)
print ("Answer P1 ", min[0]*min[1])

#part 2
tstamps = []

for index, bus in enumerate(busses):
    if index > 0:
        if bus!="x":tstamps.append([int(bus), index])
tmp = [[int(busses[0]),0]]
tstamps.sort()
tstamps = tmp + tstamps
print (tstamps)
lcm = tstamps [0 ][0 ]
answer = tstamps [0 ][1 ]

for bus in tstamps[1:]:
    notfound = True
    while notfound:
        answer += lcm
        need_remain = bus[0 ] - bus[1]%bus[0 ]
        if (answer+lcm) % bus[0 ] == need_remain:
            answer+= lcm
            notfound = False
            lcm = CalcLcm (lcm, bus[0 ])
    print (answer, answer% tstamps [0 ][0 ], answer//bus[0 ]*bus[0 ], answer%bus[0 ], bus[1])

Title: Re: Advent of Code
Post by: tonycollinet on 13 December, 2020, 05:44:04 pm

Lots of talk about theorems above, and now I've completed would be interested to learn more. Can anyone point out what theorem is applicable to day 13, and ideally a link to a primer of some sort.

Ta.

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2020, 06:28:27 pm

Quote from: tonycollinet on 13 December, 2020, 05:44:04 pm

Lots of talk about theorems above, and now I've completed would be interested to learn more. Can anyone point out what theorem is applicable to day 13, and ideally a link to a primer of some sort.

It's in this post: https://yacf.co.uk/forum/index.php?topic=94710.msg2568783#msg2568783

Title: Re: Advent of Code
Post by: Ben T on 13 December, 2020, 06:54:53 pm

Quote from: Greenbank on 13 December, 2020, 02:32:53 pm

Quote from: Davef on 13 December, 2020, 01:57:45 pm

If anyone is interested in how my simple solution to 13 day 2 works ...

(click to show/hide)

The basic problem is to find a (very large) number that satisfies some rule.

Suppose your numbers are 17 67 231 ...

The initial approach is to start at 1 and keep trying with increments of 1

After 17 attempts you find the number 17 which satisfies your first requirement (but unfortunately no others). You could carry on looking one at a time for something that matches the first and second requirement, but you can skip some as you quickly realise only every 17th number will satisfy criteria 1, so you can change your step size to 17 and carry on until you find an answer that satisfies 17 and 67. At this point you can increase your step size to 17x67 and when you find the next 17x67x231

You are soon leaping through the numbers skipping billions at a time.

(click to show/hide)

I think the differences I'm talking about are easily summed up by how people's code would handle a seemingly simple input that's designed to be difficult for solutions that don't use the ideal underlying algorithm/theorem. For example, how does your code handle this pathological input:-

3,1000000000000037

You can see that trying to find a solution for the 1000000000000037 bus by counting up 3 at a time is not going to be computeable in a reasonable timeframe.

The more people attempt to 'optimise' it by going "ah, but with big values like this I can see that I can spot that and skip a whole bunch of values in one go and make it much faster" the more they are actually working their way towards the "proper" generalised algorithm/theorem that works in an optimal manner in all cases.

(click to show/hide)

You can actually evaluate the buses in descending order so in this case you would start off by skipping 1000000000000037 first

Title: Re: Advent of Code
Post by: tonycollinet on 13 December, 2020, 07:00:39 pm

Quote from: Greenbank on 13 December, 2020, 06:28:27 pm

Quote from: tonycollinet on 13 December, 2020, 05:44:04 pm

Lots of talk about theorems above, and now I've completed would be interested to learn more. Can anyone point out what theorem is applicable to day 13, and ideally a link to a primer of some sort.

It's in this post: https://yacf.co.uk/forum/index.php?topic=94710.msg2568783#msg2568783

Thanks - missed that in the nested spoilers :-)

Title: Re: Advent of Code
Post by: Davef on 13 December, 2020, 07:05:55 pm

Quote from: Ben T on 13 December, 2020, 06:54:53 pm

Quote from: Greenbank on 13 December, 2020, 02:32:53 pm

Quote from: Davef on 13 December, 2020, 01:57:45 pm

If anyone is interested in how my simple solution to 13 day 2 works ...

(click to show/hide)

The basic problem is to find a (very large) number that satisfies some rule.

Suppose your numbers are 17 67 231 ...

The initial approach is to start at 1 and keep trying with increments of 1

After 17 attempts you find the number 17 which satisfies your first requirement (but unfortunately no others). You could carry on looking one at a time for something that matches the first and second requirement, but you can skip some as you quickly realise only every 17th number will satisfy criteria 1, so you can change your step size to 17 and carry on until you find an answer that satisfies 17 and 67. At this point you can increase your step size to 17x67 and when you find the next 17x67x231

You are soon leaping through the numbers skipping billions at a time.

(click to show/hide)

I think the differences I'm talking about are easily summed up by how people's code would handle a seemingly simple input that's designed to be difficult for solutions that don't use the ideal underlying algorithm/theorem. For example, how does your code handle this pathological input:-

3,1000000000000037

You can see that trying to find a solution for the 1000000000000037 bus by counting up 3 at a time is not going to be computeable in a reasonable timeframe.

The more people attempt to 'optimise' it by going "ah, but with big values like this I can see that I can spot that and skip a whole bunch of values in one go and make it much faster" the more they are actually working their way towards the "proper" generalised algorithm/theorem that works in an optimal manner in all cases.

(click to show/hide)

You can actually evaluate the buses in descending order so in this case you would start off by skipping 1000000000000037 first

I did actually a version that sorted first but I stripped it out to get my solution down to 80 characters.

Title: Re: Advent of Code
Post by: tonycollinet on 13 December, 2020, 08:05:22 pm

Realising (now) that lowest common multiplier wasn't actually needed in day 13 - still a question that came up:

Is it true that LCM (a,b,c,d...)

Is equal to

LCM(d,LCM(c,LCM(b,a)))

?? (Assuming I've got the brackets in the correct places  ;D )

Title: Re: Advent of Code
Post by: Croft on 13 December, 2020, 08:34:59 pm

Yes.

Informally, because you can calculate LCM by finding the maximum prime factor exponent of each number and max more obviously satisfies the same property: max (a,b,c) = max (a, max(b,c))

Title: Advent of Code
Post by: Davef on 14 December, 2020, 08:29:43 am

Or that the lcm of a set of numbers is their product divided by their gcd. I find it easier to visualise the gcd in a  mental venn diagram of prime factors. It is fundamental that set intersection works this way from the colouring in I did at school.

Title: Re: Advent of Code
Post by: Davef on 14 December, 2020, 09:42:16 am

Quote from: Greenbank on 13 December, 2020, 03:15:45 pm

Quote from: Croft on 13 December, 2020, 02:57:43 pm

Quote from: Greenbank on 13 December, 2020, 02:11:20 pm

(click to show/hide)

Such an algorithm wouldn't be guaranteed to return the lowest possible answer if not all of the bus numbers were pairwise co-prime.

(click to show/hide)

Maybe I'm missing something, but surely if the bus numbers are not pairwise co-prime, there is no solution regardless of algorithm (e.g. {5,10} will never arrive a minute apart).

(click to show/hide)

Correct that there can't be a solution to {5,10} but what about:-

5,x,x,x,x,10

?

(I think I've got the right amount of x's for it to have a solution)

Doesn’t your favourite theorem require the bus numbers to be relatively prime too ?

Title: Re: Advent of Code
Post by: Greenbank on 14 December, 2020, 12:43:53 pm

Quote from: Davef on 14 December, 2020, 09:42:16 am

Doesn’t your favourite theorem require the bus numbers to be relatively prime too ?

The basic one yes, but the more generalised version works on non-co-prime moduli too.

Title: Re: Advent of Code
Post by: Ben T on 14 December, 2020, 02:15:42 pm

I think day 14 part 2's badly explained, I don't even get what the program's meant to be doing.

Quote

After applying the mask, four bits are overwritten, three of which are different, and two of which are floating. Floating bits take on every possible combination of values; with two floating bits, four actual memory addresses are written:

000000000000000000000000000000011010  (decimal 26)
000000000000000000000000000000011011  (decimal 27)
000000000000000000000000000000111010  (decimal 58)
000000000000000000000000000000111011  (decimal 59)
Next, the program is about to write to memory address 26 with a different bitmask:

address: 000000000000000000000000000000011010  (decimal 26)
mask:    00000000000000000000000000000000X0XX
result:  00000000000000000000000000000001X0XX
This results in an address with three floating bits, causing writes to eight memory addresses:

000000000000000000000000000000010000  (decimal 16)
000000000000000000000000000000010001  (decimal 17)
000000000000000000000000000000010010  (decimal 18)
000000000000000000000000000000010011  (decimal 19)
000000000000000000000000000000011000  (decimal 24)
000000000000000000000000000000011001  (decimal 25)
000000000000000000000000000000011010  (decimal 26)
000000000000000000000000000000011011  (decimal 27)

The entire 36-bit address space still begins initialized to the value 0 at every address, and you still need the sum of all values left in memory at the end of the program. In this example, the sum is 208.

"four actual memory addresses are written"... written with what?
"In this example, the sum is 208".... which of the above values sum to 208?

They seem to sum to 342 to me. Even if you only count each one once (26 and 27 are twice), they sum to 289.

How does he get 208?

???

Title: Re: Advent of Code
Post by: grams on 14 December, 2020, 02:28:18 pm

Quote

mask = 000000000000000000000000000000X1001X
mem[42] = 100
mask = 00000000000000000000000000000000X0XX
mem[26] = 1

The first command writes "100" to 4 different addresses. The second command writes "1" to 8 addresses, 2 of which overwrite the 100s. Therefore what's left is 2*100+8*1.

I can't see a sensible way of implementing it with a spreadsheet yet.

Title: Re: Advent of Code
Post by: Davef on 14 December, 2020, 02:35:48 pm

Quote from: grams on 14 December, 2020, 02:28:18 pm

Quote

mask = 000000000000000000000000000000X1001X
mem[42] = 100
mask = 00000000000000000000000000000000X0XX
mem[26] = 1

The first command writes "100" to 4 different addresses. The second command writes "1" to 8 addresses, 2 of which overwrite the 100s. Therefore what's left is 2*100+8*1.

I can't see a sensible way of implementing it with a spreadsheet yet.

My first go splurged stuff all over the place but worked. I then redid it imagining I had a quantum processor using a superposition of quantum states. I then fell back through a wormhole to day 13 part 2.

Title: Re: Advent of Code
Post by: Davef on 14 December, 2020, 02:42:18 pm

Day 13 part 2, only loops 38 times rather than 1000 now, but I feel sorry for the person taking over code maintenance

(click to show/hide)

   // _a[] is array of nn ints with x replaced with 1
// const int x=1;
// int _a[] = {67,7,x,59,61};
// int *a = _a;
    // int n=5;

__int64 p = 1;
__int64 s = 0;
 
for(i=n;i;p*=a[--i]);for(;i<n;i++,a++){if(*a>1){__int64 z=*a,d=z,t,q,e=0,f=1,w=p/ *a;while(w>1){q=w/z;t=z,z=w%z,w=t;t=e,e=f-q*e,f=t;}s+=(*a-i)*(f+(f<0)*d)*(p/ *a);}}

ret=s%p;

Title: Re: Advent of Code
Post by: Greenbank on 14 December, 2020, 03:17:17 pm

(click to show/hide)

Yeah, the 'worst' mask in my input had 9 X's and so that's 512 different addresses it could modify. Given that, I used to a recursive function to set the actual memory. If the address contained an X it would call itself twice replacing the X with a 0 and a 1. If it didn't contain an X it would set the bit of memory to the value provided.

Usual trick of using a hash/dict for memory rather than an array, as the memory in use can be quite spread out and sparse.

But, yes, I think I had to re-read the description about 10 times more than I usually do, it just wouldn't sink in at first.

Title: Re: Advent of Code
Post by: Davef on 14 December, 2020, 03:52:08 pm

Quote from: Greenbank on 14 December, 2020, 03:17:17 pm

(click to show/hide)

Yeah, the 'worst' mask in my input had 9 X's and so that's 512 different addresses it could modify. Given that, I used to a recursive function to set the actual memory. If the address contained an X it would call itself twice replacing the X with a 0 and a 1. If it didn't contain an X it would set the bit of memory to the value provided.

Usual trick of using a hash/dict for memory rather than an array, as the memory in use can be quite spread out and sparse.

But, yes, I think I had to re-read the description about 10 times more than I usually do, it just wouldn't sink in at first.

(click to show/hide)

That was the first approach. I then changed to not expanding the addresses at all and just keeping them with the Xs in as all you want is the total. when it comes to the final output if you have an address with say 8 Xs in and value 200 you add 51200 to you output. The complication is where two address overlap so you have to add corrective entries to negate the intersection (e.g. mem address 26 and 27 in the example). You can spot two addresses that intersect as they both have X at the same point but it gets messy

So for the example after reading input I would end up with have 3 entries in memory
.....X...x 100
......x      -100
.......x..xx  1

The total would be 208 ( 100x4 -100x2 1x8 )

Title: Re: Advent of Code
Post by: Ben T on 14 December, 2020, 04:40:51 pm

Quote from: grams on 14 December, 2020, 02:28:18 pm

Quote

mask = 000000000000000000000000000000X1001X
mem[42] = 100
mask = 00000000000000000000000000000000X0XX
mem[26] = 1

The first command writes "100" to 4 different addresses. The second command writes "1" to 8 addresses, 2 of which overwrite the 100s. Therefore what's left is 2*100+8*1.

I can't see a sensible way of implementing it with a spreadsheet yet.

Oh, I see...
yeah you might have to wheel a programming language out.

Title: Re: Advent of Code
Post by: Lightning Phil on 14 December, 2020, 05:56:09 pm

Quote from: Ben T on 14 December, 2020, 04:40:51 pm

Quote from: grams on 14 December, 2020, 02:28:18 pm

Quote

mask = 000000000000000000000000000000X1001X
mem[42] = 100
mask = 00000000000000000000000000000000X0XX
mem[26] = 1

The first command writes "100" to 4 different addresses. The second command writes "1" to 8 addresses, 2 of which overwrite the 100s. Therefore what's left is 2*100+8*1.

I can't see a sensible way of implementing it with a spreadsheet yet.

Oh, I see...
yeah you might have to wheel a programming language out.

You can do bit operations in Google sheets.  Haven’t looked at what you need to do but bit manipulation via ORs ANDs, shifts etc should not stop you using sheets.

Title: Re: Advent of Code
Post by: grams on 14 December, 2020, 06:12:12 pm

Quote from: Lightning Phil on 14 December, 2020, 05:56:09 pm

You can do bit operations in Google sheets.  Haven’t looked at what you need to do but bit manipulation via ORs ANDs, shifts etc should not stop you using sheets.

That's not the problem. Part 1 was straightforward enough.

The problem is storing the intermediate results of each write, and combining the overwrites to get the final total. Without hashtables or nested loops or a 2^36 array.

There's probably some clever radical simplification of the problem.

Title: Re: Advent of Code
Post by: Davef on 14 December, 2020, 06:29:39 pm

Quote from: grams on 14 December, 2020, 06:12:12 pm

Quote from: Lightning Phil on 14 December, 2020, 05:56:09 pm

You can do bit operations in Google sheets.  Haven’t looked at what you need to do but bit manipulation via ORs ANDs, shifts etc should not stop you using sheets.

That's not the problem. Part 1 was straightforward enough.

The problem is storing the intermediate results of each write, and combining the overwrites to get the final total. Without hashtables or nested loops or a 2^36 array.

There's probably some clever radical simplification of the problem.

You could have one column with memory addresses in an the values in the next. They are are just labels.

Title: Re: Advent of Code
Post by: tonycollinet on 14 December, 2020, 06:40:09 pm

Day 14 complete - less tricky than 13, but...

(click to show/hide)

Still had to think about how to sequence all the X in a part 2 address through all combinations.

For the memory, a python dictionary was useful.

At first I was surprised that the total for part 2 was lower than part 1 - then realised the memory contents were not increased by the mask as they were in P1.

**********************************************************
def AddLead36 (binary):
    if binary[:2] == "0b":
        tmp = binary [2:]
    else:
        tmp = binary
    tmp = "000000000000000000000000000000000000"[:36-len(tmp)]+tmp
    return "0b"+tmp

def ApplyMask (mask, number):
    mXto0 = int(mask.replace("X","0"),2)
    mXto1 = int(mask.replace("X","1"),2)

    return (number | mXto0) & mXto1

def WriteMem2Float (addr, value, mask):
    global mem2
   
    mXto0 = int(mask.replace("X","0"),2)
    addrfloat = AddLead36(bin(addr | mXto0))
    countX = 0
    for c in range (len (mask)):
        if mask[c:c+1]=="X":
            addrfloat = addrfloat[:c+2] + "X" + addrfloat[c+3:]
            countX += 1
   
    for genAdr in range (2**countX):
        sourcebits = AddLead36(bin (genAdr))
        sourcepos = len(sourcebits)-countX
        for c in range (len (mask)):
            if mask[c:c+1]=="X":
                fbit = sourcebits[sourcepos:sourcepos+1]
                addrfloat = addrfloat[:c+2] + fbit + addrfloat[c+3:]
                sourcepos+=1
       
        mem2 [int(addrfloat,2)] = value   
   
# start get data
input_file = open("14Input.txt", "r")
data = [(line.strip()).split(" = ") for line in input_file]
input_file.close()

#format data
df = []
for d in data:
    if d[0]=="mask":
        df_n = ["ma","0",d[1]]
    elif d[0][:4]=="mem[":
        tmp = d[0].split("[")[1]
        tmp = tmp[:len(tmp)-1]
        df_n = ["me",tmp,d[1]]
    else:
        print ("ERROR")
       
    df.append(df_n)


#Part 1 & 2 combined

mask = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
mem1 = {}
mem2 = {}
value1 = 0
value2 = 0

for index, d in enumerate(df):
    if d[0] == "ma":
        mask = d[2]
    elif d[0] == "me":
        addr = int(d[1])
        value1 = ApplyMask (mask,int(d[2]))
        value2 = int(d[2])
        mem1[addr] = value1
        WriteMem2Float (addr,value2,mask)
       
total1 = 0
for m in mem1:
    total1+=mem1[m]
print ("part 1: ",total1)

total2 = 0
for m in mem2:
    total2+=mem2[m]
print ("part 2: ",total2)

Title: Re: Advent of Code
Post by: Diver300 on 14 December, 2020, 11:59:36 pm

Day 14 complete.

(click to show/hide)

For part 2 I suspected that the addresses wouldn't overlap, and spent too long checking whether that was the case. It wasn't
With 100 masks and, and up to 9 Xs in those masks, the total number of memory locations used is a tiny fraction of the 2^36 space, so I thought that they might not overlap.

If there was no overlap, the totals would be the memory values multiplied by 2^(number of Xs in mask)

My data had about 5% of the values replacing others.

It's not very difficult to have a list of addresses and a corresponding list of values. The lisst for my data were about 70000 long, so just over 2^16 and far easier to manage than 2^36

Title: Re: Advent of Code
Post by: grams on 15 December, 2020, 01:27:11 am

Day 14 part 1. Relatively trivial.
https://docs.google.com/spreadsheets/d/1uprQs9jfVjy9C7WC-q9_iVRd9lz6VEts1kPm-iAzPaA/edit?usp=sharing

Day 14 part 2.
https://docs.google.com/spreadsheets/d/1wTfCJDeHbetXmXDTj6ZkR7Z_KBjIpG2dLe91rwaOyNg/edit?usp=sharing

(click to show/hide)

The first step is to apply the 0/1 bit mask. Pretty easy.

In the second step I generate all 70,000 writes and each address. If I had a more malleable data format, I'm sure this could be optimised away, but that's the opposite of what I have.

The real problem was the final step, de-duplicating to work out which values get overwritten. The MATCH() function 70,000 times over 70,000 rows would take literally days. The optimisation that worked was working out that only ca. 2,700 addresses actually get written to more than once, so if I only need to run the full de-duplication search on those.

And now I can go to bed (with 28 gold stars).

Title: Re: Advent of Code
Post by: tonycollinet on 15 December, 2020, 08:45:20 am

Day 15 oddly trivial, even brute forcing part2. I assume there is a more intelligent method for that, but if there is, I haven't found it yet.

(click to show/hide)

Again, a dictionary has proven quite useful

***********************************************
numbers = {8:1,0:2,17:3,4:4,1:5}
turn = 6
lastnum = 12


while turn <30000000:
    if lastnum in numbers:
        num = turn-numbers[lastnum]
    else:
        num = 0

    numbers [lastnum] = turn
    turn += 1
    if turn%1000000==0:print (turn, lastnum, num)
    lastnum = num
   
print ("turn is ", turn, "number is ", num)

Title: Re: Advent of Code
Post by: Greenbank on 15 December, 2020, 08:57:41 am

Occasionally there are 'easy' days to give people a break and let them catch up.

(click to show/hide)

I think the main thing today was teaching people that keeping every turn in an array and looping through the array to search for the previous mention wasn't going to work. Hence the use of a hash/dict to speed up this part of the searching.

The only "trick", as you spotted, was to add the previous turn to the hash after considering the current turn.

My perl solution takes close to 20s but perl's hashes are pretty generic and so integer->integer hash storage/lookup performance isn't optimised.

If I can get some time today I'll rewrite it in C to see how fast that can go.

I don't think there's any way of shorcutting the calculation. Various example series exists in OEIS with no mention of a way to generate arbitrary terms.

Title: Re: Advent of Code
Post by: tonycollinet on 15 December, 2020, 09:02:17 am

Quote from: Greenbank on 15 December, 2020, 08:57:41 am

Occasionally there are 'easy' days to give people a break and let them catch up.

(click to show/hide)

I think the main thing today was teaching people that keeping every turn in an array and looping through the array to search for the previous mention wasn't going to work. Hence the use of a hash/dict to speed up this part of the searching.

The only "trick", as you spotted, was to add the previous turn to the hash after considering the current turn.

My perl solution takes close to 20s but perl's hashes are pretty generic and so integer->integer hash storage/lookup performance isn't optimised.

If I can get some time today I'll rewrite it in C to see how fast that can go.

I don't think there's any way of shorcutting the calculation. Various example series exists in OEIS with no mention of a way to generate arbitrary terms.

(click to show/hide)

Interesting - I keep seeing talk of hashes, and have no idea what they are in this context. Google is... confusing. Is it simply another term for a dictionary?

Title: Re: Advent of Code
Post by: Greenbank on 15 December, 2020, 09:15:10 am

Quote from: tonycollinet on 15 December, 2020, 09:02:17 am

(click to show/hide)

Interesting - I keep seeing talk of hashes, and have no idea what they are in this context. Google is... confusing. Is it simply another term for a dictionary?

Yes, a hash is another name for a dictionary. Different languages use different names.

Dictionaries, hashes, hashmaps, maps, ...

Title: Re: Advent of Code
Post by: Greenbank on 15 December, 2020, 09:52:02 am

Rewrote it in C to see how quick I could get it:-

Code: [Select]

$ gcc -ansi -pedantic -Wall -O4 15.c -o 15
$ time ./15 2 3 1
2020: 78
30000000: 6895259

real    0m0.813s
user    0m0.761s
sys     0m0.052s


(click to show/hide)

Used a hybrid storage, an array for numbers below 100000 and a hash for anything above that. Previous pure hash version was ~2s.

Title: Re: Advent of Code
Post by: Croft on 15 December, 2020, 10:08:54 am

(click to show/hide)

I spent too long on part 2 looking for repeated patterns in the hope of predicting a cycle. But here is a rather nice proof there can be no cycles in the sequence: https://youtu.be/etMJxB-igrc?t=310

Title: Re: Advent of Code
Post by: grams on 15 December, 2020, 10:33:48 am

Day 14, part 2

(click to show/hide)

Having slept on it, I realised the overwrites can be looked for trivially after doing a single stable sort by address, which is orders of magnitude faster than anything I did yesterday.

Day 15, part 2

(click to show/hide)

Google Sheets is limited to 5 million cells across all tabs. I don't really see how I can do 30 million iterations.

Title: Re: Advent of Code
Post by: tonycollinet on 15 December, 2020, 11:43:58 am

Quote from: Greenbank on 15 December, 2020, 09:52:02 am

Rewrote it in C to see how quick I could get it:-

Code: [Select]

$ gcc -ansi -pedantic -Wall -O4 15.c -o 15
$ time ./15 2 3 1
2020: 78
30000000: 6895259

real    0m0.813s
user    0m0.761s
sys     0m0.052s


(click to show/hide)

Used a hybrid storage, an array for numbers below 100000 and a hash for anything above that. Previous pure hash version was ~2s.

I tried the same in python, and it increased  execution time from 13s to nearly 15s

EDIT

(click to show/hide)

Suggests the dictionary lookup is less an overhead than interpreting the additional if-then-else.

Title: Re: Advent of Code
Post by: freeflow on 15 December, 2020, 01:41:38 pm

My Day 15 Part 2 is forecast to complete in around 4 hours :jurek:

Title: Advent of Code
Post by: Davef on 15 December, 2020, 02:46:38 pm

My whopping array takes a few milliseconds

(click to show/hide)

int n = (b==1) ? 30000000 : 2020;

const char *s = "0,14,6,20,1,4";
int *a = new int[n];  // big array!
memset(a, 0, n*sizeof(int));
 
// parse input string
for(int i=1;*s ;s++)if(*s>='0')*a=10**a+(*s-'0');else{a[2+*a]=i++;*a=0;}

// find solution
for(;i<n;){a[1]=*a;*a=a[2+*a];*a=*a?i-*a:0;a[a[1]+2]=i++;}
   
return *a;

Title: Re: Advent of Code
Post by: Greenbank on 15 December, 2020, 03:27:16 pm

Quote from: Davef on 15 December, 2020, 02:46:38 pm

My whopping array takes a few milliseconds

You can shave a tiny bit off if you remove the memset(). Linux should automatically give you zeroed memory.

Title: Re: Advent of Code
Post by: grams on 15 December, 2020, 03:34:01 pm

I finally wheeled out a programming language and decided to see quite how slow a naive C implementation would actually be. It's taken 45 minutes to get to 2.8 million and progress has fallen well below 1000 numbers per second.

Meanwhile I tried to use Applescript. The closest thing it has to a hashtable has keys fixed at compile time, so no good.

So in leiu of a spreadsheet or a programming language, some PHP, which does 30 million iterations in about 7 seconds:

(click to show/hide)

<?php
$lookupTable = array( 19 => 1 , 0 => 2, 5 => 3, 1 => 4, 10 => 5 );
$lastNumber = 13;

for ($i = 6; $i <= 30000001; $i++) {
        if (array_key_exists($lastNumber, $lookupTable)) {
                $previousIndex = $lookupTable[$lastNumber];
                $nextNumber = $i - $previousIndex;
        } else {
                $nextNumber = 0;
        }
        $lookupTable[$lastNumber] = $i;
        if (($i % 10000) == 0 or ($i == 2020)) {
                echo $i . ": " . $lastNumber . "\n";
        }

        $lastNumber = $nextNumber;
}
?>

Davef, do you want to talk us through your code a little bit? My head indirectly hurts.

Title: Re: Advent of Code
Post by: Greenbank on 15 December, 2020, 03:50:33 pm

Quote from: grams on 15 December, 2020, 03:34:01 pm

I finally wheeled out a programming language and decided to see quite how slow a naive C implementation would actually be. It's taken 45 minutes to get to 2.8 million and progress has fallen well below 1000 numbers per second.

Meanwhile I tried to use Applescript. The closest thing it has to a hashtable has keys fixed at compile time, so no good.

So in leiu of a spreadsheet or a programming language, some PHP, which does 30 million iterations in about 7 seconds:

(click to show/hide)

<?php
$lookupTable = array( 19 => 1 , 0 => 2, 5 => 3, 1 => 4, 10 => 5 );
$lastNumber = 13;

for ($i = 6; $i <= 30000001; $i++) {
        if (array_key_exists($lastNumber, $lookupTable)) {
                $previousIndex = $lookupTable[$lastNumber];
                $nextNumber = $i - $previousIndex;
        } else {
                $nextNumber = 0;
        }
        $lookupTable[$lastNumber] = $i;
        if (($i % 10000) == 0 or ($i == 2020)) {
                echo $i . ": " . $lastNumber . "\n";
        }

        $lastNumber = $nextNumber;
}
?>

Davef, do you want to talk us through your code a little bit? My head indirectly hurts.

Here's my fast C code (it's slightly faster, and significantly more readable, than Davef's if I run both on my machine):-

(click to show/hide)

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

int mem[30000000];

int main( int argc, char **argv) {
        int turn=0;
        int last=-1;
        while( argv[turn+1] ) {
                last=atoi(argv[turn+1]);
                mem[last]=turn+1;
                turn++;
        }
        while( turn < 30000000 ) {
                int say=0;
                turn++;
                if( mem[last] > 0 ) say = turn-1-mem[last];
                mem[last]=turn-1;
                last=say;
        }
        printf( "%d\n", last );
        return(0);
}

Simply put, it initialises entries in an array to the turn number when that number was last seen.
The default of 0 will mean that the number has not been seen yet.

Each turn we default the "say" to 0
Unless we find the previous number has been mentioned before, in which case we calculate how many goes ago it was mentioned.
Only after we've done this do we set the 'last seen' entry for a number to the previous turn.
The we update the last item we saw to be the number we just said

Code: [Select]

$ gcc -ansi -pedantic -Wall -O4 15fast.c -o 15fast
$ time ./15fast 2 1 3
3544142

real    0m0.540s
user    0m0.468s
sys     0m0.072s


Title: Re: Advent of Code
Post by: Davef on 15 December, 2020, 03:52:25 pm

Quote from: Greenbank on 15 December, 2020, 03:50:33 pm

Quote from: grams on 15 December, 2020, 03:34:01 pm

I finally wheeled out a programming language and decided to see quite how slow a naive C implementation would actually be. It's taken 45 minutes to get to 2.8 million and progress has fallen well below 1000 numbers per second.

Meanwhile I tried to use Applescript. The closest thing it has to a hashtable has keys fixed at compile time, so no good.

So in leiu of a spreadsheet or a programming language, some PHP, which does 30 million iterations in about 7 seconds:

(click to show/hide)

<?php
$lookupTable = array( 19 => 1 , 0 => 2, 5 => 3, 1 => 4, 10 => 5 );
$lastNumber = 13;

for ($i = 6; $i <= 30000001; $i++) {
        if (array_key_exists($lastNumber, $lookupTable)) {
                $previousIndex = $lookupTable[$lastNumber];
                $nextNumber = $i - $previousIndex;
        } else {
                $nextNumber = 0;
        }
        $lookupTable[$lastNumber] = $i;
        if (($i % 10000) == 0 or ($i == 2020)) {
                echo $i . ": " . $lastNumber . "\n";
        }

        $lastNumber = $nextNumber;
}
?>

Davef, do you want to talk us through your code a little bit? My head indirectly hurts.

Here's my fast C code (it's slightly faster, and significantly more readable, than Davef's if I run both on my machine):-

(click to show/hide)

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

int mem[30000000];

int main( int argc, char **argv) {
        int turn=0;
        int last=-1;
        while( argv[turn+1] ) {
                last=atoi(argv[turn+1]);
                mem[last]=turn+1;
                turn++;
        }
        while( turn < 30000000 ) {
                int say=0;
                turn++;
                if( mem[last] > 0 ) say = turn-1-mem[last];
                mem[last]=turn-1;
                last=say;
        }
        printf( "%d\n", last );
        return(0);
}


Code: [Select]

$ gcc -ansi -pedantic -Wall -O4 15fast.c -o 15fast
$ time ./15fast 2 1 3
3544142

real    0m0.540s
user    0m0.468s
sys     0m0.072s


Mine was specifically designed to be unreadable.

Title: Advent of Code
Post by: Davef on 15 December, 2020, 03:59:36 pm

Quote from: grams on 15 December, 2020, 03:34:01 pm

I finally wheeled out a programming language and decided to see quite how slow a naive C implementation would actually be. It's taken 45 minutes to get to 2.8 million and progress has fallen well below 1000 numbers per second.

Meanwhile I tried to use Applescript. The closest thing it has to a hashtable has keys fixed at compile time, so no good.

So in leiu of a spreadsheet or a programming language, some PHP, which does 30 million iterations in about 7 seconds:

(click to show/hide)

<?php
$lookupTable = array( 19 => 1 , 0 => 2, 5 => 3, 1 => 4, 10 => 5 );
$lastNumber = 13;

for ($i = 6; $i <= 30000001; $i++) {
        if (array_key_exists($lastNumber, $lookupTable)) {
                $previousIndex = $lookupTable[$lastNumber];
                $nextNumber = $i - $previousIndex;
        } else {
                $nextNumber = 0;
        }
        $lookupTable[$lastNumber] = $i;
        if (($i % 10000) == 0 or ($i == 2020)) {
                echo $i . ": " . $lastNumber . "\n";
        }

        $lastNumber = $nextNumber;
}
?>

Davef, do you want to talk us through your code a little bit? My head indirectly hurts.

Basically the same as yours but a big array instead of a dictionary And then I have pissed around to use as few characters as possible and make it as unreadable as possible!

e.g.
Int a[3000000]
a[19] = 1

How I actually wrote it first time with more characters  ...

(click to show/hide)

// parse the input and set it up with e.g.a[14]=1
for (; *s; i++)
{
n = strtol(s,&s,10);
if (*s) {s++;a[n] = i;}
}

// find solution
for (; i <= nn; i++)
{     
int oldn = n;
   
if (n = a[n])  // look it up or 0
          n = i - n - 1; // if found replace with offset

a[oldn] = i-1;  // store
}

Title: Re: Advent of Code
Post by: tonycollinet on 15 December, 2020, 04:43:15 pm

Quote from: Greenbank on 15 December, 2020, 03:50:33 pm

Quote from: grams on 15 December, 2020, 03:34:01 pm

I finally wheeled out a programming language and decided to see quite how slow a naive C implementation would actually be. It's taken 45 minutes to get to 2.8 million and progress has fallen well below 1000 numbers per second.

Meanwhile I tried to use Applescript. The closest thing it has to a hashtable has keys fixed at compile time, so no good.

So in leiu of a spreadsheet or a programming language, some PHP, which does 30 million iterations in about 7 seconds:

(click to show/hide)

<?php
$lookupTable = array( 19 => 1 , 0 => 2, 5 => 3, 1 => 4, 10 => 5 );
$lastNumber = 13;

for ($i = 6; $i <= 30000001; $i++) {
        if (array_key_exists($lastNumber, $lookupTable)) {
                $previousIndex = $lookupTable[$lastNumber];
                $nextNumber = $i - $previousIndex;
        } else {
                $nextNumber = 0;
        }
        $lookupTable[$lastNumber] = $i;
        if (($i % 10000) == 0 or ($i == 2020)) {
                echo $i . ": " . $lastNumber . "\n";
        }

        $lastNumber = $nextNumber;
}
?>

Davef, do you want to talk us through your code a little bit? My head indirectly hurts.

Here's my fast C code (it's slightly faster, and significantly more readable, than Davef's if I run both on my machine):-

(click to show/hide)

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

int mem[30000000];

int main( int argc, char **argv) {
        int turn=0;
        int last=-1;
        while( argv[turn+1] ) {
                last=atoi(argv[turn+1]);
                mem[last]=turn+1;
                turn++;
        }
        while( turn < 30000000 ) {
                int say=0;
                turn++;
                if( mem[last] > 0 ) say = turn-1-mem[last];
                mem[last]=turn-1;
                last=say;
        }
        printf( "%d\n", last );
        return(0);
}

Simply put, it initialises entries in an array to the turn number when that number was last seen.
The default of 0 will mean that the number has not been seen yet.

Each turn we default the "say" to 0
Unless we find the previous number has been mentioned before, in which case we calculate how many goes ago it was mentioned.
Only after we've done this do we set the 'last seen' entry for a number to the previous turn.
The we update the last item we saw to be the number we just said

Code: [Select]

$ gcc -ansi -pedantic -Wall -O4 15fast.c -o 15fast
$ time ./15fast 2 1 3
3544142

real    0m0.540s
user    0m0.468s
sys     0m0.072s


Where I am struggling with a lot of these C implementations - I can't see where your input arrives in the code - the first 5 (or whatever) numbers.

Title: Advent of Code
Post by: Davef on 15 December, 2020, 04:50:21 pm

Quote from: tonycollinet on 15 December, 2020, 04:43:15 pm

Quote from: Greenbank on 15 December, 2020, 03:50:33 pm

Quote from: grams on 15 December, 2020, 03:34:01 pm

I finally wheeled out a programming language and decided to see quite how slow a naive C implementation would actually be. It's taken 45 minutes to get to 2.8 million and progress has fallen well below 1000 numbers per second.

Meanwhile I tried to use Applescript. The closest thing it has to a hashtable has keys fixed at compile time, so no good.

So in leiu of a spreadsheet or a programming language, some PHP, which does 30 million iterations in about 7 seconds:

(click to show/hide)

<?php
$lookupTable = array( 19 => 1 , 0 => 2, 5 => 3, 1 => 4, 10 => 5 );
$lastNumber = 13;

for ($i = 6; $i <= 30000001; $i++) {
        if (array_key_exists($lastNumber, $lookupTable)) {
                $previousIndex = $lookupTable[$lastNumber];
                $nextNumber = $i - $previousIndex;
        } else {
                $nextNumber = 0;
        }
        $lookupTable[$lastNumber] = $i;
        if (($i % 10000) == 0 or ($i == 2020)) {
                echo $i . ": " . $lastNumber . "\n";
        }

        $lastNumber = $nextNumber;
}
?>

Davef, do you want to talk us through your code a little bit? My head indirectly hurts.

Here's my fast C code (it's slightly faster, and significantly more readable, than Davef's if I run both on my machine):-

(click to show/hide)

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

int mem[30000000];

int main( int argc, char **argv) {
        int turn=0;
        int last=-1;
        while( argv[turn+1] ) {
                last=atoi(argv[turn+1]);
                mem[last]=turn+1;
                turn++;
        }
        while( turn < 30000000 ) {
                int say=0;
                turn++;
                if( mem[last] > 0 ) say = turn-1-mem[last];
                mem[last]=turn-1;
                last=say;
        }
        printf( "%d\n", last );
        return(0);
}

Simply put, it initialises entries in an array to the turn number when that number was last seen.
The default of 0 will mean that the number has not been seen yet.

Each turn we default the "say" to 0
Unless we find the previous number has been mentioned before, in which case we calculate how many goes ago it was mentioned.
Only after we've done this do we set the 'last seen' entry for a number to the previous turn.
The we update the last item we saw to be the number we just said

Code: [Select]

$ gcc -ansi -pedantic -Wall -O4 15fast.c -o 15fast
$ time ./15fast 2 1 3
3544142

real    0m0.540s
user    0m0.468s
sys     0m0.072s


Where I am struggling with a lot of these C implementations - I can't see where your input arrives in the code - the first 5 (or whatever) numbers.

In my obscure version at post 1004 above there is a ‘for’ loop after the comment that says parse input

It reads the input string
const char *s = "0,14,6,20,1,4";
 one ascii character at a time and converts to numbers and puts the numbers in the array. Normally I would use a library function for that but instead I convert the asciii to decimal by subtracting ‘0’ (and repeatedly multiplying by 10 if more than one char)

Edit: looking at greenbanks, his input is coming in on the command line. C programs main() function are invoked with an array of arguments in char *argv[]

Title: Re: Advent of Code
Post by: Diver300 on 15 December, 2020, 07:42:11 pm

On day 15 part 1, I had a list of numbers, and for 2020 numbers it didn't take long.

Once I set the same code to run to 30,000,000 numbers it was heading for all day with the computer fan running flat out, and it was slowing down.

(click to show/hide)

Then I realised that a list of positions was a much better way than a list of numbers. There was no need to search through a big array for a particular number. All that was needed was selecting the nth item. The array was only a bit smaller than the 30,000,000, but it only had about 3,600,000 entries.

Title: Re: Advent of Code
Post by: tonycollinet on 15 December, 2020, 08:37:03 pm

Quote from: Davef on 15 December, 2020, 04:50:21 pm

Edit: looking at greenbanks, his input is coming in on the command line. C programs main() function are invoked with an array of arguments in char *argv[]

That'll be it - thanks.

Title: Re: Advent of Code
Post by: grams on 15 December, 2020, 11:43:01 pm

Quote from: Diver300 on 15 December, 2020, 07:42:11 pm

Once I set the same code to run to 30,000,000 numbers it was heading for all day with the computer fan running flat out, and it was slowing down.

So I've worked out that (for my data), to get to 30 million by brute force you'd need to do 71 trillion comparisons. Whereas for 1 million it only needs to do 92 billion. Which is 771, and computer science tells us that's the same as 900.

So to finish in under an hour it needs to get to a million in under 4 seconds, or 23 billion comparisons per second. It's not implausible you could get there with SIMD and/or running it on a GPU.

ETA: I've got the inner loop down to three x86 assembly instructions (load+compare, decrement pointer, conditional jump) and it still takes 45 seconds to get to a million, suggesting a 10 hour completion time. Bah.

Title: Re: Advent of Code
Post by: Davef on 16 December, 2020, 09:05:36 am

Quote from: grams on 15 December, 2020, 11:43:01 pm

Quote from: Diver300 on 15 December, 2020, 07:42:11 pm

Once I set the same code to run to 30,000,000 numbers it was heading for all day with the computer fan running flat out, and it was slowing down.

So I've worked out that (for my data), to get to 30 million by brute force you'd need to do 71 trillion comparisons. Whereas for 1 million it only needs to do 92 billion. Which is 771, and computer science tells us that's the same as 900.

So to finish in under an hour it needs to get to a million in under 4 seconds, or 23 billion comparisons per second. It's not implausible you could get there with SIMD and/or running it on a GPU.

ETA: I've got the inner loop down to three x86 assembly instructions (load+compare, decrement pointer, conditional jump) and it still takes 45 seconds to get to a million, suggesting a 10 hour completion time. Bah.

I think you have the problem the wrong way round. It should only take 30,000,000 loops

I have moved on to trying to squeeze my day 16 down in size. I feel it is going to spread to a couple of punch cards.

Title: Re: Advent of Code
Post by: grams on 16 December, 2020, 01:12:57 pm

Quote from: Davef on 16 December, 2020, 09:05:36 am

I think you have the problem the wrong way round. It should only take 30,000,000 loops

I have the problem the right way round, which is O(n^2), and that's how I like it. I'm trying to figure out if computers are fast enough yet to JFDI, at least for n = 30 million.

Title: Advent of Code
Post by: Davef on 16 December, 2020, 02:01:05 pm

Quote from: grams on 16 December, 2020, 01:12:57 pm

Quote from: Davef on 16 December, 2020, 09:05:36 am

I think you have the problem the wrong way round. It should only take 30,000,000 loops

I have the problem the right way round, which is O(n^2), and that's how I like it. I'm trying to figure out if computers are fast enough yet to JFDI, at least for n = 30 million.

Are you doing it with no storage then ?

With no storage it is O(n^2). With n integers of storage it is O(n)

Title: Re: Advent of Code
Post by: grams on 16 December, 2020, 02:06:58 pm

I'm storing the raw list of numbers and looking backwards until I find a matching number (or, worse, don't).

Title: Advent of Code
Post by: Davef on 16 December, 2020, 03:23:57 pm

Day 16 2

(click to show/hide)

// const char *s = "departure location: 39-715 or 734-949 etc  assumes \r\n line separator
int part=0,i=0,i0=0,lr=0,z=0,m=0;
__int64 ret = 1;

int _a[100000];
memset(_a,0,sizeof(_a));

int *a = _a+20;
int *res = _a;

for (;z<6;s++)
{
for (int k=0;!*s&&k<20;k++) // process results when they are ready
{
for (int j=0,c=0,t=0;j<20;j++) if (!((m|res[k])&(1<<j))){c++;t=j;}
if (c==1){ret*=(t<6)?z++,a[lr+k+1]:1;m|=(1<<t);}
}

if (*s>47&&*s<58)a=10*a+*s-48; // build an integer from ascii
else if (a) // and do something with it
{ 
for (int ok=0,j=0;part==2&&!ok&&j<=lr;j+=2) // valid ticket ?
ok=a>=a[j]&&a<=a[j+1];

for (int t=0,k=0;part==2&&ok&&k<=lr;k+=2) // which fields?
{
t+=a>=a[k]&&a<=a[k+1];
if (k%4==2){if(!t)res[i-i0]|=1<<k/4;t=0;}
}

// assumes CRLF - otherwise change to 10 and checking s[1]
if (*s==13){i0=i+1;if(s[2]==13&&!part++)lr=i;} // next input section
i++;
}
}
return ret;

Better result processing using bitmask

Title: Advent of Code
Post by: Davef on 16 December, 2020, 03:26:35 pm

Quote from: grams on 16 December, 2020, 02:06:58 pm

I'm storing the raw list of numbers and looking backwards until I find a matching number (or, worse, don't).

Why ? The beauty of arrays is that they provide fast access via an integer key

(click to show/hide)

// parse the input and set it up with e.g.a[14]=1
for (; *s; i++)
{
n = strtol(s,&s,10);
if (*s) {s++;a[n] = i;}
}

// find solution
for (; i <= nn; i++)
{     
int oldn = n;
   
if (n = a[n])  // look it up or 0 - this is an assignment as well as test
          n = i - n - 1; // if found replace with offset

a[oldn] = i-1;  // store
}

Title: Re: Advent of Code
Post by: grams on 16 December, 2020, 06:19:18 pm

Quote from: Davef on 16 December, 2020, 03:26:35 pm

Why ? The beauty of arrays is that they provide fast access via an integer key

Idle curiosity.

Clearly the question was set with the expectation that many people would create a naive O(n^2) algorithm for Part 1 and then have to replace it with something at least O(n log n) to calculate Part 2 in reasonable time. But I reckon it's possible to run an O(n^2) solution for n = 30 million in reasonable time.

Day 16:

(click to show/hide)

For part 1, Google Sheets interpreted some - but not all - of the tickets as very large numbers and rounded them off, which took me ages to spot. Grrrrr.

Good thing no one uses spreadsheets for anything life or death.

Title: Re: Advent of Code
Post by: tonycollinet on 16 December, 2020, 06:34:55 pm

Day 16 done.

But I really don't enjoy the ones that result in a mess of data manipulation (how to code it) as distinct from puzzle solving (what do I need to code). It was more like work than fun.

(click to show/hide)

This is as it evolved. I can't be bothered to look if optimisation is possible.
********************************
# start get data
input_file = open("16Input.txt", "r")
data = [line.strip() for line in input_file]
input_file.close()

#format data
rules = []
tickets = []

section = "rules"
for d in data:
    if d!="":
        if section == "rules":
            if d.split()[0]=="your":
                section = "tickets"
            else:
                rules.append([d.split(": ")[0],     d.split(": ")[1].split(" or ")[0].split("-"),      d.split(": ")[1].split(" or ")[1].split("-")])
        else:
            dw1 = d.split()[0]
            if dw1!="" and dw1!="nearby":
                tickets.append(d.split(","))

#part 1
error_rate = 0

for tindex, ticket in enumerate(tickets):
    for val in ticket:
        value = int (val)
        valid = False
        for rule in rules:
            range1 = range(int(rule[1][0]),int(rule[1][1])+1)
            range2 = range(int(rule[2][0]),int(rule[2][1])+1)
            if value in range1 or value in range2:
                valid = True
        if not valid:
            error_rate += value
            tickets[tindex][0]="invalid"

print (error_rate) #Part 1

#Part 2

#Create a matrix of rules (rows) and fields (columns) which are vaild for the rule
rule_valid = []
for r in rules:
    rule_valid.append ([r[0]+"........................."[:-len(r[0])]])

for rindex, rule in enumerate(rules):
    fvcount = 0
    range1 = range(int(rule[1][0]),int(rule[1][1])+1)
    range2 = range(int(rule[2][0]),int(rule[2][1])+1)
    for field in range (len (tickets[0])):
        field_valid = True

        for tindex, ticket in enumerate(tickets):
            if ticket

• != "invalid":

                tick_f = int(ticket[field])
                if tick_f not in range1 and tick_f not in range2: #rule invalid for field on this ticket
                    field_valid = False
        if field_valid:
            rule_valid[rindex].append(1)
            fvcount+=1
        else:
            rule_valid[rindex].append(0)
    rule_valid[rindex].append(fvcount) #tag a count of how many fields are valid to the end of the rule row.

#scan the matrix to decide which field is applicable to which rule
available_flds = [True]*20
for valid_fld_cnt in range (21):
    for rindex, rv in enumerate(rule_valid):
        if rv[-1] == valid_fld_cnt:
            for field in range (len (tickets[0])):
                if rv[field+1]==1 and available_flds[field]:
                    rule_valid[rindex].append(field)
                    available_flds[field]=False

#print the buggers out, and calc the answer.
dep_multi = 1
for rv in rule_valid:
    print (rv)
    if rv[0][:9]=="departure":
        num = int(tickets[0][rv[-1]]) #field from my ticket
        dep_multi *= num

print (dep_multi)

Title: Re: Advent of Code
Post by: Greenbank on 16 December, 2020, 08:00:29 pm

Quote from: grams on 16 December, 2020, 06:19:18 pm

Quote from: Davef on 16 December, 2020, 03:26:35 pm

Why ? The beauty of arrays is that they provide fast access via an integer key

Idle curiosity.

Clearly the question was set with the expectation that many people would create a naive O(n^2) algorithm for Part 1 and then have to replace it with something at least O(n log n) to calculate Part 2 in reasonable time. But I reckon it's possible to run an O(n^2) solution for n = 30 million in reasonable time.

Have implemented what I think is the fastest O(n^2) algorithm for day 15 part 2. So far:-

Code: [Select]

$ time ./15slow 2 1 3
t=4 turn=300000
t=17 turn=600000
t=39 turn=900000
t=68 turn=1200000
t=106 turn=1500000
t=153 turn=1800000
t=208 turn=2100000
t=272 turn=2400000
t=347 turn=2700000

Each one of those lines represents 1% of the number of turns with the t value being the time in seconds it has been running.

Extrapolating I'd be happy if it's done in <24 hours.

[EDIT] The rate of change of the rate of change is about 10 seconds per 1%.

So extrapolating that gives 10 * 100 * 99 / 2 = 49500 seconds =~ 14h

Title: Re: Advent of Code
Post by: grams on 16 December, 2020, 09:41:35 pm

Day 16 done:
https://docs.google.com/spreadsheets/d/1t3jC4tIqWEm3IPSIk0FSWWqPeY4BrNc9HMUSfa0R2fg/edit?usp=sharing

Reasonably straightforward but a lot of steps and therefore a lot of annoying debugging cell reference typos.

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2020, 08:13:41 am

Quote from: Greenbank on 16 December, 2020, 08:00:29 pm

Have implemented what I think is the fastest O(n^2) algorithm for day 15 part 2. So far:-

Code: [Select]

$ time ./15slow 2 1 3
t=4 turn=300000
t=17 turn=600000
t=39 turn=900000
t=68 turn=1200000
t=106 turn=1500000
t=153 turn=1800000
t=208 turn=2100000
t=272 turn=2400000
t=347 turn=2700000

Each one of those lines represents 1% of the number of turns with the t value being the time in seconds it has been running.

Extrapolating I'd be happy if it's done in <24 hours.

[EDIT] The rate of change of the rate of change is about 10 seconds per 1%.

So extrapolating that gives 10 * 100 * 99 / 2 = 49500 seconds =~ 14h

It's exciting (and that updated prediction is looking quite accurate). Should be done inside an hour.

Code: [Select]

...
t=41498 turn=28800000
t=42355 turn=29100000
t=43223 turn=29400000
t=44095 turn=29700000

(The question is whether it will give the right answer! [Which should be 3544142 for the input I gave it.])

Title: Re: Advent of Code
Post by: vorsprung on 17 December, 2020, 08:17:10 am

I see day 17 is a 3-d Conway's Life

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2020, 08:17:30 am

(click to show/hide)

Nothing special here.

Relatively slow solution, takes ~5s for part 2 but not worried about trying to optimise it, got better things to do with my day.

Made reasonable choices in the original development which meant adjusting to part 2 only took a few minutes and gave the correct answer first time.

We're due a virtual machine question though...

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2020, 08:30:02 am

Quote from: vorsprung on 17 December, 2020, 08:17:10 am

I see day 17 is a 3-d Conway's Life

(click to show/hide)

And then you get to part 2...

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2020, 08:38:42 am

Quote from: Greenbank on 17 December, 2020, 08:13:41 am

Quote from: Greenbank on 16 December, 2020, 08:00:29 pm

Have implemented what I think is the fastest O(n^2) algorithm for day 15 part 2. So far:-

Code: [Select]

$ time ./15slow 2 1 3
t=4 turn=300000
t=17 turn=600000
t=39 turn=900000
t=68 turn=1200000
t=106 turn=1500000
t=153 turn=1800000
t=208 turn=2100000
t=272 turn=2400000
t=347 turn=2700000

Each one of those lines represents 1% of the number of turns with the t value being the time in seconds it has been running.

Extrapolating I'd be happy if it's done in <24 hours.

[EDIT] The rate of change of the rate of change is about 10 seconds per 1%.

So extrapolating that gives 10 * 100 * 99 / 2 = 49500 seconds =~ 14h

It's exciting (and that updated prediction is looking quite accurate). Should be done inside an hour.

Code: [Select]

...
t=41498 turn=28800000
t=42355 turn=29100000
t=43223 turn=29400000
t=44095 turn=29700000

(The question is whether it will give the right answer! [Which should be 3544142 for the input I gave it.])

And ...

Code: [Select]

$ time ./15slow 2 1 3
t=4 turn=300000
t=17 turn=600000
t=39 turn=900000
t=68 turn=1200000
...
t=42355 turn=29100000
t=43223 turn=29400000
t=44095 turn=29700000
3544142

real    749m39.241s
user    750m18.228s
sys     0m1.734s

That is the right answer! You are one gold star closer to saving your vacation.

750m = 12 hours and 30 minutes

Source:-

Code: [Select]

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int mem[30000000];

int main( int argc, char **argv) {
        int turn=0;
        int last=-1;
        time_t start;
        time(&start);
        while( argv[turn+1] ) {
                last=atoi(argv[turn+1]);
                mem[turn]=last;
                turn++;
        }
        while( turn < 30000000 ) {
                int say=0;
                int f;
                if( turn % 300000 == 0 ) {
                        time_t now;
                        time(&now);
                        printf( "t=%d turn=%d\n", (int)(now-start), turn );
                }
                f=turn-2;
                while( f >= 0 ) {
                        if( mem[f] == last )
                                break;
                        f--;
                }
                if( f >= 0 ) {
                        say = turn-f-1;
                }
                /* printf( "turn=%d last=%d say=%d f=%d\n", turn, last, say, f ); */
                mem[turn-1]=last;
                last=say;
                turn++;
        }
        printf( "%d\n", last );
        return(0);
}


Title: Re: Advent of Code
Post by: grams on 17 December, 2020, 10:49:00 am

Quote from: Greenbank on 17 December, 2020, 08:38:42 am

Source:-

Code: [Select]

                while( f >= 0 ) {
                        if( mem[f] == last )
                                break;
                        f--;
                }


If you stick the value of last into mem[0] (and shuffle the other numbers up) you only need to do one comparison per loop and it will run considerably quicker. And turn and f will no longer be 1 different.

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2020, 02:24:18 pm

Quote from: grams on 17 December, 2020, 10:49:00 am

If you stick the value of last into mem[0] (and shuffle the other numbers up) you only need to do one comparison per loop and it will run considerably quicker. And turn and f will no longer be 1 different.

Good point...

Old:-

t=347 turn=2700000

New:-

t=191 turn=2700000

So almost twice as fast (so far, although I don't see why that shouldn't continue). Surprised me as I would have thought the infrequent negatives would have trained the branch predictor to err on the side of looping (and then only having to occasionally buck the pipeline), and also that it would have been mostly memory bound given the fact that a ~100MB array isn't going to be very cache friendly.

So, likely to finish take 5-6 hours.

Title: Re: Advent of Code
Post by: tonycollinet on 17 December, 2020, 03:22:26 pm

So day 17:

Part 1 took me about 2.5 hours to sort out, mainly finding a way to efficiently represent infinite 3d space**, with one abortive start***, and a number of stupid typo type bugs. Fortunately I'd structured it in a way that suited part 2. Part 2 took an additional 5 minutes.

(click to show/hide)

**I was expecting part 2 to dramatically expand the universe. As it turned out - not so much.

***I started with a nested dictionary - before I realised a linear dictionary was perfectly adequate, and much simpler

(click to show/hide)

def cTokey(x,y,z,w):
    return(str(x)+' '+str(y)+' '+str(z)+' '+str(w))

def keyToc (key):
    return [int(key.split()[0]),int(key.split()[1]),int(key.split()[2]),int(key.split()[3])]

def SpaceVal (x,y,z,w): #ALWAYS READS FROM space_buf
    global space_buf
    key = cTokey(x,y,z,w)
   
    if key in space_buf:
        return '#'
    else:
        return "."
   
def InactSpace (x,y,z,w):
    key = cTokey(x,y,z,w)
    if key in space:
        del space[key]
       
def ActSpace (x,y,z,w):
    key = cTokey(x,y,z,w)
    space[key] = 1
   
def FindActiveVol ():
    global space
    xr = [100000,-100000]
    yr = [100000,-100000]
    zr = [100000,-100000]
    wr = [100000,-100000]
    for key in space:
        coord = keyToc(key)
        x = coord[0]
        y = coord[1]
        z = coord[2]
        w = coord[3]
        if x<xr[0]:xr[0] = x
        if x>xr[1]:xr[1] = x

        if y<yr[0]:yr[0] = y
        if y>yr[1]:yr[1] = y
       
        if z<zr[0]:zr[0] = z
        if z>zr[1]:zr[1] = z
       
        if w<wr[0]:wr[0] = w
        if w>wr[1]:wr[1] = w
    return ([xr,yr,zr,wr])

def PrintSpace():
    av = FindActiveVol()
    for w in range(av[3][0],av[3][1]+1):
        print ("w",w)
        for z in range(av[2][0],av[2][1]+1):
            print ("z",z)
            for y in range(av[1][0],av[1][1]+1):
                row = ''
                for x in range(av[0][0],av[0][1]+1):#in each of these, expand area by 1 up and 1 down to process surrounding)
                    row = row+SpaceVal (x,y,z,w)
                print (row)
           
def ProcessCube (x,y,z,w):
    now = SpaceVal (x,y,z,w)
    near_act = 0
    for xd in range (-1,2):
        for yd in range (-1,2):
            for zd in range (-1,2):
                for wd in range (-1,2):
                    if not (xd==0 and yd==0 and zd==0 and wd==0):
                        if SpaceVal (x+xd, y+yd, z+zd, w+wd) == "#":
                            near_act += 1
    if now == "#":
        if near_act != 2 and near_act != 3:
            InactSpace (x,y,z,w)
    else:
        if near_act == 3:
            ActSpace (x,y,z,w)


#format data
input = [
    "#...#.#.",
    "..#.#.##",
    "..#..#..",
    ".....###",
    "...#.#.#",
    "#.#.##..",
    "#####...",
    ".#.#.##."]


space = {}

z=0
w=0
for yindex, y in enumerate (input):
    for x in range (len (y)):
        if y[x:x+1] == '#':
            ActSpace (x,yindex,z,w)

#part 1       
space_buf = space.copy()
print (FindActiveVol())
PrintSpace()
for cycle in range (6):

    av = FindActiveVol()
    for x in range(av[0][0]-1,av[0][1]+2):#in each of these, expand area by 1 up and 1 down to process surrounding)
        for y in range(av[1][0]-1,av[1][1]+2):
            for z in range(av[2][0]-1,av[2][1]+2):
                for w in range(av[3][0]-1,av[3][1]+2):
                    ProcessCube (x,y,z,w)
    space_buf = space.copy()
    print (FindActiveVol())
    PrintSpace()
             
print (len(space))

Title: Re: Advent of Code
Post by: vorsprung on 17 December, 2020, 03:42:53 pm

Quote from: Greenbank on 17 December, 2020, 08:30:02 am

Quote from: vorsprung on 17 December, 2020, 08:17:10 am

I see day 17 is a 3-d Conway's Life

(click to show/hide)

And then you get to part 2...

doesn't bother me coz I am still at work and have plenty of programming puzzles to figure out

Title: Re: Advent of Code
Post by: Greenbank on 17 December, 2020, 03:45:06 pm

Quote from: tonycollinet on 17 December, 2020, 03:22:26 pm

So day 17:

That's pretty similar to mine:

(click to show/hide)

https://gist.github.com/alexgreenbank/5e2e9604b8b163aa58c0edcca30765e6

Title: Re: Advent of Code
Post by: Croft on 17 December, 2020, 04:22:59 pm

(click to show/hide)

Because input is just in a 2d plane, the evolved space will be symmetric around that plane, so could save some space (literally) by ignoring offsets in the negative direction for dimensions 3 and 4 and doubling the count in the positive direction of those dimensions.

Title: Re: Advent of Code
Post by: grams on 17 December, 2020, 04:42:21 pm

Quote from: Greenbank on 17 December, 2020, 02:24:18 pm

So almost twice as fast (so far, although I don't see why that shouldn't continue). Surprised me as I would have thought the infrequent negatives would have trained the branch predictor to err on the side of looping (and then only having to occasionally buck the pipeline),

The branch predictor just keeps the pipline full. The operations for each compare (a compare and a conditional branch) will still take up their normal number of cycles, even if the branch predictor is perfect.

Quote

and also that it would have been mostly memory bound given the fact that a ~100MB array isn't going to be very cache friendly.

It ought to load a whole block into cache at once, so I'd expect it to spend very little time waiting for memory loads.

I reckon it's entirely CPU bound.

Title: Re: Advent of Code
Post by: tonycollinet on 17 December, 2020, 06:00:19 pm

Quote from: Croft on 17 December, 2020, 04:22:59 pm

(click to show/hide)

Because input is just in a 2d plane, the evolved space will be symmetric around that plane, so could save some space (literally) by ignoring offsets in the negative direction for dimensions 3 and 4 and doubling the count in the positive direction of those dimensions.

But:

(click to show/hide)

wont the first layer of negative z (and w) influence the neighbour count for z=w=0 - so it would be necessary also to track the positive z/w neighbour counts for z0 and double them also

Title: Re: Advent of Code
Post by: tonycollinet on 17 December, 2020, 06:03:59 pm

Quote from: Greenbank on 17 December, 2020, 03:45:06 pm

Quote from: tonycollinet on 17 December, 2020, 03:22:26 pm

So day 17:

That's pretty similar to mine:

(click to show/hide)

https://gist.github.com/alexgreenbank/5e2e9604b8b163aa58c0edcca30765e6

Ive just done a simple optimisation that...

(click to show/hide)

instead of finding the extent of the volume containing active cubes and processing all cubes in that volume (+ 1 in each direction), It simply processes only the neighbour cubes of each active cube. Also remembering which have been processed so they are not processed twice. Saves about 35% of execution time.

EG - in the 6th step it only processes 23486 cubes instead of 72675

Title: Re: Advent of Code
Post by: Diver300 on 17 December, 2020, 09:53:32 pm

For day 16, I created a sort routine for the 20 fields against the 20 columns, but it was really slow and took half an hour or so. That actually gave me the answer.

Then I realised that one field only worked with one column, that allowed all other fields to be eliminated as option for that column. Columns and rows could be thinned out to the final solution that way, and the code ran in a fraction of a second.

I don't know if the thinning out method will always work when there is a unique solution.

Title: Re: Advent of Code
Post by: grams on 18 December, 2020, 12:16:00 am

Day 17 remains spreadsheetable, although it has so many rows it was immensely crashy on recalculation:
https://docs.google.com/spreadsheets/d/1vb2HE64SbJN3acZpFipF3T01m-ABLNuUje7UEQpx_C4/edit?usp=sharing

(click to show/hide)

I was already linearising it to store each iteration in one common, so part 2 was very straightforward, if incredibly slow

Quote from: Diver300 on 17 December, 2020, 09:53:32 pm

I don't know if the thinning out method will always work when there is a unique solution.

It ought to. I did worry they might have made it extra hard as you don't need to figure out which departure field is which for the answer they want.

Title: Re: Advent of Code
Post by: Ben T on 18 December, 2020, 12:24:40 pm

Day 18 quite interesting

(click to show/hide)

part 1

Code: [Select]

    public class Day18
    {
        public static async Task Part1(string[] args)
        {
            string line;
            long result = 0;
            while((line = await Console.In.ReadLineAsync()) != null)
            {
               
                var lineResult = EvaluateExpression(line, 0);
                await Console.Out.WriteLineAsync($"{line} = {lineResult}");
                result += lineResult;
            }
            await Console.Out.WriteLineAsync(result.ToString());
        }

        private static long EvaluateExpression(string line, int depth)
        {
            while(line.Contains("("))
            {
                var newline = Regex.Replace(line, @"\(([^()]+)\)", m => EvaluateExpression(m.Groups[1].Value, depth + 1).ToString());
                if(newline == line) throw new InvalidOperationException($"Mismatched brackets");
                line = newline;
            }

            long result;
            while(!long.TryParse(line.Trim(), out result))
            {
                var newline = Regex.Replace(line, @"^\d+[^\d]+\d+", m => EvaluateSingleExpression(m.Value).ToString());
                if(newline == line) throw new InvalidOperationException($"Failed to chomp first expression");
                line = newline;
            }

            return result;
        }

        private static readonly Regex singleExpressionMatch = new Regex(@"^\s*(\d+)\s*([*+])\s*(\d+\s*$)");
        private static long EvaluateSingleExpression(string expression)
        {
            var match = singleExpressionMatch.Match(expression);
            if(!match.Success) throw new InvalidOperationException($"{expression} not recognized");

            var op = match.Groups[2].Value;
            if(op == "*")
                return long.Parse(match.Groups[1].Value) * long.Parse(match.Groups[3].Value);
            else if(op == "+")
                return long.Parse(match.Groups[1].Value) + long.Parse(match.Groups[3].Value);
            else throw new InvalidOperationException($"Operator {op} not recognized - expression = {expression}");
        }
    }


small change for part 2:

Code: [Select]

using System;
using System.Collections.Concurrent;
using System.Linq.Expressions;
using System.Text.RegularExpressions;
using System.Threading.Tasks;
using Microsoft.CodeAnalysis.CSharp.Scripting;

namespace AoC2020
{
    public class Day18
    {
        public static async Task Part2(string[] args)
        {
            string line;
            long result = 0;
            while((line = await Console.In.ReadLineAsync()) != null)
            {
               
                var lineResult = EvaluateExpression(line, 0);
                await Console.Out.WriteLineAsync($"{line} = {lineResult}");
                result += lineResult;
            }
            await Console.Out.WriteLineAsync(result.ToString());
        }

        private static long EvaluateExpression(string line, int depth)
        {
            while(line.Contains("("))
            {
                var newline = Regex.Replace(line, @"\(([^()]+)\)", m => EvaluateExpression(m.Groups[1].Value, depth + 1).ToString());
                if(newline == line) throw new InvalidOperationException($"Mismatched brackets");
                line = newline;
            }

            while(line.Contains("+"))
            {
                var newline = Regex.Replace(line, @"\d+\s*\+\s*\d+", m => EvaluateSingleExpression(m.Value).ToString());
                if(newline == line) throw new InvalidOperationException("Failed to chomp +");
                line = newline;
            }

            long result;
            while(!long.TryParse(line.Trim(), out result))
            {
                var newline = Regex.Replace(line, @"^\d+[^\d]+\d+", m => EvaluateSingleExpression(m.Value).ToString());
                if(newline == line) throw new InvalidOperationException($"Failed to chomp first expression");
                line = newline;
            }

            return result;
        }

        private static readonly Regex singleExpressionMatch = new Regex(@"^\s*(\d+)\s*([*+])\s*(\d+\s*$)");
        private static long EvaluateSingleExpression(string expression)
        {
            var match = singleExpressionMatch.Match(expression);
            if(!match.Success) throw new InvalidOperationException($"{expression} not recognized");

            var op = match.Groups[2].Value;
            if(op == "*")
                return long.Parse(match.Groups[1].Value) * long.Parse(match.Groups[3].Value);
            else if(op == "+")
                return long.Parse(match.Groups[1].Value) + long.Parse(match.Groups[3].Value);
            else throw new InvalidOperationException($"Operator {op} not recognized - expression = {expression}");
        }
    }
}


Title: Re: Advent of Code
Post by: Greenbank on 18 December, 2020, 12:52:18 pm

(click to show/hide)

Iterative/recursive hybrid in perl:-

https://gist.github.com/alexgreenbank/9c1fce97c7f1d341b3ddfc92feb6cf67

Title: Re: Advent of Code
Post by: grams on 18 December, 2020, 12:58:59 pm

Day 18 part 1:
https://docs.google.com/spreadsheets/d/1SmJDMWM0QfYyfTanZWOrZEGvkDF6yA8EabCrKCAXtdc/edit?usp=sharing

(click to show/hide)

The first column on the Substitutions tab required manual intervention to construct, as I don't think it's possible in a spreadsheet otherwise without upsetting the circular reference goblin.

The string lookup functions treat asterisk as a wildcard. That was fun to debug.

Part 2 will require extra rounds to evaluate plus before multiply. Not sure I CBA making that happen.

ETA: Part 2
https://docs.google.com/spreadsheets/d/1r78qCZenNR7SrqM1HmzznSoJcvQ4im_SmbZ1TcKr0UY/edit?usp=sharing

Title: Re: Advent of Code
Post by: tonycollinet on 18 December, 2020, 09:20:20 pm

Excuse my French, but Holy Hell day 18 (part 1) was a fucking BASTARD.

I could not get my head round parsing the brackets, and then calculating in parsed order. I have a serious headache now. And that was *with*

(click to show/hide)

ripping of a generic stack based parse brackets function from stack exchange.

I'm also certain that there must be a more elegant recursive approach, but I just couldn't get there.


Part two was a doddle - just a minor change to the 'calculate flat string' function.

Code here has a metric shedload of diagnostic print statements that I am not going to remove  ;)

(click to show/hide)

def evaluate(expression):
    opp = '-'
    acc = 0
    for i,x in enumerate(expression.split()):
        if i==0:#first number into accumulator
            acc = int(x)
        elif x=='*' or x=='+':
            opp = x
        elif opp == '+':
            acc = acc + int(x)
        elif opp == '*':
            acc = acc * int(x)
        else:
            print ('not sure what happened')
#     print (expression.split(), acc)
    return (acc)
def p2Evaluate (expression):
    split_exp = expression.split('*')
    ret = 1
    for multiple in split_exp:
        ret = ret * evaluate(multiple)
    return (ret)
   
   
def SplitBrackets(string):
    """Generate parenthesized contents in string as pairs (level, contents)."""
    stack = []
    for i, c in enumerate(string):
        if c == '(':
            stack.append(i)
        elif c == ')' and stack:
            start = stack.pop()
            yield (len(stack), string[start + 1: i])

# start
input_file = open("18Input.txt", "r")
#data = [(line.strip()).split() for line in input_file]
data = [line.strip() for line in input_file]
input_file.close()




last_depth = 0
max_depth = 0
calced_subs = []
sub = []
grand_total = 0

for full_exp in data:
    full_exp = '('+full_exp+')'
    sb = SplitBrackets(full_exp)

    for exp in sb:
        print (exp)
       
    sb = SplitBrackets(full_exp)
       
    for index, exp in enumerate(sb):
        depth = exp

        if index == 0:
            max_depth = depth
            last_depth = max_depth
            print (max_depth)
        print ('---------------------------Expression ',exp)

        if depth<last_depth:
            string = exp [1]
            print ('Presub ',string)
            sub = calced_subs.pop()
            print ('popped sub', sub)
            while last_depth == sub[0]:
                string = string.replace('('+sub[1]+')',sub[2])
                print ('Postsub ',string)
                if len (calced_subs)>0:
                    sub = calced_subs.pop()
                    print ('popped sub', sub)
                else: break
            calced_subs.append(sub)   # - put last popped sub back
               
            print ('about to evaluate ' , string)
            this_sub =  [exp[0],exp[1],str(p2Evaluate(string))]
            print ('About to append ',this_sub)
            calced_subs.append (this_sub)
           
        if depth >= last_depth:
            this_sub =  [exp[0],exp[1],str(p2Evaluate(exp[1]))]
            print ('About to append ',this_sub)
            calced_subs.append (this_sub)
       
        last_depth = depth

    grand_total = grand_total + int(this_sub[2])
   
print (grand_total)   

Title: Re: Advent of Code
Post by: Diver300 on 19 December, 2020, 03:31:01 am

For day 18 my first attempt tried to have recursion for both brackets and for dealing with left to right precedence but it all got a bit mixed up, and didn't get the precedence correct for operators after brackets. It was a bit frustrating that it was fine for shorter lines in my puzzle input, but fell over with the longer ones.

My working attempt used recursion on the brackets. The function found if there were any brackets, and if so, found the highest level of brackets, and then found the first instance of that level. The function would then call itself twice, in the form f( [part before bracket] . f( [part inside bracket] . [part after bracket]).

I just seemed to make lots of mistakes like not calculating [part before bracket] or [part after bracket] correctly, especially when one was zero length.

My code also had lots of diagnostic print statements, although I only used them on single lines of the puzzle input.

Title: Re: Advent of Code
Post by: grams on 19 December, 2020, 10:26:05 am

My spreadsheets finds the last opening bracket in the string and finds the first closing bracket after it. That's guaranteed to never contain any other brackets. Process the calculation inside, substitute it in the string with the answer and do it all again. No recursion required.

For part 2 only processing the calculation changed. I checked if the string contained a mix of additions and multiplications. If not, I used the formulae from part 1. If yes, I processed only the additions and gave the unfinished calculation as the result string, still with brackets. The multiplications would be processed on the next iteration of processing brackets. The latter is largely a limitation of doing it with a spreadsheet.

Day 19 part 1:

(click to show/hide)

Making a list of all of the valid messages doesn't seem to be a goer. I get 2^370 combinations.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2020, 12:59:25 pm

Day 19, late to start it as I had family stuff to do in the morning.

Expected my initial semi-naive algorithm to require rework to speed it up or prevent it wasting time going down dead ends but it gave me the right answer for part 1 in under a second.

Also lucky that the way I'd implemented it meant that part 2 was a doddle. According to the stats I got the second star just 75 seconds after the first. All I did was tweak my input accordingly and the right answer for part 2 popped out straight away.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2020, 05:09:22 pm

I think Day 19 (and maybe Day 18) has seen a big slow down in people completing.

This could be for several reasons:-
* There's a natural daily drop-off of people completing each day
* Many people have started their holidays at this point (my last working day for this year was yesterday for example)
* Natural weekend slowdown

But the biggest reason, I'd suggest, is that day 18 and Day 19 are the first problems that weren't just (IMHO) "simple" programming problems. By this I mean "programming" in terms of knowing what to tell the computer to do in order to solve the problem, i.e. procedural programming.

Whereas day 18 and 19 it's not so obvious what the procedure for solving the problem actually is. It's not a case of "for each point in 3D/4D space calculate the number of neighbours and iterate" or "parse the list of passwords and test them against these rules".

Title: Re: Advent of Code
Post by: Pickled Onion on 19 December, 2020, 05:38:51 pm

Quote from: tonycollinet on 18 December, 2020, 09:20:20 pm

Excuse my French, but Holy Hell day 18 (part 1) was a fucking BASTARD.

I could not get my head round parsing the brackets, and then calculating in parsed order.

(click to show/hide)

The way the explanation is laid out normally gives a hint on the approach to take with these puzzles. So rather than "parsing" where you read left to right, find an opening parenthesis, count them to find the closing one, etc., instead find the innermost and work outwards replacing the result each time. Part2 is then an extension of that where any addition is basically equivalent to a parenthesis.

Title: Re: Advent of Code
Post by: Davef on 19 December, 2020, 06:07:42 pm

Had a catch up after 3 days off. Need to go back to multi dimensional life as my cunning several dimensions all in one integer is not quite  working.

Title: Re: Advent of Code
Post by: Davef on 19 December, 2020, 06:52:11 pm

I did day18 part 1 with no library calls and minimal c with recursion

(click to show/hide)

static __int64 eval(const char *& s)
{
__int64 ret=0,op='+',n=0;

for (;*s; s++)
{
if (*s>='0'&&*s<='9') n=10*n+*s-'0';     // build up integer
else if ((*s=='*')||(*s=='+')) op = *s;  // save the op
else if (*s=='(' || (s[-1]>='0'&&s[-1]<='9')|| (*s==')') )
{
if (*s=='(') { s++; n = eval(s); s++; }  // recurse for brackets
ret += (op=='+')*n;    // do +
ret *= op=='*'?n:1;    // *
n = 0;
}

if (*s==')') break;
}

return ret;
}

Part 2 I went a bit wild and used a c++ string class. Feeling a bit dirty.

(click to show/hide)

// find matching bracket
int matching(const char *p)
{
int c = 0;
for (int i = 0; p; i++)
{
if (p=='(') c++;
if (p==')') { c--; if (!c) return i; }
}

return -1;
}

static __int64 eval2(CString s)
{
int n = s.Find('(');
if (n>=0)
{
int n2 = matching(s);
s = s.Left(n) + fmt64(eval2(s.Mid(n+1, n2-n-1))) + s.Mid(n2+1);
return eval2(s);
}

if ((n = s.Find('*'))>=0)
return eval2(s.Left(n))*eval2(s.Mid(n+1));

if ((n = s.Find('+'))>=0)
return eval2(s.Left(n)) + eval2(s.Mid(n+1));

return atoll(Trim(s));
}

Title: Re: Advent of Code
Post by: grams on 19 December, 2020, 08:11:32 pm

Day 19:

(click to show/hide)

I reckon parsing with a spreadsheet is a bit too hard but I did use one to turn the rules into a monster regex that worked perfectly full time for Part 1.

Part 2 I did by looking at the rules.

Quote

0: 8 11
8: 42 | 42 8
11: 42 31 | 42 11 31

Which implies every valid string has (n+m) instances of 42 followed by m instances of 31, where n and m are both >= 1. So I extracted the 31 and 42 regexes and made a table to build and try giant slow regexes for different values of m (n >= 1 is handled by the + operator). Max actually needed was m=5.

https://docs.google.com/spreadsheets/d/1c3sM2aFwMljOh9K5EcRXms9jCB55ErwjGsTzpp89TjM/edit?usp=sharing

Title: Re: Advent of Code
Post by: tonycollinet on 19 December, 2020, 10:56:58 pm

I have to confess, 19p2 has me beat.

Title: Re: Advent of Code
Post by: grams on 19 December, 2020, 11:19:20 pm

Quote from: tonycollinet on 19 December, 2020, 10:56:58 pm

I have to confess, 19p2 has me beat.

(click to show/hide)

If your root rules are the same as mine you can completely ignore the recursion and just feed "0: 42 42 31" and various other valid combinations into your code from part 1. It does explicitly say in today's task that you only need it to work for the rules you have, not to be general purpose.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2020, 11:19:42 pm

(click to show/hide)

Split this into two stages (well 2 for part one and then a third for part 2 when you have to write a slightly different calculation function).

First of all you need a function/method/procedure/whatever to calculate the value of the string assuming there are no parentheses.

So, given the string "1 + 2 * 3 + 4 * 5 + 6" you need to be able to parse this and come up with an answer.

For part 1 this is relatively simple as you simply read it in from left to right and apply the operations as you see them.
curr = 1
curr + 2 = 3
curr * 3 = 9
curr + 4 = 13
curr * 5 = 65
curr + 6 = 71

But this obviously doesn't deal with parentheses. But, as others have hinted, you don't really need to worry too much about them. Just look for what you can calculate, if the the string is:-

"( ( ( 3 + ( 2 * 4 + 5 ) * 2 ) + 1 ) + 2 ) + 3"

Then you just need to deal with what you can deal with, and that is strings that don't have parentheses.

So either use grams approach and look through the string for the last opening parenthesis followed by the next closing parenthesis. That gets you the string "(2 * 4 + 5)" which you can work out using your earlier function to be 13 and so you replace "(2 * 4 + 5)" by 13 to get:-

"( ( ( 3 + 13 * 2 ) + 1 ) + 2 ) + 3"

Now you repeat the previous step and process "(3 + 13 * 2 )" to get "32", giving you "( ( 32 + 1 ) + 2 ) + 3" and so on through "( 33 + 2 ) + 3", "35 + 3" to "38".

If you want to use regex then I looked for an opening parenthesis following by any number of characters that weren't another opening parethensis and then a closing parenthesis. That allowed me to pull out the chunks that could be solved by the function/method/procedure/whatever developed earlier.

Then part (2) was just a different version of the calculation function, the parentheses will be dealt with in exactly the same way as before.

So given a string of "1 + 2 * 3 + 4 * 5 + 6" we know that addition should be performed first, so we look for every occurrence of "<numbers>  + <numbers>" and replace those with the answers, e.g.

"1 + 2" -> 3
"3 + 4" -> 7
"5 + 6" -> 11

giving:-

"3 * 7 * 11" = "231"

Again, this is just applied to each sum enclosed by parentheses (that doesn't have any other sub clauses in it).

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2020, 11:31:57 pm

(click to show/hide)

I didn't use regex or anything like that for this problem.

I used a recursive solution that, surprisingly, gave the correct answer quickly (solving both parts in less than a second) with minimal hassle.

I just started off with a string of "0" and, upon recursion, the function would attempt to replace the first number in the current string with each of the corresponding possibilities.

With each recursion the start of the string would grow with a number of a's and b's before the first number appeared, so I could bail on any attempts where the current string didn't match the start of the string I was attempting to check. This was possible as there was no way for the rules to change what characters had already been laid down before the first number.

I thought I would need to modify it to spot when the string was too long but this never happened.

So, in my rules, I had:-

0: 8 11
8: 42
42: 69 48 | 12 41
...

Where 69 was "a" and 12 was "b".

So if I was trying to match "bbbb" for example, it would go:-

"0" and find rule "0" -> "8 11" to give:-
"8 11", and checking rule "8" -> "42" to give: "42 11"
"42 11", and checking rule "42" -> "69 48" or "12 41",
so first try: "69 48 11"
  "69 48 11" and checking rule "69" -> "a" we get "a 48 11" but this would only give strings starting with "a" and our string starts with "b" so no match here
second try: "42" -> "12 41" to give "12 41 11"
  "12 41 11" and checking rule "12" -> "b" we get "b 41 11" and so the [ab] characters on the left hand side ("b") match the first bits of the string we want to match, so it continues and recurses, etc.

No other early bail was required, it ran quickly for both strings that matched and strings that didn't match.

Given this, part 2 was a doddle, I just replaced the 8 and 11 rules and it ran straight away giving the right answer first time. No tweaks to the algorithm required. I submitted my answer for part two a whole 75 seconds after my answer for part one.

As others have said, it was specifically designed not to be overly tricky, it could have included so many levels of nesting/recursion/loops that would have made lots of naive algorithms spin for days. Luckily it didn't.

Title: Re: Advent of Code
Post by: Diver300 on 20 December, 2020, 12:05:02 am

I'm struggling on day 19. After some effort I got an algorithm to run that produces 2^21 rules, each of 24 characters in length. The length isn't set in the algorithm, the 24 is what comes out of the data.

None of those match the messages.

I've run through the first option for each rule set and it seems to work out to the first rule that my algorithm produces.

Title: Re: Advent of Code
Post by: Diver300 on 20 December, 2020, 12:36:55 am

Quote from: Diver300 on 20 December, 2020, 12:05:02 am

I'm struggling on day 19. After some effort I got an algorithm to run that produces 2^21 rules, each of 24 characters in length. The length isn't set in the algorithm, the 24 is what comes out of the data.

None of those match the messages.

I've run through the first option for each rule set and it seems to work out to the first rule that my algorithm produces.

I've just realised my counting of the matches with the messages was wrong. I've done the first part.

Title: Re: Advent of Code
Post by: tonycollinet on 20 December, 2020, 09:58:05 am

I've reached the point where the time to solve the puzzles is longer than the available time I have each day. I'm going to carry on, but no longer attempt to keep up. Falling of the back of the peloton as it were :D

Title: Re: Advent of Code
Post by: grams on 20 December, 2020, 12:07:10 pm

Day 20 part 1:

(click to show/hide)

There's a shortcut to find the tiles for the answer without worrying about all the others

Title: Re: Advent of Code
Post by: Croft on 20 December, 2020, 01:18:39 pm

Quote from: grams on 20 December, 2020, 12:07:10 pm

Day 20 part 1:

(click to show/hide)

There's a shortcut to find the tiles for the answer without worrying about all the others

(click to show/hide)

Which probably explains why the completion times for part 2 are so much longer because (as far as I can see) that shortcut won't work for the second part.

Title: Re: Advent of Code
Post by: Greenbank on 20 December, 2020, 04:05:54 pm

2020 day 20. That was fun. I was in and out doing various bits so my time was rather fragmented.

Probably took me 90 minutes or so whilst actually sat at a computer, but that was spread out over ~8h or so, and some of those other 6.5h not at a computer were spent thinking about various bits so it would have taken me more than 90 minutes if I sat down to do it in one go (or maybe I would have gained some time not being so distracted or having to mentally get back into it, anyway, who knows).

Spotted the trick for part 1 and did that quite quickly, obviously part 2 renders that trick not so useful, but it does help with how you need to go about the major chunk of part 2.

Annoying as I had an off by one error in part 2 that meant I got the correct answer for the example but not for my input (always fun when that happens). Also annoying that I had to go out this afternoon for a long walk and only fixed it when back (within 2 minutes!), so it could have been finished 3h earlier.

Interesting problem. Was good to break it down into little chunks and solve each of those (with some testing!) and see it all assemble together to give the answer.

[EDIT] I don't look at the leaderboards until I've got both stars so I never really know whether it's a hard problem or whether I'm just missing something obvious. It's my best placing on part 2 so far this year (3141) which taking into account the large amount of time away from the computer, is good going.

Title: Re: Advent of Code
Post by: Ben T on 20 December, 2020, 04:10:18 pm

Found day 19 part 2 quite hard but have done it now.

(click to show/hide)

Rule 0 is just 8..11.
Rule 8 is just 42, or 42..8 => so just 42 repeated any number of times.
Rule 11 is 42..31 or 42..11..31. So in other words, 11 = 42..31 | 42..42..31..31 | 42..42..42..31..31..31| etc    - i.e. 42 n times, then 31 that same number of times.

So rule zero is therefore
42{1,}..42{m}..31{m}
therefore
42{n}..31{m} where n >= m+1

(click to show/hide)

first resolve all the other rules (or at least 31 and 42, which probably involves resolving the others) to regexes, then
for each line, keep matching 31 at the end, keep track of how many times you have matched 31, and if the remainder matches 41 that many times + 1, you have a match.

Code: [Select]

private static bool IsMatch(string line)
{
    string wip = line;
    int end31s = 0;
    while(true)
    {
        string newwip = Regex.Replace(wip, $"{rule31}$", "");
        if(newwip != wip) end31s++;
        else return false;

        if(Regex.IsMatch(newwip, $"^{rule42}{{{end31s+1},}}$")) return true;

        wip = newwip;
    }
}



Title: Re: Advent of Code
Post by: grams on 20 December, 2020, 06:30:23 pm

Day 20 parts 1 and 2:
https://docs.google.com/spreadsheets/d/1pMovEAF1L-UlmCy6rSLCFxMGXzA6VrhzESYRUmPPTQY/edit?usp=sharing

(click to show/hide)

This was a ludicrous amount of work. Using the corners form part 1 you can build out the whole image as all edges are unique. Then you have to build out the image, remembering to flip the data in each tile (which I completely forgot to do first time). Then you have to try out all orientations of the whole image until you find any sea monsters. Then you have to check the lines for a second sea monster. Then possibly a third.

If you wanted to shortcut all this, just count the hashes in your tiles, guess a plausible number of sea monsters and multiply by 15 and deduct it.

Title: Re: Advent of Code
Post by: Greenbank on 20 December, 2020, 08:35:05 pm

Quote from: grams on 20 December, 2020, 06:30:23 pm

(click to show/hide)

...
If you wanted to shortcut all this, just count the hashes in your tiles, guess a plausible number of sea monsters and multiply by 15 and deduct it.

(click to show/hide)

I did think that it'd be possible to do this with a binary search but Eric obviously foresaw this and you stop getting the "that's too high" or "that's too low" hints after a few incorrect attempts. The delays between guess attempts also grows I think.

Title: Re: Advent of Code
Post by: Davef on 20 December, 2020, 10:45:12 pm

I thought the second part of today’s was a bit of a slog. Certainly no solution I could see in a few lines of code though I could see what I had to do -  plenty of opportunity for errors.

Title: Re: Advent of Code
Post by: Davef on 21 December, 2020, 09:49:30 am

Day 21 part 2 seemed rather trivial. Perhaps I had over-solved part 1.

Title: Re: Advent of Code
Post by: Croft on 21 December, 2020, 10:05:36 am

(click to show/hide)

I think day 21, which I enjoyed, would be more interesting if it didn't include the worked example. The puzzle here is in translating the problem into, what turns out to be, a couple of simple set operations. The worked example makes that possible as a pattern matching exercise rather than the more interesting logical reasoning.

Title: Advent of Code
Post by: Davef on 21 December, 2020, 10:15:05 am

Quote from: Croft on 21 December, 2020, 10:05:36 am

(click to show/hide)

I think day 21, which I enjoyed, would be more interesting if it didn't include the worked example. The puzzle here is in translating the problem into, what turns out to be, a couple of simple set operations. The worked example makes that possible as a pattern matching exercise rather than the more interesting logical reasoning.

(click to show/hide)

Seemed oddly similar to day 16

For me, part 2 was “now sort your results into alphabetical order”!

Title: Re: Advent of Code
Post by: Diver300 on 21 December, 2020, 12:45:19 pm

Quote from: Davef on 21 December, 2020, 09:49:30 am

Day 21 part 2 seemed rather trivial. Perhaps I had over-solved part 1.

I can't see how part 1 can be solved without going most of the way to solving part 2.

(click to show/hide)

As with Day 16, where columns could be matched to rows by finding rows that only matched one column, and eliminating those columns for other rows, Day 21's list of ingredients could be matched to allergens by eliminating ingredients known to only match one allergen.

I suspect that may be a property of puzzles with unique solutions. Problems in real life aren't so simple.

The solution to Day 21 part 1 probably doesn't need allergens to be uniquely allocated to ingredients. I had done that allocation before submitting my answer to part 1

Title: Re: Advent of Code
Post by: grams on 21 December, 2020, 02:42:38 pm

Day 21:
https://docs.google.com/spreadsheets/d/1jEu0iCON4JgT1V5ee8U4zAsdBD3f9Ly33wvktBDqNfQ/edit?usp=sharing

(click to show/hide)

I spent a *long* time looking at the example and not understanding it at all. The "each allergen only appears in one ingredient" didn't really click and doesn't fit how allergens work. Not a great framing device. And yeah, a rehash of Day 16.

Also I wasted a lot of time wondering why it wouldn't work because I'd lost 1 of the allergens completely with a wonky cell reference.

The AoC code wouldn't accept my answer. After wondering if my data was bad or the site was broken, I realised I'd also lost 50 ingredients to the same mistake. FFS.

Quote from: Diver300 on 21 December, 2020, 12:45:19 pm

I can't see how part 1 can be solved without going most of the way to solving part 2.

See the "alternative" tab on my spreadsheet. For each allergen, only ingredients that appear in every food that mentions that allergen are candidates to be an allergen. Only 8 ingredients have that property for at least one allergen. I'm not sure if that's guaranteed to be true, but it is for the data you're given.

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2020, 07:49:41 pm

Day 20 alternative input: https://gist.github.com/alexgreenbank/3a5dcb1a2854321558509247b1ed78e4

Title: Re: Advent of Code
Post by: grams on 21 December, 2020, 11:49:21 pm

Quote from: Greenbank on 21 December, 2020, 07:49:41 pm

Day 20 alternative input: https://gist.github.com/alexgreenbank/3a5dcb1a2854321558509247b1ed78e4

Needs more sea monsters.
https://docs.google.com/spreadsheets/d/1dhOAv1rMzblj7Y6POpbM1DPKnj3eypgsz0fC5JPrXas/edit#gid=901221645

Title: Advent of Code
Post by: Davef on 22 December, 2020, 02:24:32 pm

Quote from: Greenbank on 21 December, 2020, 07:49:41 pm

Day 20 alternative input: https://gist.github.com/alexgreenbank/3a5dcb1a2854321558509247b1ed78e4

Lost on me as my solution didn’t actually rotate or stitch together the data but just kept the original data along with a list of transformations. With hindsight this was a mistake because although efficient once working it was hellish to debug. It also means I can could not visualise your data without writing some more code.

Title: Re: Advent of Code
Post by: Davef on 22 December, 2020, 02:25:57 pm

Day 22 done. Back to fine tuning my day 17 part 2 multidimensional life.

Title: Re: Advent of Code
Post by: grams on 22 December, 2020, 02:35:10 pm

Day 22 part 1 was nice and straightforward and satisfying. Part 2 just makes my eyes glaze over.

Title: Re: Advent of Code
Post by: Greenbank on 22 December, 2020, 02:37:21 pm

I purposely put in just one (although the other bits of rough sea are placed at random so it another could easily appear by random) in order to be underwhelming for people who aren't printing out the final map.

Writing something to fake the whole input is an interesting exercise. One thing I didn't think about is that not only do the edges of adjacent tiles need to match but the 4 tiles in an inner corner all need to have the same symbol ( . or # ) at that corner, which means there's some careful selection of edge "numbers" that need to be done. Ho hum.

Title: Re: Advent of Code
Post by: Greenbank on 22 December, 2020, 02:39:14 pm

Quote from: grams on 22 December, 2020, 02:35:10 pm

Day 22 part 1 was nice and straightforward and satisfying. Part 2 just makes my eyes glaze over.

(click to show/hide)

It took me many times of reading for it to sink in but it was a relatively trivial implementation if you've already done part 1.

I think this was the "breather" day from the previous few (20 especially).

Title: Re: Advent of Code
Post by: Davef on 22 December, 2020, 02:51:42 pm

Quote from: Greenbank on 22 December, 2020, 02:37:21 pm

I purposely put in just one (although the other bits of rough sea are placed at random so it another could easily appear by random) in order to be underwhelming for people who aren't printing out the final map.

Writing something to fake the whole input is an interesting exercise. One thing I didn't think about is that not only do the edges of adjacent tiles need to match but the 4 tiles in an inner corner all need to have the same symbol ( . or # ) at that corner, which means there's some careful selection of edge "numbers" that need to be done. Ho hum.

To make a puzzle you just start at the top left with a couple of random 10 bit numbers and then work across from there, setting the first bit of the next to be the last bit of the previous and making sure you don’t reuse a number or it’s reverse

That sets the edges for all the tiles. Then throw them up in the air and see how they land.

Title: Re: Advent of Code
Post by: Davef on 22 December, 2020, 04:19:55 pm

Quote from: grams on 22 December, 2020, 02:35:10 pm

Day 22 part 1 was nice and straightforward and satisfying. Part 2 just makes my eyes glaze over.

To see what was going on, for printing purposes I replaced the 50 odd numbers with letters A-ZA-z and ran part 1 again.

If I had a bigger screen I would have used the proper names of the tanks from top trumps.

This led to a better understanding of how to store the data and work efficiently. Then a few optimisations such as caching previous results and looking for simple cases (if there is no recursion you can see straightaway which player will win) and I left it to run on my grindingly slow laptop. It took 20 minutes which is probably 5 minutes on a decent pc. I still feel I am missing something.

Title: Re: Advent of Code
Post by: Pickled Onion on 22 December, 2020, 04:24:18 pm

Quote from: grams on 22 December, 2020, 02:35:10 pm

Day 22 part 1 was nice and straightforward and satisfying. Part 2 just makes my eyes glaze over.

It definitely took me longer to understand the instructions for part 2 than to implement it, given a tidy implementation of part 1.

Day 20 was too much code for very little satisfaction. It looks like a lot of people just couldn't be bothered as I just got round to it today and still < 10,000

Title: Re: Advent of Code
Post by: Greenbank on 22 December, 2020, 09:29:52 pm

Quote from: Davef on 22 December, 2020, 04:19:55 pm

If I had a bigger screen I would have used the proper names of the tanks from top trumps.

With my usual settings (10 point Ubuntu Mono font) I can have a 546x131 char terminal window open on this monitor and, yes, it's completely readable without needing any scaling.

Title: Re: Advent of Code
Post by: grams on 22 December, 2020, 09:47:07 pm

Day 22 here, sort of:
https://docs.google.com/spreadsheets/d/1hMM1Uort-P4v3FoS3QETp7VmuIbxFlj6gUOzQknQLW8/edit?usp=sharing

(click to show/hide)

I actually bothered to write and fully debug a full implementation of Part 2 even though there's absolutely no way I can run it the necessary 2,216,197 times in Google Sheets. So I compared with someone else's code and I've verified it as far as iteration 4000 and I'm confident it's correct. A bit cheating but I definitely put the work in to get my star.

Title: Re: Advent of Code
Post by: Davef on 23 December, 2020, 02:50:38 pm

Day 23 is now chugging away in the background and will take a few hours despite my fine tuning.

There is obviously a better way but I suspect the computer will find the answer before I come up with a better way of doing it.

Title: Re: Advent of Code
Post by: Greenbank on 23 December, 2020, 04:00:14 pm

Day 23 runs in a second for me. The really naive solution in perl I knocked up for part 1 was never going to perform well enough for part 2 so I did it properly in C.

(click to show/hide)

Doubly linked list of nodes in an array.

typedef struct _node {
        int cup;
        struct _node *prev;
        struct _node *next;
} NODE;

#define ONEMILLION 1000000

NODE nodes[ONEMILLION];

Gives me instant access to any node by cup number (via the array) and I can move individual nodes around by changing the prev/next pointers as required.

Each iteration is then just looking up a couple of values in the array (directly to the required nodes, no searching required) and then moving a few of pointers around to shuffle the order of the cups.

3 stars to go (day 25 part 2 is usually just having the other 49 stars).

Title: Re: Advent of Code
Post by: Davef on 24 December, 2020, 09:12:11 am

Day 24 was nice and easy.

Title: Re: Advent of Code
Post by: Greenbank on 24 December, 2020, 10:58:36 am

(click to show/hide)

Various choices of co-ordinate systems: https://www.redblobgames.com/grids/hexagons/

Some (like the cube coordinates) make more sense if you need to calculate distances.

I went with what I've used before, which is like the "Doubled coordinates" (but halved). So E being [1,0] and NE being [0.5,1]

Title: Advent of Code
Post by: Davef on 24 December, 2020, 12:28:42 pm

(click to show/hide)

I just went with unit vectors in the east and south-east directions so e =(1,0) and se=(0,1)

// unit vectors
//  ...................... e     se     sw     w    nw       ne
int u[] = { 0,0,    1,0,   0,1,  -1,1,  -1,0,    0,-1,     1,-1 };


.....
// consider us and all our neighbours
for (int d = 0; d < 14; d+=2)
{
// conisder our selves and our neighbours
int x2 = x+u[d];
int y2 = y+u[d+1];

Title: Re: Advent of Code
Post by: Ben T on 24 December, 2020, 04:19:34 pm

Quote from: Davef on 22 December, 2020, 04:19:55 pm

Quote from: grams on 22 December, 2020, 02:35:10 pm

Day 22 part 1 was nice and straightforward and satisfying. Part 2 just makes my eyes glaze over.

To see what was going on, for printing purposes I replaced the 50 odd numbers with letters A-ZA-z and ran part 1 again.

If I had a bigger screen I would have used the proper names of the tanks from top trumps.

This led to a better understanding of how to store the data and work efficiently. Then a few optimisations such as caching previous results and looking for simple cases (if there is no recursion you can see straightaway which player will win) and I left it to run on my grindingly slow laptop. It took 20 minutes which is probably 5 minutes on a decent pc. I still feel I am missing something.

not seeing what the optimisation is.
Are you actually getting any cache hits?
I've implemented a cache but not getting any hits. I've checked the equality comparison and made it so that it mirrors, i.e. if player 1 won with a hand that player 2's now got, that it returns player 2 winning. But still grinding away with no cache hits.

Title: Re: Advent of Code
Post by: Diver300 on 24 December, 2020, 06:43:17 pm

Quote from: Davef on 24 December, 2020, 12:28:42 pm

(click to show/hide)

I just went with unit vectors in the east and south-east directions so e =(1,0) and se=(0,1)

// unit vectors
//  ...................... e     se     sw     w    nw       ne
int u[] = { 0,0,    1,0,   0,1,  -1,1,  -1,0,    0,-1,     1,-1 };


.....
// consider us and all our neighbours
for (int d = 0; d < 14; d+=2)
{
// conisder our selves and our neighbours
int x2 = x+u[d];
int y2 = y+u[d+1];

(click to show/hide)

I just made an arbitrary decision as to whether odd rows were 1/2 a hexagon to the east for the same number, or half a hexagon to the west compared to even numbered rows. For directions and adding up the number of adjacent hexagons there are so few rules that it's not much code to write out the rules that differ for odd and even rules separately.

I fell foul of the modulus function in javascript, for negative numbers. (n % 2) can give -1 if n is a negative integer. I was testing for n%2 == 1, and didn't realise that was false for all negative integers.

Title: Re: Advent of Code
Post by: Davef on 24 December, 2020, 07:12:17 pm

Quote from: Ben T on 24 December, 2020, 04:19:34 pm

Quote from: Davef on 22 December, 2020, 04:19:55 pm

Quote from: grams on 22 December, 2020, 02:35:10 pm

Day 22 part 1 was nice and straightforward and satisfying. Part 2 just makes my eyes glaze over.

To see what was going on, for printing purposes I replaced the 50 odd numbers with letters A-ZA-z and ran part 1 again.

If I had a bigger screen I would have used the proper names of the tanks from top trumps.

This led to a better understanding of how to store the data and work efficiently. Then a few optimisations such as caching previous results and looking for simple cases (if there is no recursion you can see straightaway which player will win) and I left it to run on my grindingly slow laptop. It took 20 minutes which is probably 5 minutes on a decent pc. I still feel I am missing something.

not seeing what the optimisation is.
Are you actually getting any cache hits?
I've implemented a cache but not getting any hits. I've checked the equality comparison and made it so that it mirrors, i.e. if player 1 won with a hand that player 2's now got, that it returns player 2 winning. But still grinding away with no cache hits.

I get a lot of cache hits but I suppose it could vary with  input could vary but it seems unlikely.
The other optimisation is based on the top trump killer card theorem I just made up. There are scenarios where you can see who will win without actually playing. The other optimisation was how to store the data so that each iteration was very efficient.

Title: Re: Advent of Code
Post by: Davef on 24 December, 2020, 07:41:19 pm

Quote from: Diver300 on 24 December, 2020, 06:43:17 pm

Quote from: Davef on 24 December, 2020, 12:28:42 pm

(click to show/hide)

I just went with unit vectors in the east and south-east directions so e =(1,0) and se=(0,1)

// unit vectors
//  ...................... e     se     sw     w    nw       ne
int u[] = { 0,0,    1,0,   0,1,  -1,1,  -1,0,    0,-1,     1,-1 };


.....
// consider us and all our neighbours
for (int d = 0; d < 14; d+=2)
{
// conisder our selves and our neighbours
int x2 = x+u[d];
int y2 = y+u[d+1];

(click to show/hide)

I just made an arbitrary decision as to whether odd rows were 1/2 a hexagon to the east for the same number, or half a hexagon to the west compared to even numbered rows. For directions and adding up the number of adjacent hexagons there are so few rules that it's not much code to write out the rules that differ for odd and even rules separately.

I fell foul of the modulus function in javascript, for negative numbers. (n % 2) can give -1 if n is a negative integer. I was testing for n%2 == 1, and didn't realise that was false for all negative integers.

(click to show/hide)

I did not bother trying to put it on a square grid at all, so no odd rows. My entire coordinate system was based on e and se.

So for example e=1,0   se=0,1  and everything based on these so   w = -e      nw= -se   ne = e - se

Having a Cartesian coordinate system where axes are perpendicular is familiar but not necessary. Once you are happy with axes not at 90 degrees it all drops into place. The oddity is that there are only six adjacencies to (0,0)  - the two vectors (1,1) and (-1,-1) take you to a non adjacent tiles and must be ignored.

If I have a tile at (6,3) that means 6 steps e and 3 se and (-2,-1) means -2 e ( +2 west ) and -1 se (+1 nw)

Title: Re: Advent of Code
Post by: Greenbank on 24 December, 2020, 09:14:31 pm

Quote from: Davef on 24 December, 2020, 07:12:17 pm

Quote from: Ben T on 24 December, 2020, 04:19:34 pm

Quote from: Davef on 22 December, 2020, 04:19:55 pm

Quote from: grams on 22 December, 2020, 02:35:10 pm

Day 22 part 1 was nice and straightforward and satisfying. Part 2 just makes my eyes glaze over.

To see what was going on, for printing purposes I replaced the 50 odd numbers with letters A-ZA-z and ran part 1 again.

If I had a bigger screen I would have used the proper names of the tanks from top trumps.

This led to a better understanding of how to store the data and work efficiently. Then a few optimisations such as caching previous results and looking for simple cases (if there is no recursion you can see straightaway which player will win) and I left it to run on my grindingly slow laptop. It took 20 minutes which is probably 5 minutes on a decent pc. I still feel I am missing something.

not seeing what the optimisation is.
Are you actually getting any cache hits?
I've implemented a cache but not getting any hits. I've checked the equality comparison and made it so that it mirrors, i.e. if player 1 won with a hand that player 2's now got, that it returns player 2 winning. But still grinding away with no cache hits.

I get a lot of cache hits but I suppose it could vary with  input could vary but it seems unlikely.
The other optimisation is based on the top trump killer card theorem I just made up. There are scenarios where you can see who will win without actually playing. The other optimisation was how to store the data so that each iteration was very efficient.

Not sure what optimisations are required if you implement it as it says. Mine completes in ~5 seconds even with a relatively naive perl implementation. The only caching I do is to prevent it repeating a hand-state as per the instructions, and that's just per game.

My input meant I processed somewhere under 20,000 games and 2.1 million rounds in total.

Early on I forgot to truncate the decks for the sub-games and that meant it had no chance of returning before the heat death of the universe. Sure you aren't doing the same?

Title: Re: Advent of Code
Post by: freeflow on 25 December, 2020, 09:55:49 am

Day 25.  I get an answer which passes the test case and meets all the criteria but its not the correct answer!!

(click to show/hide)

Just in case you clicked in error

(click to show/hide)

The process I used comes from the last paragraph before the question. Everything seems to be misdirection. We are told that a public key plus a number (the loop number) will produce an encryption key.  So all that is necessary is to cache the encryption key for loop values  1 onwards for both public keys until we find an encryption key that already exists in the cache.  So what have I missed?

Title: Re: Advent of Code
Post by: Ben T on 25 December, 2020, 10:07:29 am

Quote from: Greenbank on 24 December, 2020, 09:14:31 pm

Not sure what optimisations are required if you implement it as it says. Mine completes in ~5 seconds even with a relatively naive perl implementation. The only caching I do is to prevent it repeating a hand-state as per the instructions, and that's just per game.

My input meant I processed somewhere under 20,000 games and 2.1 million rounds in total.

Early on I forgot to truncate the decks for the sub-games and that meant it had no chance of returning before the heat death of the universe. Sure you aren't doing the same?

initially, yes, but have changed it to truncate now and doesn't seem any faster.
It seems to get more 'repeats' per 1,000 games than when it didn't truncate.
It's actually a lot slower per 1,000 games but I was hoping that it would mean there would be fewer to go through in total.
My only thought is it could be the list copying in order to keep the state after a sub game as it was when the subgame started that's slowing it down every time.

Title: Re: Advent of Code
Post by: Greenbank on 25 December, 2020, 11:53:31 am

Quote from: freeflow on 25 December, 2020, 09:55:49 am

Day 25.  I get an answer which passes the test case and meets all the criteria but its not the correct answer!!

(click to show/hide)

Just in case you clicked in error

(click to show/hide)

The process I used comes from the last paragraph before the question. Everything seems to be misdirection. We are told that a public key plus a number (the loop number) will produce an encryption key.  So all that is necessary is to cache the encryption key for loop values  1 onwards for both public keys until we find an encryption key that already exists in the cache.  So what have I missed?

Yes, 2020 day 25 took more time reading and re-reading than it did actually writing the code.

(click to show/hide)

I don't think you've got the second part right.

Taking the example of 5764801 and 17807724.

You get the answers 8 and 11 for the loop sizes.

This because:-
7^8 mod 20201227 = 5764801
7^11 mod 20201227 = 17807724

With this information what you then want to compute is:-

5764801^11 mod 20201227
or:-
17807724^8 mod 20201227

They should be the same number because:-

5764801 = 7^8 mod 20201227 so substituting that in gives:-

= (7^8 mod 20201227)^11 mod 20201227
= (7^8)^11 mod 20201227
= 7^(8*11) mod 20201227
= 7^88 mod 20201227

and likewise:-

17807724^8 mod 20201227
= (7^11 mod 20201227)^8 mod 20201227
= (7^11)^8 mod 20201227
= 7^(11*8) mod 20201227
= 7^88 mod 20201227

which is the same expression as above and equals the example answer of 14897079.

Using the numbers from your input you'll find you have much bigger exponents than 11 and 8.

For the second part you can do it one step at a time, or you can use some maths library to calculate x to the power y mod m. (For this kind of thing I use the libgmp C library and the gmp_pwom() function.)

The step by step approach takes ~4 seconds in my perl solution for both parts. I haven't bothered to implement the second part with libgmp as you still need to do the first step by hand.

There are ways to do the first part faster than brute force, algorithms like https://en.wikipedia.org/wiki/Baby-step_giant-step, but it's still computationally expensive and the fundamental problem of finding the answer to an equation of the form e^x mod m is called the Discrete Log problem, and the fact it is very difficult to solve is the foundation of many parts of public-key encryption systems.

Title: Re: Advent of Code
Post by: Davef on 25 December, 2020, 04:12:03 pm

Quote from: Ben T on 25 December, 2020, 10:07:29 am

Quote from: Greenbank on 24 December, 2020, 09:14:31 pm

Not sure what optimisations are required if you implement it as it says. Mine completes in ~5 seconds even with a relatively naive perl implementation. The only caching I do is to prevent it repeating a hand-state as per the instructions, and that's just per game.

My input meant I processed somewhere under 20,000 games and 2.1 million rounds in total.

Early on I forgot to truncate the decks for the sub-games and that meant it had no chance of returning before the heat death of the universe. Sure you aren't doing the same?

initially, yes, but have changed it to truncate now and doesn't seem any faster.
It seems to get more 'repeats' per 1,000 games than when it didn't truncate.
It's actually a lot slower per 1,000 games but I was hoping that it would mean there would be fewer to go through in total.
My only thought is it could be the list copying in order to keep the state after a sub game as it was when the subgame started that's slowing it down every time.

My list copying is minimal as I have each players hand as string. The game state is the two strings concatenated with an * in between.

For efficiency each player is actually slightly more than a string - it also has a number of characters to ignore off the beginning which makes for less work but that is thrown away when I save.

I actually misunderstood the instructions about repeated states in a game and had implemented it globally before I reread and added it locally too.

Title: Re: Advent of Code
Post by: Davef on 25 December, 2020, 04:18:44 pm

Quote from: freeflow on 25 December, 2020, 09:55:49 am

Day 25.  I get an answer which passes the test case and meets all the criteria but its not the correct answer!!

(click to show/hide)

Just in case you clicked in error

(click to show/hide)

The process I used comes from the last paragraph before the question. Everything seems to be misdirection. We are told that a public key plus a number (the loop number) will produce an encryption key.  So all that is necessary is to cache the encryption key for loop values  1 onwards for both public keys until we find an encryption key that already exists in the cache.  So what have I missed?

If you look at the Wikipedia articule on modular arithmetic https://en.wikipedia.org/wiki/Modular_arithmetic there is an efficient c routine for raising a to the power of b.  I still had a copy from last year. That said it would would be relatively quick without it.

Today was my best ranking - in the 2000s because I was on early morning turkey duty.

I also woke up knowing the correct way to do day 23. Problem solving whilst asleep is not something I have done since an undergraduate decades ago.

Title: Re: Advent of Code
Post by: Davef on 25 December, 2020, 09:24:45 pm

Quote from: Ben T on 25 December, 2020, 10:07:29 am

Quote from: Greenbank on 24 December, 2020, 09:14:31 pm

Not sure what optimisations are required if you implement it as it says. Mine completes in ~5 seconds even with a relatively naive perl implementation. The only caching I do is to prevent it repeating a hand-state as per the instructions, and that's just per game.

My input meant I processed somewhere under 20,000 games and 2.1 million rounds in total.

Early on I forgot to truncate the decks for the sub-games and that meant it had no chance of returning before the heat death of the universe. Sure you aren't doing the same?

initially, yes, but have changed it to truncate now and doesn't seem any faster.
It seems to get more 'repeats' per 1,000 games than when it didn't truncate.
It's actually a lot slower per 1,000 games but I was hoping that it would mean there would be fewer to go through in total.
My only thought is it could be the list copying in order to keep the state after a sub game as it was when the subgame started that's slowing it down every time.

I did have another optimisation that gave an answer in fractions of a second. Unfortunately the wrong answer. It is has been bothering me why it didn’t work and I just realised so I now have a solution that only takes a few seconds.

Title: Re: Advent of Code
Post by: Croft on 26 December, 2020, 08:07:12 am

(click to show/hide)

Quote from: Greenbank on 25 December, 2020, 11:53:31 am

For the second part you can do it one step at a time, or you can use some maths library to calculate x to the power y mod m. (For this kind of thing I use the libgmp C library and the gmp_pwom() function.)

The step by step approach takes ~4 seconds in my perl solution for both parts. I haven't bothered to implement the second part with libgmp as you still need to do the first step by hand. [my emphasis]

There are ways to do the first part faster than brute force, algorithms like https://en.wikipedia.org/wiki/Baby-step_giant-step, but it's still computationally expensive and the fundamental problem of finding the answer to an equation of the form e^x mod m is called the Discrete Log problem, and the fact it is very difficult to solve is the foundation of many parts of public-key encryption systems.

If you have to iterate to find loop size, you might as well use the same loop to generate the private key as a simple multiplication and modulus is cheap:

long findPrivate (long card, long door)
{
  while (card != cardPublic)
  {
    card = (7*card) % 20201227;
    door = (doorPublic*door) % 20201227;
  }
  return door;
}

In Java, this takes 60 milliseconds on my machine.

Title: Re: Advent of Code
Post by: Ben T on 26 December, 2020, 10:29:59 am

Quote from: Davef on 25 December, 2020, 09:24:45 pm

Quote from: Ben T on 25 December, 2020, 10:07:29 am

Quote from: Greenbank on 24 December, 2020, 09:14:31 pm

Not sure what optimisations are required if you implement it as it says. Mine completes in ~5 seconds even with a relatively naive perl implementation. The only caching I do is to prevent it repeating a hand-state as per the instructions, and that's just per game.

My input meant I processed somewhere under 20,000 games and 2.1 million rounds in total.

Early on I forgot to truncate the decks for the sub-games and that meant it had no chance of returning before the heat death of the universe. Sure you aren't doing the same?

initially, yes, but have changed it to truncate now and doesn't seem any faster.
It seems to get more 'repeats' per 1,000 games than when it didn't truncate.
It's actually a lot slower per 1,000 games but I was hoping that it would mean there would be fewer to go through in total.
My only thought is it could be the list copying in order to keep the state after a sub game as it was when the subgame started that's slowing it down every time.

I did have another optimisation that gave an answer in fractions of a second. Unfortunately the wrong answer. It is has been bothering me why it didn’t work and I just realised so I now have a solution that only takes a few seconds.

hmm, weird. Rewrote it in c++ and it gets the correct answer in under a second, with about 14,000 games. No idea what the previous program was doing.

Title: Re: Advent of Code
Post by: Davef on 26 December, 2020, 10:51:39 am

Quote from: Ben T on 26 December, 2020, 10:29:59 am

Quote from: Davef on 25 December, 2020, 09:24:45 pm

Quote from: Ben T on 25 December, 2020, 10:07:29 am

Quote from: Greenbank on 24 December, 2020, 09:14:31 pm

Not sure what optimisations are required if you implement it as it says. Mine completes in ~5 seconds even with a relatively naive perl implementation. The only caching I do is to prevent it repeating a hand-state as per the instructions, and that's just per game.

My input meant I processed somewhere under 20,000 games and 2.1 million rounds in total.

Early on I forgot to truncate the decks for the sub-games and that meant it had no chance of returning before the heat death of the universe. Sure you aren't doing the same?

initially, yes, but have changed it to truncate now and doesn't seem any faster.
It seems to get more 'repeats' per 1,000 games than when it didn't truncate.
It's actually a lot slower per 1,000 games but I was hoping that it would mean there would be fewer to go through in total.
My only thought is it could be the list copying in order to keep the state after a sub game as it was when the subgame started that's slowing it down every time.

I did have another optimisation that gave an answer in fractions of a second. Unfortunately the wrong answer. It is has been bothering me why it didn’t work and I just realised so I now have a solution that only takes a few seconds.

hmm, weird. Rewrote it in c++ and it gets the correct answer in under a second, with about 14,000 games. No idea what the previous program was doing.

Your computer is faster than my old laptop.

Title: Advent of Code
Post by: Davef on 26 December, 2020, 10:55:17 am

My day 23 part b cups speedy solution minimal version which after initialisation is technically one line of c (no curly brackets). It s about as fast as it can be too

(click to show/hide)

Code: [Select]


// puzzle input
const char *s = "389125467";
int n0 = strlen(s), n = 1000000;

// an array of 1 million integers.
int *a = new int [n+1];

// store puzzle input
for (int i=0,c=0,y=0,f=0,d=0; i < n0; i++) a[s[i]-'0']=s[(i+1)%n0]-'0';

// and the extra 1 million ish entries
for (i++,a[s[i-2]-'0'] = i,a[n] = *s-'0'; i<n ; i++) a[i]=i+1;

// do the business 10 million times
for (i=0,c=s[0]-'0';i<10000000&&(y=a[a[a[c]]],f=a[c]);a[c]=a[y],a[y]=a[d],a[d]=f,c=a[c],i++)
  for (d=c;d==c||d==f||d==a[f]||d==y; d=(d-1<1)?n:d-1) ; // empty loop, max 4 decrements to dest

return (__int64)a[1] * a[a[1]];  // return result



Title: Re: Advent of Code
Post by: Greenbank on 26 December, 2020, 04:21:14 pm

(click to show/hide)

Quote from: Croft on 26 December, 2020, 08:07:12 am

If you have to iterate to find loop size, you might as well use the same loop to generate the private key as a simple multiplication and modulus is cheap:

long findPrivate (long card, long door)
{
  while (card != cardPublic)
  {
    card = (7*card) % 20201227;
    door = (doorPublic*door) % 20201227;
  }
  return door;
}

Sure that gets you the answer, but far from optimal.

For this problem even the most naive solution gives the answer quite quickly, but there are better ways to do it (as someone has mentioned already). If the question had much bigger numbers the naive solution would not have been workable.

If you want to get something to the power of 8 you can do it the naive way and use 7 multiplications and 7 modulus operations, e.g.

x=7
x*=7 ; x%=m;
x*=7 ; x%=m;
x*=7 ; x%=m;
x*=7 ; x%=m;
x*=7 ; x%=m;
x*=7 ; x%=m;
x*=7 ; x%=m;

Or you can do it in 3 multiplications and 3 modulus operations:-

x=7
x*=x ; x%=m; # current value is x^2 mod m
x*=x ; x%=m; # current value is x^4 mod m
x*=x ; x%=m; # current value is x^8 mod m

To raise to an arbitrary exponent you effectively look at the binary representation of the exponent and sometimes multiply in another x before you square the number you have as you go along.

So to raise something to the power 12413864 (for example) you can do 12413863 mulitply/modulus operations, or just ~30 by using the more optimal way.

As always with AoC, you can stop as soon as you've got the answer, or you can choose to delve a little deeper.

Title: Re: Advent of Code
Post by: Pickled Onion on 26 December, 2020, 07:42:22 pm

Done. Not helped by the fact that the dot net debugger crashes on the Apple M1 chip when stepping off a break point. Had to go back to old school debugging by print statements.

Now to go back to 2019 - I stopped at day 15. This year's seems tamer than previous years, or perhaps it's just easier with practice.

Title: Re: Advent of Code
Post by: Ben T on 27 December, 2020, 09:43:28 pm

For day 23 part 2 my program produces the right numbers for the example input 389125467 => (934001 x 159792 = 149245887792)
but wrong for my actual input.
Bloody annoying.
Definitely not overflown as I've converted to 64 bit numbers before making the product.
Struggling to see how it would be right for the example but wrong for my actual.
Would anyone who's got it right mind posting their input and the two numbers clockwise from 1 please and the product?
Runs in a second or two so easy for me to check

Title: Advent of Code
Post by: Davef on 27 December, 2020, 10:03:05 pm

Quote from: Ben T on 27 December, 2020, 09:43:28 pm

For day 23 part 2 my program produces the right numbers for the example input 389125467 => (934001 x 159792 = 149245887792)
but wrong for my actual input.
Bloody annoying.
Definitely not overflown as I've converted to 64 bit numbers before making the product.
Struggling to see how it would be right for the example but wrong for my actual.
Would anyone who's got it right mind posting their input and the two numbers clockwise from 1 please and the product?
Runs in a second or two so easy for me to check

Your puzzle answer was 412990492266.

Both parts of this puzzle are complete! They provide two gold stars: **

At this point, all that is left is for you to admire your Advent calendar.

Your puzzle input was 963275481.


You could also test your input against my code posted a few posts above #1103

The only bit that needed 64 bit was the final multiply

Title: Re: Advent of Code
Post by: Ben T on 28 December, 2020, 09:41:41 am

Quote from: Davef on 27 December, 2020, 10:03:05 pm

Quote from: Ben T on 27 December, 2020, 09:43:28 pm

For day 23 part 2 my program produces the right numbers for the example input 389125467 => (934001 x 159792 = 149245887792)
but wrong for my actual input.
Bloody annoying.
Definitely not overflown as I've converted to 64 bit numbers before making the product.
Struggling to see how it would be right for the example but wrong for my actual.
Would anyone who's got it right mind posting their input and the two numbers clockwise from 1 please and the product?
Runs in a second or two so easy for me to check

Your puzzle answer was 412990492266.

Both parts of this puzzle are complete! They provide two gold stars: **

At this point, all that is left is for you to admire your Advent calendar.

Your puzzle input was 963275481.


You could also test your input against my code posted a few posts above #1103

The only bit that needed 64 bit was the final multiply

Weird. My code gets the right answer for your input.

But still claims to be wrong for my own. Oh well, I'll give your code a compile and see what it gets...

Title: Re: Advent of Code
Post by: Ben T on 28 December, 2020, 12:11:32 pm

Quote from: Ben T on 28 December, 2020, 09:41:41 am

Your puzzle answer was 412990492266.

Both parts of this puzzle are complete! They provide two gold stars: **

At this point, all that is left is for you to admire your Advent calendar.

Your puzzle input was 963275481.


You could also test your input against my code posted a few posts above #1103

The only bit that needed 64 bit was the final multiply

Weird. My code gets the right answer for your input.

But still claims to be wrong for my own. Oh well, I'll give your code a compile and see what it gets...
[/quote]
Got it now, thanks davef - was a bug in setting up the initial data.
Was using a linked list and wasn't setting up the initial data correctly, so if the input was 315679824, I was setting e.g. 2.next = 4, and 4.prev = 2, and setting 4's next to 10.... but forgot to set 10's prev to 4.
Might try and create a generic linked list class, as the code is a bit of a mess and a pita to debug.

Title: Re: Advent of Code
Post by: Ben T on 28 December, 2020, 12:16:23 pm

Quote from: Ben T on 28 December, 2020, 12:11:32 pm

Quote from: Ben T on 28 December, 2020, 09:41:41 am

Quote

Your puzzle answer was 412990492266.

Both parts of this puzzle are complete! They provide two gold stars: **

At this point, all that is left is for you to admire your Advent calendar.

Your puzzle input was 963275481.


You could also test your input against my code posted a few posts above #1103

The only bit that needed 64 bit was the final multiply

Weird. My code gets the right answer for your input.

But still claims to be wrong for my own. Oh well, I'll give your code a compile and see what it gets...

Got it now, thanks davef - was a bug in setting up the initial data.
Was using a linked list and wasn't setting up the initial data correctly, so if the input was 315679824, I was setting e.g. 2.next = 4, and 4.prev = 2, and setting 4's next to 10.... but forgot to set 10's prev to 4.
Might try and create a generic linked list class, as the code is a bit of a mess and a pita to debug.

My somewhat more verbose than your code:

(click to show/hide)

Code: [Select]

class cup
{
public:
    cup* prev;
    cup* next;
    int num;
};

int main(int argc, char** argv)
{
    int cupcount = 1000000;
    cup* cups = new cup[cupcount+1];

    int len = strlen(argv[1]);
    for (int i = 1; i <= cupcount; i++)
    {
        cups[i].prev = i == 1 ? cups+cupcount : cups+i-1;
        cups[i].next = i == cupcount ? cups+1 : cups+i+1;
        cups[i].num = i;
    }

    //arrange the (first) 10 cups according to the input
    for(int i = 1; i <= len; i++)
    {
        int cupnum = (int)(argv[1][i-1] - '0');
        int prevcupnum = i > 1 ? (int)(argv[1][i-2] - '0') : cupcount;
        cups[cupnum].prev = cups + prevcupnum;

        int nextcupnum = i < len ? (int)(argv[1][i] - '0') :
            (cupcount > len ? len + 1 : (int)(argv[1][0] - '0'));
        cups[cupnum].next = cups + nextcupnum;
    }
    if(cupcount > len) cups[len+1].prev = cups + (int)(argv[1][len-1] - '0'); // << the ommission of this line was the bug

    int firstcup = (int)(argv[1][0] - '0');
    cups[cupcount].next = cups+firstcup;

    int moves = 0;
    cup* current;

    for(current = cups+firstcup; moves++ < 10000000 ;)
    {
        cup* pickup_first = current->next;
        cup* pickup_last = pickup_first->next->next;

        //detach the ones picked up

        pickup_first->prev->next = pickup_last->next;
        pickup_last->next->prev = pickup_first->prev;

        int dest = current->num;

        do {
            if(--dest == 0) dest = cupcount;
           
        } while(
                pickup_first->num == dest ||
                pickup_first->next->num == dest ||
                pickup_first->next->next->num == dest);

        cup* insertion_before = cups+dest;
        cup* insertion_after = insertion_before->next;

        insertion_before->next = pickup_first;
        pickup_first->prev = insertion_before;
        pickup_last->next = insertion_after;
        insertion_after->prev = pickup_last;

        current = current->next;
       
    }

    // part 1

    // int count = 1;
    // for(cup* c = (cups+1)->next; count++ < cupcount; c = c->next)
    // {
    //     std::cout << c->num;
    // }
    // std::cout << std::endl;

    // part 2 (cup count and num moves changes)
    std::cout << cups[1].next->num << ", " << cups[1].next->next->num << " = " << (long)cups[1].next->num * cups[1].next->next->num << std::endl;


Title: Re: Advent of Code
Post by: Greenbank on 28 December, 2020, 05:52:16 pm

Implemented day 25 properly and got the time down to 1189usec for my input.

It finds the answer for the example input in 102usec.

(Note usec not msec. 1189usec is ~1.2msec.)

Title: Re: Advent of Code
Post by: Davef on 28 December, 2020, 06:27:59 pm

Quote from: Greenbank on 28 December, 2020, 05:52:16 pm

Implemented day 25 properly and got the time down to 1189usec for my input.

It finds the answer for the example input in 102usec.

(Note usec not msec. 1189usec is ~1.2msec.)

It is a flawed security system if it can be broken by some arithmetic !

Title: Re: Advent of Code
Post by: Pickled Onion on 28 December, 2020, 07:55:08 pm

(day 15 2019)

Quote from: Greenbank on 16 December, 2019, 01:06:06 am

Late to it today as I'd been out all day at a family party. Chased a few silly bugs in a dreadful implementation but got it done.

The way I'd implemented meant it was only a very small change required to do part 2.

Loving the use of IntCode computers to provide inputs (i.e. the maze) that can't be analysed directly.

(click to show/hide)

2445 moves to discover the entire map, CPU time was 2.783s including the IntCode computer process time

Bah! Mapped out the route to the Oxygen by finding the walls and marking any dead-ends on backtrack. This gave all the map that was needed and the route back to origin was then the only one left.

Now for part two I need the whole map!  :facepalm:

Title: Re: Advent of Code
Post by: Greenbank on 28 December, 2020, 09:25:08 pm

Quote from: Davef on 28 December, 2020, 06:27:59 pm

Quote from: Greenbank on 28 December, 2020, 05:52:16 pm

Implemented day 25 properly and got the time down to 1189usec for my input.

It finds the answer for the example input in 102usec.

(Note usec not msec. 1189usec is ~1.2msec.)

It is a flawed security system if it can be broken by some arithmetic !

And I hadn't bothered optimising it. Down to 240usec now.

It's not just arithmetic, it's searching the full search space to solve a^e = x mod m (i.e. finding e for a given a, x and m). It just does it in a more efficient way with a lot fewer calculations.

(In this example 7^e = x mod 20201227)

The security system is a little better if you use much bigger primes. 20201227 is a tad on the small size.

If I give you even a 256-bit prime such as 90903494037702082433862493857994179414185677901950849383197625766750833066817 then it's not so quick or easy.

Title: Advent of Code
Post by: Davef on 29 December, 2020, 09:28:47 am

Here is my day 25. I think it is quite efficient both in terms of performance and typing and is surprisingly readable. With the exception of the sea monster I have them all down to a handful of lines of code. Just fine tuning my 4d life.

(click to show/hide)

for (__int64 c=2084668,d=3704642,m=20201227,e,f,g,h=g=f=e=1;e!=c&&f!=d;e=e*7%m,f=f*7%m,g=g*c%m,h=h*d%m)
   ;
return e==c?h:g;

Or if you were happy to take a punt on which key was easier to find you could remove f and g but if one was much easier than the other it could be much slower

(click to show/hide)

for (__int64 c=2084668,d=3704642,m=20201227,e,h=e=1;e!=c;e=e*7%m,h=h*d%m)
   ;
return h;

Title: Re: Advent of Code
Post by: Greenbank on 01 January, 2021, 05:27:29 pm

Can't see it mentioned anywhere but there's Project Euler too, for anyone wanting to continue with problems throughout the year.

I've made a thread for it here: https://yacf.co.uk/forum/index.php?topic=117960.0 so not to clutter up this one (which we can save for AoC).

Title: Re: Advent of Code
Post by: Pickled Onion on 01 January, 2021, 06:27:25 pm

Quote from: Greenbank on 01 January, 2021, 05:27:29 pm

Can't see it mentioned anywhere but there's Project Euler too, for anyone wanting to continue with problems throughout the year.

I've made a thread for it here: https://yacf.co.uk/forum/index.php?topic=117960.0 so not to clutter up this one (which we can save for AoC).

Thanks, but I think I'm going to be busy going over the previous years' ones I gave up on at the time. :-)

Title: Re: Advent of Code
Post by: Pickled Onion on 02 January, 2021, 09:06:51 pm

Quote from: Greenbank on 17 December, 2019, 11:24:40 am

Day 17 (2019). Another example of READ THE TEXT, then READ IT AGAIN.

The "obvious" route, of going straight across each intersection, might have led to a final set of instructions that could not be compressed to fit the input instruction rules.

Having to then go back and make the first part of part 2 output every possible permutation until one that could be compressed adequately would have been less fun.

A transcription error meant I missed the obvious route (and didn't look for spoilers). So I implemented the "every permutation" with linked lists and recursion. It was a rather laborious, but popped out the answer very quickly.

Title: Re: Advent of Code
Post by: Croft on 30 November, 2021, 06:59:15 pm

It's that time of year again. Anyone doin'?

https://adventofcode.com/

Private leaderboard code that YACF people have been using for a few years now: 48462-ea506236

Title: Re: Advent of Code
Post by: Pingu on 02 December, 2021, 11:31:00 pm

First two days weren't too hard. But then I probably think that every year  :P

Title: Re: Advent of Code
Post by: perpetual dan on 04 December, 2021, 04:59:34 pm

We did a bit of this as learning with interns at work. I seem to have done four days now, luring me in :)

Title: Re: Advent of Code
Post by: Diver300 on 06 December, 2021, 05:33:27 am

Day 6

(click to show/hide)

There is no need to keep tabs on individual fish. A small array of how many fish of each age there are is all that's needed. Then the number of calculations don't increase as the fish multiply.

Title: Re: Advent of Code
Post by: perpetual dan on 07 December, 2021, 08:08:55 pm

Quote from: Diver300 on 06 December, 2021, 05:33:27 am

Day 6

(click to show/hide)

There is no need to keep tabs on individual fish. A small array of how many fish of each age there are is all that's needed. Then the number of calculations don't increase as the fish multiply.

(click to show/hide)

Or buy a bigger computer. But your approach was faster for me as well!

Title: Re: Advent of Code
Post by: Diver300 on 08 December, 2021, 10:28:50 am

Quote from: perpetual dan on 07 December, 2021, 08:08:55 pm

Quote from: Diver300 on 06 December, 2021, 05:33:27 am

Day 6

(click to show/hide)

There is no need to keep tabs on individual fish. A small array of how many fish of each age there are is all that's needed. Then the number of calculations don't increase as the fish multiply.

(click to show/hide)

Or buy a bigger computer. But your approach was faster for me as well!

(click to show/hide)

Lots of puzzles from previous years started with something that could be solved with brute force, but then part 2 took amount of computing power needed beyond my PC. Therefore from the start I was on the lookout for something that took less computing power. The final answer for day 6 was around 1.6 million million, so having to have arrays that big is a large fraction of a PC's power. Simply having an array of nine numbers that are each that big is much quicker.

Title: Re: Advent of Code
Post by: perpetual dan on 08 December, 2021, 10:41:53 am

Quote from: Diver300 on 08 December, 2021, 10:28:50 am

Quote from: perpetual dan on 07 December, 2021, 08:08:55 pm

Quote from: Diver300 on 06 December, 2021, 05:33:27 am

Day 6

(click to show/hide)

There is no need to keep tabs on individual fish. A small array of how many fish of each age there are is all that's needed. Then the number of calculations don't increase as the fish multiply.

(click to show/hide)

Or buy a bigger computer. But your approach was faster for me as well!

(click to show/hide)

Lots of puzzles from previous years started with something that could be solved with brute force, but then part 2 took amount of computing power needed beyond my PC. Therefore from the start I was on the lookout for something that took less computing power. The final answer for day 6 was around 1.6 million million, so having to have arrays that big is a large fraction of a PC's power. Simply having an array of nine numbers that are each that big is much quicker.

My day job tends to call on that kind of optimization, so i had a similar predisposition :)

In contrast, my solution for today's feels quite clunky. Though coding before coffee might be an issue.

Title: Re: Advent of Code
Post by: Diver300 on 08 December, 2021, 01:10:56 pm

Quote from: perpetual dan on 08 December, 2021, 10:41:53 am

Quote from: Diver300 on 08 December, 2021, 10:28:50 am

Quote from: perpetual dan on 07 December, 2021, 08:08:55 pm

Quote from: Diver300 on 06 December, 2021, 05:33:27 am

Day 6

(click to show/hide)

There is no need to keep tabs on individual fish. A small array of how many fish of each age there are is all that's needed. Then the number of calculations don't increase as the fish multiply.

(click to show/hide)

Or buy a bigger computer. But your approach was faster for me as well!

(click to show/hide)

Lots of puzzles from previous years started with something that could be solved with brute force, but then part 2 took amount of computing power needed beyond my PC. Therefore from the start I was on the lookout for something that took less computing power. The final answer for day 6 was around 1.6 million million, so having to have arrays that big is a large fraction of a PC's power. Simply having an array of nine numbers that are each that big is much quicker.

My day job tends to call on that kind of optimization, so i had a similar predisposition :)

In contrast, my solution for today's feels quite clunky. Though coding before coffee might be an issue.

Day 8
Even though today's was a bit clunky, the only solution that I saw didn't involve going round anything more than a handful of times.

(click to show/hide)

To work out which segment was which, all the possibles were there, so it was a matter of doing stuff like "find the segments in the 4 that aren't in the 1, and find which of those is missing from one of the instances of 6 segments lit".
I looked up how to put the results into alphabetical order in Javascript in order to compare against  a standard list of which letters are lit for 0 - 9 in seven segement.

Title: Re: Advent of Code
Post by: Pingu on 08 December, 2021, 03:49:47 pm

Quote from: perpetual dan on 08 December, 2021, 10:41:53 am

Quote from: Diver300 on 08 December, 2021, 10:28:50 am

Quote from: perpetual dan on 07 December, 2021, 08:08:55 pm

Quote from: Diver300 on 06 December, 2021, 05:33:27 am

Day 6

(click to show/hide)

There is no need to keep tabs on individual fish. A small array of how many fish of each age there are is all that's needed. Then the number of calculations don't increase as the fish multiply.

(click to show/hide)

Or buy a bigger computer. But your approach was faster for me as well!

(click to show/hide)

Lots of puzzles from previous years started with something that could be solved with brute force, but then part 2 took amount of computing power needed beyond my PC. Therefore from the start I was on the lookout for something that took less computing power. The final answer for day 6 was around 1.6 million million, so having to have arrays that big is a large fraction of a PC's power. Simply having an array of nine numbers that are each that big is much quicker.

My day job tends to call on that kind of optimization, so i had a similar predisposition :)

In contrast, my solution for today's feels quite clunky. Though coding before coffee might be an issue.

(click to show/hide)

I eventually found a fairly simple spreadsheet solution for day 6

  :P

Title: Re: Advent of Code
Post by: Diver300 on 12 December, 2021, 09:31:45 am

Day 12
Part 1

(click to show/hide)

For this I had an array of routes though the caves. The array started with a single entry of "start". For each route that didn't finish with "end", the code would look for a possible next cave, that wasn't a duplicate if it was lower case. If none were found, the route would be deleted. The first possible next cave would be added to the route. If more than one were found, additional routes would be added to the array, each copying the parent route up to the new final step. It worked first time, after a couple of syntax errors were found

Part 2

(click to show/hide)

I added another array, of the same size as the array of routes. The second array simply flagged whether the route had visited a lower case cave. It should have been a quick change, but I made a syntax error that wasn't flagged as such

Quote

if (a == 1);
   {
   b = 2;
   }

when I should have written:-

if (a == 1)
   {
   b = 2;
   }

Once I had sorted that, it took me ages to spot that I hadn't deleted an entry to the second array at the same place where I deleted an entry to the main array.  :facepalm:

Title: Re: Advent of Code
Post by: perpetual dan on 12 December, 2021, 10:38:36 pm

Day 12 I got the first bit done ok, then had stuff to do.

Part two broke my previous (learning a new library) approach. Starting again with something simpler got me there.

Deliberate loops in a routing algorithm as part of the spec was quite upsetting though.

Title: Re: Advent of Code
Post by: Diver300 on 14 December, 2021, 08:17:53 am

Day 14

(click to show/hide)

Having spotted the bear trap in day 6, I proceeded to fall into the same trap in day 14.
Part 1 has a reasonable length of the polymer. With a start of 20, and approximately doubling ten  times, it's under 20000 long, and a program can keep track of each item.
Part 2 calls for 40 steps of approximately doubling, ending up with something huge and my attempt that solved part 1 in an instant would take years to do part 2 and I probably wouldn't have enough memory on my PC.
There was never any need to keep track of each item in the polymer. It's much quicker to count the pairs. I had an array 26x26 of pairs of letters, and each entry is the number of such pairs.

Title: Re: Advent of Code
Post by: perpetual dan on 14 December, 2021, 11:55:20 am

Quote from: Diver300 on 14 December, 2021, 08:17:53 am

Day 14

(click to show/hide)

Having spotted the bear trap in day 6, I proceeded to fall into the same trap in day 14.
Part 1 has a reasonable length of the polymer. With a start of 20, and approximately doubling ten  times, it's under 20000 long, and a program can keep track of each item.
Part 2 calls for 40 steps of approximately doubling, ending up with something huge and my attempt that solved part 1 in an instant would take years to do part 2 and I probably wouldn't have enough memory on my PC.
There was never any need to keep track of each item in the polymer. It's much quicker to count the pairs. I had an array 26x26 of pairs of letters, and each entry is the number of such pairs.

I took a couple of dead ends before getting it working in reasonable time today, but I still got my best part two position so far without any alarm clock shenanigans.

(click to show/hide)

Your approach is neat. I like it.

I broke out the cache and still got an answer in about 0.3s.
I wrote recursive depth first application of rules, then there's enough repeating of pair and depth to break the bottleneck. It's a fairly small and repetitive value space after all.

Title: Re: Advent of Code
Post by: Diver300 on 15 December, 2021, 07:03:30 am

Day 15
My code works for the demo, parts 1 and 2, and for my puzzle input part 1, and it appears to work for my puzzle input in part 2, but it gives the wrong answer. I am a bit stuck now.

Edit. Found the problem.

(click to show/hide)

The searching for better routes has to look up and left as well as down and right. I had stopped looking up and left at 100, and forgot to increase that when the map was 5 times larger.

Title: Re: Advent of Code
Post by: perpetual dan on 15 December, 2021, 01:41:08 pm

(click to show/hide)

My head wasn't really in it today, so I looked up Dijkstra with a priority queue and did that.
I still have a sense that I've missed some optimization, but ought to do some work :)

Title: Re: Advent of Code
Post by: Diver300 on 25 December, 2021, 08:13:36 pm

Day 23 was solved with (effectively) pencil and paper.

I did use a computer to spot my stupid adding up mistake.

Title: Re: Advent of Code
Post by: Morat on 22 November, 2022, 10:15:15 am

gentle nudge?

Title: Re: Advent of Code
Post by: Diver300 on 30 November, 2022, 11:38:34 pm

The countdown has started.

Title: Re: Advent of Code
Post by: freeflow on 01 December, 2022, 08:00:47 am

I've been doing advent of code in VBA for the past few years, but I've now upgraded to twinbasic.  Over the years I've developed a library to help eliminate a lot of the VBA boilerplate code needed to solve AoC problems.  So this morning I was delighted (and astonished) when my library worked well in solving the day 1 problem.

(click to show/hide)

Code: [Select]

Dim myResult As Long = Seq.Deb(Filer.GetFileAsArrayOfStrings(AoC & Today, vbCrLf & vbCrLf)) _
            .MapIt(mpSplitToSubStr(ToSeq, vbCrLf)) _
            .MapIt(mpInner(mpConvert(ToLong))) _
            .ReduceIt(rdInner(rdSum)) _
            .sort _
            .last

Title: Re: Advent of Code
Post by: Pickled Onion on 03 December, 2022, 07:50:06 pm

I had to look up TwinBasic, and found:

Quote

twinBASIC is an exciting new project that aims to provide a full replacement IDE and compiler for VB6

For the love of $Deity WHY??

Title: Re: Advent of Code
Post by: Pickled Onion on 10 December, 2022, 06:20:48 pm

Well day 9 pt 2 got me. The test data got the right answer, and printing out the visited points exactly matched the example, but the final answer was wrong. Only comparing the intermediates showed that I'd misunderstood the rules.

Bah! This is not the first one this year where the tests have passed for the wrong implementation.

Title: Re: Advent of Code
Post by: Diver300 on 10 December, 2022, 08:56:30 pm

Quote from: Pickled Onion on 10 December, 2022, 06:20:48 pm

Well day 9 pt 2 got me. The test data got the right answer, and printing out the visited points exactly matched the example, but the final answer was wrong. Only comparing the intermediates showed that I'd misunderstood the rules.

Bah! This is not the first one this year where the tests have passed for the wrong implementation.

I had the same.

I got program to draw out the path of the last knot in the rope, and realised that my first attempt had gaps in the path.

Title: Re: Advent of Code
Post by: freeflow on 10 December, 2022, 11:01:02 pm

One of the joys of advent of code is teaching folks about how assumptions are made.  The problems need very careful reading to ensure you have eliminated stuff that has been included unnecessarily and stuff which is implicit - usually hidden in plain view in the details of the examples.  God knows how people who don't have English as a first language cope, or maybe its easier as things are read properly rather than quickly scanned for 'salient' points.

Title: Re: Advent of Code
Post by: Diver300 on 11 December, 2022, 08:26:12 am

Day 11 needed a trick so that the solution didn't become unmanageable for a normal computer.

(click to show/hide)

The "levels of worry" get to be extremely large numbers.
The tests each monkey does are whether the "levels of worry" is divided by a prime number.
The "levels of worry" only increase by multiplying by integers or adding integers.
The "levels of worry" can be reduced by taking their modulus using the product of all the primes used by all the monkeys. In my case that was the first 8 primes, so the numbers could be kept down to less than 10 million.
After that the sequence could be run in a few seconds in javascipt.

Title: Re: Advent of Code
Post by: Diver300 on 15 December, 2022, 09:08:21 am

For Day 15, the scale is too large for a brute-force solution.

(click to show/hide)

I divided the possible 4 million x 4 million grid into 10,000 squares of side 40,000.
I worked out if the midpoint of each square was more or less than 40,000 away from a point that could not be detected by a sensor.
If the midpoint was more than 40,000 away from a point that could be detected, the whole square could be discounted. That only left me with 50 squares.
Then each of the 50 squares was divided into 40,000 smaller squares of 200 x 200.
Then I used a brute-force attack to check every single point in each one of the smallest squares that couldn't be discounted. There were 3185 to check.
In all the program checked how close a point was to a point that could be detected 129,410,000 times, so it only needed to check one in every 123,000 points. It took about 20 seconds to run in Javascript.
 

Title: Re: Advent of Code
Post by: Diver300 on 18 December, 2022, 08:51:45 pm

Day 16, part 2.
The code that got the right answer for me needed to try 8,142,958,394 possibilities and took something like an hour to run.
The same code run on the example only needed 37,623 possibilities and runs almost instantly.

(click to show/hide)

I first worked out the distances from each cave to each other cave, then I removed the caves with valves with no flow from the possibilities.
The final answer was 6 valves opened by the person, and 5 by the elephant. With 15 valves there are an enormous number of possibilities.

I have tried to make sure that a pair of routes was only checked once, rather than once with the person doing the first, and once with the elephant doing the first, but I'm not sure if I succeeded, but that would have only doubled the number of routes checked.

Edit:- With a robust way of checking for duplicates, it only took 40 mins to run (Javascript on Chrome) and it tried 4,106,390,647 possibilities.

I can't see any more optimisations that could be done.

Title: Re: Advent of Code
Post by: Diver300 on 23 December, 2022, 12:12:45 pm

Day 22: Monkey Map Part 2
The statistics show that quite a low proportion of the solutions of the first part got converted into solutions of the second part.

The YACF private leaderboard has 5 solutions to the first part and only 3 to the second part. There are only 4 first part only solutions for the whole of the private leaderboard, and two of those are for Day 22.

(click to show/hide)

The puzzle input is to be folded into a cube, and the path traced over the edges.

I don't know if others are trying to find a general solution, but I found a solution specific to the layout in my puzzle input.

Code: [Select]

     C  D
    ######
   B######F
    ######
    ### G
   A###g
  a ###
 ######
b######f
 ######
 ### E
c###e
 ###
  d
That is the layout of my puzzle input with each square of 9 #'s  representing a square of 50 x 50 of my puzzle input.
The letters indicate where the edges of the cube join.

My solution would only work for the same layout, but for any content within each 50 x 50 square.

There are 12 edges in cube. 5 of those edges are already joined in the puzzle input, so there are 7 edges, each of which can be approached from two directions, so that is 14 rules for crossing edges.

I just wrote out and coded each of the 14 rules by hand. Each was a couple of conditions and a couple of equations. For me that was a lot quicker than trying to write the code to write those rules.

Title: Re: Advent of Code
Post by: Diver300 on 01 December, 2023, 08:35:50 am

Advent of code 2023 has started.

Day 1

(click to show/hide)

My puzzle input has 16 instances of "oneight" and 16 instances of "eightwo"

Title: Re: Advent of Code
Post by: R_nger on 01 December, 2023, 06:52:07 pm

Quote from: Diver300 on 01 December, 2023, 08:35:50 am

Advent of code 2023 has started.

Day 1

(click to show/hide)

My puzzle input has 16 instances of "oneight" and 16 instances of "eightwo"

That’s plain greedy  ;)

Title: Re: Advent of Code
Post by: Pickled Onion on 02 December, 2023, 10:58:48 am

That was a bit sneaky for a day 1. Depending on your approach it would have been quite easy to pass a test on the sample but get the wrong answer on the puzzle.

I see quite a few people in the private leaderboard haven't bothered completing part 2 yet.

Title: Re: Advent of Code
Post by: Diver300 on 02 December, 2023, 12:53:53 pm

Quote from: Pickled Onion on 02 December, 2023, 10:58:48 am

That was a bit sneaky for a day 1. Depending on your approach it would have been quite easy to pass a test on the sample but get the wrong answer on the puzzle.

Only for part 2, but yes, the sample was no help at all for the difference between part 2 and part 1

Quote from: Pickled Onion on 02 December, 2023, 10:58:48 am

I see quite a few people in the private leaderboard haven't bothered completing part 2 yet.

Part 2 needs to detect several characters to get a match, while part one only needs to detect a single character.

I was pleasantly surprised when my additions for part 2 worked first time (after the errors that wouldn't compile had been sorted)

Title: Re: Advent of Code
Post by: jwo on 02 December, 2023, 07:10:32 pm

Quote from: Diver300 on 02 December, 2023, 12:53:53 pm

Only for part 2, but yes, the sample was no help at all for the difference between part 2 and part 1

Except that some of the words in the sample did give a clue about the main gotcha with part 2, even if it didn't actually have an effect when processing the sample.

Title: Re: Advent of Code
Post by: vorsprung on 02 December, 2023, 09:30:10 pm

Quote from: Diver300 on 01 December, 2023, 08:35:50 am

Advent of code 2023 has started.

Day 1

(click to show/hide)

My puzzle input has 16 instances of "oneight" and 16 instances of "eightwo"

and once again i can't be arsed with it

Title: Re: Advent of Code
Post by: Diver300 on 05 December, 2023, 06:53:42 am

Day 5

(click to show/hide)

The second part takes a lot of calculations if you don't use subtlety. My puzzle took 1.8 billion calculations with absolutely no subtlety, but in javascript that took 15 minutes or so, faster than I could work out a more sophisticated algorithm and program it.

Title: Re: Advent of Code
Post by: Pickled Onion on 05 December, 2023, 10:42:43 pm

Not wanting to wait 15 mins, I spent an hour writing a recursive split which spat out the answer in 15 seconds.

Thinking I might be descending the same tree multiple times, I added a cache but it only knocked off a second. There is probably a better way, but it seems OK for < 100 lines of C#.

Title: Re: Advent of Code
Post by: Diver300 on 05 December, 2023, 11:37:26 pm

I decided that there had to be an elegant solution, and what I have now written, in far more than 15 minutes, runs in less than a second. It's not recursive.

(click to show/hide)

The seeds are in ranges. Each time a range of seeds has a line of a map applied to it, either or both ends of the seed range can be split off because they are outside the scope of the line of the map. Parts of seed ranges that are split off become new seed ranges so the number of ranges increases.

Seed ranges were marked as transformed by the map or not, to prevent more than one line of any one map being applied to any seed.

My input started with 10 ranges of seeds. I ended up with 45 ranges of seeds. There may have been overlap in these ranges, but I didn't care.

The code ran for each map
for each line of the map
for each range of seeds
The innermost loop runs 6449 times.

Title: Re: Advent of Code
Post by: Pickled Onion on 06 December, 2023, 08:21:24 pm

Yes, spotted the range thing later.

Day 6 was a bit easy

(click to show/hide)

It was pretty obvious from the start it was a normal distribution, so Part 2 ran quicker than Part 1 with no changes.


    public long Part1()
    {
        return Races.Select(x=> x.Ways()).Aggregate(1L, (x, y) => x * y);
    }
    public long Part2()
    {
        return Single!.Ways();
    }

Title: Re: Advent of Code
Post by: jwo on 06 December, 2023, 09:59:39 pm

Day 6:

(click to show/hide)

Pickled O: I'm not really familiar with C#. What does Select(x=> x.Ways()) do? And isn't the distribution quadratic rather than normal?

Here's my solution / explanation (https://observablehq.com/@jwolondon/advent-of-code-2023-day-6?collection=@jwolondon/advent-of-code-2023) that finds the roots of the quadratic to find the lower and upper bounds of the record beating boats.

Title: Re: Advent of Code
Post by: Diver300 on 06 December, 2023, 10:12:41 pm

Quote from: Pickled Onion on 06 December, 2023, 08:21:24 pm

Yes, spotted the range thing later.

Day 6 was a bit easy

(click to show/hide)

It was pretty obvious from the start it was a normal distribution, so Part 2 ran quicker than Part 1 with no changes.


    public long Part1()
    {
        return Races.Select(x=> x.Ways()).Aggregate(1L, (x, y) => x * y);
    }
    public long Part2()
    {
        return Single!.Ways();
    }

jwo posted while I was writing this.

(click to show/hide)

I don't think it was a normal distribution at all. It was a quadratic equation.
I found both solutions to each of four quadratic equations for part 1, and both solutions for one equation for part 2, admittedly with some large numbers.

In fact, a 3-cell spreadsheet can do the second part. The formulae are:-
=CEILING((A9-SQRT(A9^2-4*A10))/2;1)
=FLOOR((A9+SQRT(A9^2-4*A10))/2;1)
=A12-A11+1

A9 is the time
A10 is the distance
A11 is  the first formula
A12 is the second

Title: Re: Advent of Code
Post by: Pickled Onion on 07 December, 2023, 10:51:33 am

Symmetric rather than Normal. So you only need to find the lower bound.

Title: Re: Advent of Code
Post by: Pickled Onion on 09 December, 2023, 12:30:18 pm

Quote from: jwo on 06 December, 2023, 09:59:39 pm

Pickled O: I'm not really familiar with C#. What does Select(x=> x.Ways()) do?

It's Linq - Select takes an enumeration of races, and for each one asks it how many ways can that race be won, returning an enumeration of those. Aggregate takes an enumeration of numbers and applies the function on that number (y) and the previous result (x) with the seed (1) used as x for the first operation.

I'm seeing how far I can go writing all solutions in Linq. Eg, day 1 was quite neatly

    public long Part1()
    {
        return Lines.ElfinToNumber().Sum();
    }
    public long Part2()
    {
        return Lines.WordsToDigits().ElfinToNumber().Sum();
    }

Title: Re: Advent of Code
Post by: Pickled Onion on 09 December, 2023, 05:22:06 pm

And day 7 reads nicely with Linq

(click to show/hide)

    public long Part1()
    {
        return Hands.Order().Select((x, n) => x.Bid * (n + 1)).Sum();
    }
    public long Part2()
    {
        CardValue['J'] = 1;
        return Hands.WithJokers().Order().Select((x, n) => x.Bid * (n + 1)).Sum();
    }

It was fun writing the comparer.

Title: Re: Advent of Code
Post by: Pickled Onion on 09 December, 2023, 08:15:32 pm

Day 8, a bit of a cheat because I wrote GetSteps as normal function but the resulting Linq is still pleasing

(click to show/hide)

This really is a spoiler, don't click unless you really want a spoiler

(click to show/hide)

    public long Part1()
    {
        return Map.Keys.Where(x => x == "AAA").Select(GetSteps).Single();
    }
    public long Part2()
    {
        return Map.Keys.Where(x => x[2] == 'A').Select(GetSteps).Aggregate(LowestCommonMultiple);
    }

Title: Re: Advent of Code
Post by: Pickled Onion on 09 December, 2023, 10:30:12 pm

Day 9, that was interesting, I've never used Zip before

(click to show/hide)

    private long PreviousInSequence(IEnumerable<int> ints)
    {
        var diffs = ints.Zip(ints.Skip(1), (x, y) => y - x);
        return diffs.All(x => x == 0) ? ints.First() : ints.First() - PreviousInSequence(diffs);
    }

Title: Re: Advent of Code
Post by: Diver300 on 10 December, 2023, 05:12:11 pm

Day 10 pt 2 started to be interesting.

(click to show/hide)

The question is to find the number of points inside a perimeter.

That can be done from any point by counting the number of times the perimeter is crossed (in any direction) to get from the point to the edge of the map. If that number is odd, the point was inside the perimeter.

The digital and grid based nature of the map, in typical AOC fashion, means that any direction from many points to the edge will end up going along the perimeter at some point, making the crossing happen over several positions.

As my code travelled from each point to the edge along a straight line, the code stored whether the perimeter had approached the straight line from the left or the right, and if the perimeter later left the line on the same side, that was not counted a crossing, but if it left on the opposite side, it was counted as a crossing.

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2023, 07:08:08 pm

Day 10 part 2:-

(click to show/hide)

Quote from: Diver300 on 10 December, 2023, 05:12:11 pm

...
The digital and grid based nature of the map, in typical AOC fashion, means that any direction from many points to the edge will end up going along the perimeter at some point, making the crossing happen over several positions.

As my code travelled from each point to the edge along a straight line, the code stored whether the perimeter had approached the straight line from the left or the right, and if the perimeter later left the line on the same side, that was not counted a crossing, but if if left on the opposite side, it was counted as a crossing.

Not every direction. I tested for inside/outside by moving diagonally (north west in my case). If you do this you don't have to worry about non-zero winding rule type things. The horizontal/vertical pipes count, as do two of the corner pipes, but not the other two corner pipes. Much simpler.

e.g. if moving NW then | and - count, as do F and J, but L and 7 don't.

Title: Re: Advent of Code
Post by: Greenbank on 10 December, 2023, 07:16:45 pm

Day 5 part 2:-

(click to show/hide)

I didn't do ranges, I tested the lowest seed number(s) and, as I worked through the mappings, took note of the maximum I could add to this n and still fall through all of the same rules. I could then skip all of those values (since they would always lead to a higher number if going through the same rules) and start on the next one that invoked a change in rules.

Takes 0.4 ms to parse the input (could probably improve that) and then under 0.1ms to do the calcs for part1 and part2. I could probably save a bit in part2 too given that it's already done some of the seed values in part 1. It only ever had to check 153 individual seed numbers in part 2.

Code: [Select]

dur=421.422µs
part1: 174137457
dur=444.062µs
part2: 1493866
dur=498.989µs


Title: Re: Advent of Code
Post by: Pickled Onion on 10 December, 2023, 07:38:03 pm

Quote from: Greenbank on 10 December, 2023, 07:08:08 pm

Day 10 part 2:-

(click to show/hide)

Quote from: Diver300 on 10 December, 2023, 05:12:11 pm

...
The digital and grid based nature of the map, in typical AOC fashion, means that any direction from many points to the edge will end up going along the perimeter at some point, making the crossing happen over several positions.

As my code travelled from each point to the edge along a straight line, the code stored whether the perimeter had approached the straight line from the left or the right, and if the perimeter later left the line on the same side, that was not counted a crossing, but if if left on the opposite side, it was counted as a crossing.

Not every direction. I tested for inside/outside by moving diagonally (north west in my case). If you do this you don't have to worry about non-zero winding rule type things. The horizontal/vertical pipes count, as do two of the corner pipes, but not the other two corner pipes. Much simpler.

e.g. if moving NW then | and - count, as do F and J, but L and 7 don't.

(click to show/hide)

I don't think you need to do either of those things. I imagined each tile not in the loop to be slightly to the right of its real position, then a vertical line would cross a boundary only at F, L or -
The only wiggle was not knowing what flavour of pipe the start was, but rather than coding that up, if an up line hit S I just went down instead.

Title: Re: Advent of Code
Post by: jwo on 10 December, 2023, 11:14:28 pm

Day 10 part 2:

(click to show/hide)

I think you can simplify further by just moving left or right and only looking for |, L, or J (the same would work if you looked for |, F, or 7). The nice thing about this approach is that you can then just process the grid rows individually with a simple one-line filter and  character count:

crossings = (row, col, grid) => grid[row].slice(col).filter((c) => c === "|" || c === "L" || c === "J").length;
 

Title: Re: Advent of Code
Post by: jwo on 13 December, 2023, 07:02:18 pm

Day 13

I enjoyed this one. Not so much in getting an answer, but in doing so efficiently.

(click to show/hide)

My first attempt for Part 2 tried every possible grid cell as the smudge location. Surprisingly this found the answer in around a second. But with bitwise representation and information theory to the rescue (Hamming distance), managed to get a speed-up of c. 1000x, giving an answer in under a millisecond.

Full workings here (JavaScript):

https://observablehq.com/@jwolondon/advent-of-code-2023-day-13

Title: Re: Advent of Code
Post by: Greenbank on 13 December, 2023, 08:42:59 pm

Day 13

(click to show/hide)

Didn't need full hamming distance. If two numbers differ then you can a xor b and then test if the result is a single bit set with one of my favourite CompSci tricks - the test for something being a power of two:-

(x & (x-1)) == 0

Helped get mine down to 193.284µs.

Title: Re: Advent of Code
Post by: jwo on 13 December, 2023, 10:19:21 pm

Day 13

(click to show/hide)

Quote from: Greenbank on 13 December, 2023, 08:42:59 pm

Didn't need full hamming distance. If two numbers differ then you can a xor b and then test if the result is a single bit set with one of my favourite CompSci tricks - the test for something being a power of two:-

(x & (x-1)) == 0

Neat. I think that shaves off another few milliseconds, but will leave the Hamming version up in my page as it better reflects my chain of thought. The kind of programming I do tends not to use these lower-level bitwise ops, but that power of 2 trick now logged in my brain for future use (along with swapping contents of two variables with three XORs).

Title: Re: Advent of Code
Post by: Greenbank on 18 December, 2023, 12:31:26 pm

Day 18

(click to show/hide)

First time I've used the Shoelace Formula. Utter goblinry. Brain can't compute how it works so I'm going to have to read up on it to make it sink in.

Total time for 2023 so far (up to and including day 18) is 0.378s, so still a few left to optimise (days 17, 16, and 14 take the longest).

Title: Re: Advent of Code
Post by: jwo on 18 December, 2023, 10:37:56 pm

Quote from: Greenbank on 18 December, 2023, 12:31:26 pm

Day 18

Total time for 2023 so far (up to and including day 18) is 0.378s, so still a few left to optimise (days 17, 16, and 14 take the longest).

Impressive. Are you still writing them in C?

I've just totalled mine (JavaScript) up to and including Day 18. I come out at 1.3 seconds total, with those same slow days being over 80% of that time.

Day 18 was my favourite so far.

(click to show/hide)

Nice example of misdirection in the puzzle instructions with the recent memory of Day 10 also helping to shove us in the wrong direction.

(click to show/hide)

I think the trapezoid formula makes more intuitive geometric sense, and I guess you can derive the shoelace from it.

Title: Re: Advent of Code
Post by: vorsprung on 19 December, 2023, 09:58:21 am

Day 96

(click to show/hide)

there isn't a day 96.  I haven't wasted even 10 seconds on the Advent of Code this year! :)

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2023, 10:29:33 am

I don't know how long I've spent on AoC over the years but all of the time isn't wasted (it's not all 100% productive/useful either though). I'd probably guess it's at least 40h each year.

Like jwo (and Ross and mTrak) I've got all of the stars (so far, for all years) and that represents a significant amount of time that has been put into it, but I'd count this as professional development - plus the fact that I enjoy solving these kinds of puzzles.

I'm using it as a challange but mostly to get more comfortable in a new language (Go). I did all of the previous years in a mixture of shell, C and predominantly perl. Now most of my professional coding is in Go and so that's what I'm doing 2023 in. In my Copious Free Time (TM) I'm also going back and redoing all of the previous years in Go (have about 90 days left to do). This helps me understand how I would implement certain things in this language, notably:
* Numbers > 2⁶⁴
* Number theory (modmul, modexp, lcm, gcd, crt, ...)
* Recursion, tail recursion
* Parsing, regexp, sorting
* Memoization and Dynamic Programming
* Sparse grids using maps, 2D, 3D, 4D+
* BFS/DFS
* Dijkstra/A* and using structures like a heap queue to implement an efficient priority queue
* Trees (binary, n-ary, red/black, etc)
etc

Title: Re: Advent of Code
Post by: jwo on 19 December, 2023, 01:15:10 pm

Wot Greenbank sed.

For me, over the years I've used AoC to improve my skills in Java, Elm, JavaScript and C++ as well as general data structures and algorithm competence. I also use it with students (from first year undergraduates to PhDs) to help them develop their algorithmic thinking, reasoning and communication. I didn't do a Comp Sci or Maths degree so AoC has been useful learning tool for me (and mostly fun).

I know Eric (the puzzle setter) creates these to help people learn, and some of the puzzles are very elegantly and subtly designed with that in mind. Clearly it's not for everyone, but for some (of us), a fun and rewarding activity.

Title: Re: Advent of Code
Post by: davelodwig on 19 December, 2023, 03:20:53 pm

I spend all day writing code and solving problems.

As much as I try to do AoC I just can't get the energy up to do it in the evenings after work.

Title: Re: Advent of Code
Post by: Greenbank on 19 December, 2023, 03:34:00 pm

I do it in the morning before work usually. My daughter leaves for school around 7.15 and so I've got ~2 hours before I start work. Usually I'd either go for a swim/bike/run in this time, or just start work early and then have a longer lunch or knock off early, but in December it's generally AoC time.

For the trickier days doing AoC may bleed over into lunchtime or the evening, but I find that subconscious thought (while I'm doing my day job) helps get me to the solution without taking too much time sat actively staring at it. Reading elsewhere (the AoC subreddit mostly) it seems I'm lucky that I'm able to put an AoC problem down once I need to focus on something else (e.g. what I get paid for) and it doesn't bother me to do so.

The weekends (or holidays) I just have to find the time whenever outside family life.

Going back and redoing all of the previous years in Go is becoming a bit of a slog, especially now that I've picked off most of the easy ones from each year, but the plan is to tackle 1-3 days at a time in the new year and I'll get through them all in a few months. Already having a solution (albeit in C/perl/?) helps. Also going back and looking at my old code is a useful exercise to see how long it takes me to understand it and whether there are any useful comments/etc.

Title: Re: Advent of Code
Post by: Greenbank on 20 December, 2023, 03:31:56 pm

Spoiler day 20

(click to show/hide)

Got lucky and did part 2 within about 10 minutes of finishing part 1.

Another spoiler just in case you didn't want to see the magic of Day 20 part 2.

(click to show/hide)

Hacked my code from part 1 to stop when it met the condition for part 2, saw it just kept running so knew something was up and killed it.
Looked at what fed into the `rt` module, saw it was a single conjunction module.
Looked at what fed into that module, saw there were just 4 inputs to this conjunction module.
Knowing that all 4 of the inputs had to be high at the same time for this node to output a high I adapted my part2 break code from above to output the button count when each of those 4 inputs sent a high pulse.
Got 4 numbers somewhere around 4000. Also saw they were repeating on exact multiples of those numbers, so knew CRT wasn't going to be required.
Ran `factor` on the command line and saw they were all prime, so no need to do LCM. Even better.
Multiplied them together and submitted them as my answer and, lo and behold, it was correct.

Only then did I go digging as to why, and worked out what was going on and why the above worked.

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2023, 11:11:57 am

Spoiler Day 21 part 2

(click to show/hide)

Another unsatisfactory one (IMHO). Again I got lucky with my guesses.

Real spoiler below.

(click to show/hide)

The way the numbers looked (both in terms of answer from just 64 steps and the required number after 26501365 steps) told me it was impossible to bother trying to brute force so I switched into pattern spotting mode.

AoC Spidey sense tingled at:
* Map was an odd size (literally) - usually they have even lengths
* No rocks in same row or column as Start
* No rocks in diagonals between centres of each edge, so no rocks in the area with a Manhattan distance of ~65 from the start
* And the start was exactly centred in the map at 65,65.
* 65
* Answer required at 26501365 steps.
* 26501365 mod 131 = 65 (I'm guessing he picked that number on purpose so that the trailing 65 was more obvious)
* Guessing we can compute a few terms and extrapolate
* Adjust code to handle an infinite grid but keep track of real points
* Compute answer for 65, 65+131, 65+131+131 steps
* Check 1st order differences between the 3 answers, not equal, so assume it's quadratic and compute 2nd order difference (heh, back at Day 9 and Lagrange Interpolation)
* Calculate answer using 1st order and 2nd order differences
* ???
* Profit (with a second star)

[EDIT] Reworked part1 to be a single BFS to 65+131+131 steps and counting newly visited grid squares on odd and even step numbers separately. (A cell visited on an even step cannot be visited on any odd numbered step and vice versa.) Part 1 runs in 3.4ms and then Part 2 is done in 66.8ms (cumulative).

Title: Re: Advent of Code
Post by: Greenbank on 21 December, 2023, 10:15:20 pm

2023 Day 21 Part 2 mild spoiler from the AoC Creator

(click to show/hide)

I said:

Quote from: Greenbank

26501365 mod 131 = 65 (I'm guessing he picked that number on purpose so that the trailing 65 was more obvious)

Not only that, it was an even better coincidence:-

Source: https://www.reddit.com/r/adventofcode/comments/18nx8de/comment/kedjwqd/?utm_source=reddit&utm_medium=web2x&context=3

Quote

topaz2078 1 hr. ago (AoC creator)

From my Perl code:

Code: [Select]

my $goal_dist = 65 + 131*202300;
Very good find!

Title: Re: Advent of Code
Post by: vorsprung on 22 December, 2023, 11:51:59 am

Quote from: Greenbank on 19 December, 2023, 10:29:33 am

a mixture of shell, C and predominantly perl. Now most of my professional coding is in Go

Same here

Title: Re: Advent of Code
Post by: vorsprung on 22 December, 2023, 11:55:57 am

Quote from: jwo on 19 December, 2023, 01:15:10 pm

Wot Greenbank sed.

For me, over the years I've used AoC to improve my skills in Java, Elm, JavaScript and C++ as well as general data structures and algorithm competence. I also use it with students (from first year undergraduates to PhDs) to help them develop their algorithmic thinking, reasoning and communication. I didn't do a Comp Sci or Maths degree so AoC has been useful learning tool for me (and mostly fun).

I don't have any students.  At the moment I am only mentoring one person, maybe I should teach them how to program properly.  Hmmm

Title: Re: Advent of Code
Post by: jwo on 23 December, 2023, 11:32:20 pm

Day 23

A little easier than the last few days, but struggled to get computing Part 2 to anything faster than around 10 seconds.

(click to show/hide)

Beyond the obvious contraction of the graph representation to store only junctions (with edge weights as he steps between them), not sure what further optimisations are possible as generally longest path calculations on a graph are NP hard (https://en.wikipedia.org/wiki/NP-hardness)..

Title: Re: Advent of Code
Post by: Greenbank on 27 December, 2023, 02:09:51 pm

Got there in the end as I was busy/pissed most of 24th/25th/26th.

Have to redo/optimise days 22, 23, 24, 25. Plus revisit a few days (12, 14, 16, 17, 20) that are taking a bit more than they should but it can go on the backlog for now until my brain is ready for them.

Title: Re: Advent of Code
Post by: Pickled Onion on 01 January, 2024, 08:19:44 pm

Had a bit of a break, so only on day 19.

Bah. And Grr.

Spent ages working out what would happen if the ranges on different paths overlapped, and what if a path had a disjoint range, then a bit of time coding up the range flattening... Only to find that it had been crafted so that no ranges overlapped and the simple sum of combinations for each route gave the answer.

My final code cut simply down to

(click to show/hide)

    public long Part2()
    {
        return Workflows.Values.SelectMany(RangesFor).Sum(x => x.Combinations);
    }

Where RangesFor(workflow) worked back from every 'A' to 'in'

Title: Re: Advent of Code
Post by: Pickled Onion on 01 January, 2024, 08:55:41 pm

Quote from: vorsprung on 22 December, 2023, 11:51:59 am

Quote from: Greenbank on 19 December, 2023, 10:29:33 am

a mixture of shell, C and predominantly perl. Now most of my professional coding is in Go

Same here

I'd done* many of the previous years in Perl. A lot of the problems seemed to be geared towards languages like Perl and Python. One year I tried to solve them in regular expressions, which worked for the first several days at least.

I've learnt a huge amount by solving them in C# LINQ this year. I'll be giving a talk on LINQ Best Practice in a couple of weeks to the internal C# group, 100+ developers. It's become apparent that 90% of them are "doing it wrong", and most of the other 10% are simply following received wisdom (including me up to now). There's a paucity of good guidance or documentation on what is one of the sharpest tools in the C# box. In fact it's a lot like Perl in that it's easy to write something that works, but you need a deeper understanding to write something that Works Well and is clear/maintainable.


* not finished though