| Age | Commit message (Collapse) | Author |
|---|
|
|
|
That was a tough one. Still takes 2.5s on my hardware. Should be able to
multithread the permuation search at some point, if I want to.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Because we're storing the input lists *as a list*, when we compare
successive pairs of lists, we can't compare the list nodes themselves.
Instead, we compare the lists they point to.
Unfortunately, this doesn't change the answer we get. It does improve
runtime though!
|
|
Gets correct answer for test input, but wrong answer (5711) for main
input. The problem is, I don't know where it's going wrong, and the
inputs are complicated, so tracking down the source of the problem is
going to be a major pain.
Wish I hadn't put this off for most of the day, and had more time to
look at it now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The trick is that we don't care about how much worry there is, we only
care how much worry modulo the test divisor, to figure out which monkey
gets the item next.
Now, I know that addition is stable under modulo arithmetic, but I seem
to remember that multiplication is stable under modulo arithmetic also?
(I think public key cryptography relies on this?)
So, by only keeping track of our worry, modulo the product of all the
test divisors, everything should still work correctly?
At least, that's what I tried, and it stopped all the overflow, and I
seemed to get the right numbers according to the expected test results,
and my final answer was also accepted. So I guess it does work
correctly!
|
|
|
|
Turned item worry levels to unsigned long in an attempt to not overflow.
Added checks for overflow, and they get hit - quickly - without the
calming factor. Will need to think about this. (or try bignums)
|
|
|
|
|
|
|
|
|
|
|
|
Needed to switch to moving the head one step at a time and recalcating
the rest of the rope on each iteration, or the numbers came out wrong.
|
|
Now that we fixed the bug, get rid of debug output.
|
|
I wasn't creating a new tail element after inserting the first tail, so
when we revisited the origin the second time it didn't spot it as a
dupe, giving an off-by-one error
(The test input didn't have the tail pass the origin twice, so this
wasn't an issue there)
|
|
Apparently the answer it gets for the full input (5736) is wrong. The
answer for the test input (13) is right though.
Added a bunch of debugging logic, to try and see *where* it's going
wrong, but I can't see it so far. This one is interesting.
|
|
Allows me to save the test input as a .test file without getting nagged
by git.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
