12f32ed232
removed warnings
2018-12-25 14:03:45 +01:00
768d328e87
day22 2nd part
2018-12-24 17:19:50 +01:00
31075fa449
day22 refactored part1 into extra struct
2018-12-24 15:49:00 +01:00
d5aa1ddc74
day22 part1
2018-12-22 15:07:46 +01:00
8badd4a416
day20 part 2
2018-12-21 11:26:21 +01:00
241ca8ea18
day20 part1 fast
2018-12-21 10:32:11 +01:00
a35881fb01
day20 part 1 super slow
2018-12-21 10:03:06 +01:00
0438a052d2
day20 WIP
2018-12-20 10:19:41 +01:00
ba622fd408
day15 part 2 optimized
...
instead of senselessly trying to find the best starting point, just rely
on the order of neighbor point generation. Since we use a queue
to manage open points and he neighbors are added in the correct
order, they neighbor that has precedence due to reading order will
automatically be the one to be predecessor on a final path, if he is on
a shortest path.
2018-12-18 22:43:10 +01:00
cef96d55be
day15 part 2
2018-12-18 22:20:03 +01:00
3f2ff6e5a2
day15 part1 done
2018-12-18 19:11:55 +01:00
ac3a741f0d
day15 part1 combat with errors
2018-12-18 17:46:44 +01:00
2bf8edf315
day15 part1 movement
2018-12-18 16:59:41 +01:00
6f2e046080
day14 both parts
2018-12-17 17:45:35 +01:00
6f9ca4dfb6
2018-12-17 11:06:12 +01:00
807bff7977
day13 part2
2018-12-16 01:37:37 +01:00
c1c761f2ba
day13 part 1
2018-12-16 01:14:09 +01:00
2fa6c40f33
day12 part 1
2018-12-14 14:09:57 +01:00
54103e8fa6
day11 part2 fast
2018-12-11 16:02:22 +01:00
fc328d82af
day11 part2
2018-12-11 11:37:32 +01:00
267dfb8068
day11 part 1
2018-12-11 11:25:57 +01:00
6d4bdccc6e
day10 part 2
2018-12-11 09:35:19 +01:00
4eb90ac047
day10 part 1
2018-12-10 20:51:13 +01:00
2cf9933300
day09 part 2
2018-12-10 15:16:06 +01:00
e5a3a1458a
day09 part 1
2018-12-10 13:10:09 +01:00
d84e3bff27
day08 part 2
2018-12-09 21:34:43 +01:00
51418b709e
day08 part 1
2018-12-09 21:17:29 +01:00
4946263a37
day07-1
2018-12-07 11:17:48 +01:00
cd16a42821
push to edition 2018
2018-12-07 09:53:18 +01:00
5ab8409b5b
day06 both
2018-12-06 09:50:35 +01:00
5fa344dd55
day05 part 2 prealloc vectors
2018-12-05 20:53:00 +01:00
d10d36498c
day05 performance push part 2 through more efficient case insensitive comparison
2018-12-05 15:19:12 +01:00
32843531f8
take times
2018-12-05 15:15:18 +01:00
50cd1d6b00
removed comments
2018-12-05 10:50:27 +01:00
40957e1252
day05 both parts fast
2018-12-05 10:49:52 +01:00
6e92d937a9
day05 part 1 (2 WIP)
2018-12-05 08:44:50 +01:00
baacb780ba
day04 both
2018-12-04 20:15:20 +01:00
43ce26593e
day03 both
2018-12-04 18:06:01 +01:00
088179a007
day02-2 super-fast
2018-12-02 19:12:01 +01:00
062c30ece4
day02-2 linear
2018-12-02 14:25:46 +01:00
b89e4f4929
day02 both
2018-12-02 09:17:23 +01:00
a0509342ae
day01-2 use scan with tuple expansion
...
The previous problem with this was, that I tried returning
"Some((Ref<i32>, _))" from the lambda. That caused the compiler to complain
about the lifetime of the `current` value, since I tried passing on the Ref
instead of the encapsulated value.
2018-12-01 18:19:07 +01:00
0494dee19d
day01-2 tuple
2018-12-01 17:54:30 +01:00
2d64eefc09
day01 redone in a more functional way
...
in task2, RefCell is used since the passed state in 'scan' seems to be
immutable, although it shouldn't.
2018-12-01 15:13:16 +01:00
cebb80763a
day01 both
2018-12-01 10:03:12 +01:00
Johannes