| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
| |
Nice one, having to actually look at the input for once. :)
|
| |
|
|
|
|
| |
Haskell version is waaaaay too slow and uses huge amounts of memory.
Didn't even let it run to completion on part 2.
The C version is really quick. /shrug/
|
| |
|
|
|
| |
Please compile this, and even then running takes about a minute
on my PC. This is a SLOW implementation, but it works.
|
| |
|
|
|
|
| |
This gives the right answer, but that 100 is a HIGHLY magic constant.
Increase if incorrect. `prune` should work, but doesn't for some reason.
This is sad but I've spent enough time on this as is.
|
| | |
|
| |
|
|
|
|
| |
I misread part 2 thinking that 'rcv 0' still shouldn't do anything.
It should. That solved some problems. As in, let it work first try
afterwards.
|
| |
|
|
|
| |
You want to compile this for part 2. Inefficient, but works. Reusing
part 1 was so inefficient that it blew up my memory.
|
| | |
|
| | |
|
| |
|
|
|
| |
Generators are cool. Please compile this, otherwise it will burn
your CPU.
|
| |
|
|
|
|
|
| |
Honestly, I'm surprised that this is even remotely fast. The usage of plain
linked-list strings should make this horrifyingly slow, but apparently, the
combination of an optimising GHC and a not-too-large map (apparently) make
this tractable.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
That was a really long description. Fun hash though.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This one was already just a tiny bit harder, because I failed to
notice there were multiple unbalanced nodes. Filtering out parents
proved to be a success.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
