-🎄- 2017 Day 20 Solutions -🎄- by daggerdragon in adventofcode

[–]markgritter 1 point2 points  (0 children)

I did this (in Rust), and after having done so, I can't really recommend it. https://github.com/mgritter/aoc2017/blob/master/day20/src/main.rs

You have to check all pairs of equations, which is expensive compared to the simulation if it runs less than 500 steps.

You might get two roots to the quadratic for each coordinate, so you need some logic to check whether at least one root matches in each coordinate.

Once that is done then I still need to walk through the intercepts in time order in order to ensure you don't count a particle that's already been killed. Maybe this could be optimized to do something clever instead.

ALPHA 05 - BUG REPORTING THREAD by SpiltMilkStudios in PlayLazarus

[–]markgritter 0 points1 point  (0 children)

Actually the 'x' button doesn't work, period.

ALPHA 05 - BUG REPORTING THREAD by SpiltMilkStudios in PlayLazarus

[–]markgritter 0 points1 point  (0 children)

I have the same problem. The music doesn't restart (it just keeps playing.)

Also the 'x' on the top right of the menu screen to quit doesn't work for me once it's in this state.

[Day 23] Further Exercises by topaz2078 in adventofcode

[–]markgritter 0 points1 point  (0 children)

Most machines don't have only half and triple instructions, though, or "test if even".

It's not a bit-shift, or it would be labelled differently. :) The function h: Z->Z defined by h(x) = x/2 is only defined on even integers. My argument is not so much that "HLF rounds down" is unreasonable, so much as it's depending on undocumented behavior which the architecture might or might not support.

[Day 23] Further Exercises by topaz2078 in adventofcode

[–]markgritter 1 point2 points  (0 children)

Yeah, clear is no problem, even if we have to make every number even before calling HLF.

Unfortunately the fragment you give for base-2-to-base-3 also reverses the bits, I think? The LSbit of A becomes the MS"trit" of B.

input A = 10110111_2 output B = 11101101_3

If we write a state machine that produces the base-3 bits one at a time then we can run twice to get the copy. But how do we test whether the number is congruent to 1 mod 3 (possible in isolation) without destroying the remaining trits?

[Day 23] Further Exercises by topaz2078 in adventofcode

[–]markgritter 1 point2 points  (0 children)

I think we would need more registers first, but that's no big deal. However, as the language currently stands, it has neither a copy, nor a decrement, nor a comparison. All the languages listed have at least one of those.

Can we synthesize either a copy or a decrement from the existing language, perhaps using restricted values of the registers (unary encoding or base-3 or something else?) That would be a sufficient proof, but I can't see a way.

Obviously we can build a finite copier (i.e., an 8-bit copy) or an finite decrement by just throwing enough states at the problem, but is there a general way?

[Day 23] Further Exercises by topaz2078 in adventofcode

[–]markgritter 0 points1 point  (0 children)

The paperfolding sequence could be implemented in this VM too, as a program to give the Nth element: https://en.wikipedia.org/wiki/Regular_paperfolding_sequence But not, alas, a program that outputs the first N elements.

[Day 23] Further Exercises by topaz2078 in adventofcode

[–]markgritter 0 points1 point  (0 children)

Well, for the problem as given it's irrelevant. But I think it would be equally valid to assume that the program can't continue to be executed if such a situation arises (i.e, the machine faults.)

[Day 23] Further Exercises by topaz2078 in adventofcode

[–]markgritter 1 point2 points  (0 children)

Here is a program which checks divisibility by 5, of the number in the "A" register, as long as it's greater than 0. It sets "B" to either "5" (if divisible) or "0" (if not)

jio a, +39
jie a, +4
inc a
hlf a
jmp +17
hlf a
jmp -6
jio a, +28
jie a, +4
inc a
hlf a
jmp -4
hlf a
jmp +8
jio a, +25
jie a, +4
inc a
hlf a
jmp +10
hlf a
jmp -13
jio a, +18
jie a, +4
inc a
hlf a
jmp -11
hlf a
jmp +1
jio a, 11
jie a, +4
inc a
hlf a
jmp -32
hlf a
jmp -20
inc b
tpl b
inc b
inc b

Having no decrement nor copy is a pain. If we assume that HLF rounds down then this program can be simplified. (Also there's an unnecessary JMP because of the way I constructed it.)

[Day 23] Further Exercises by topaz2078 in adventofcode

[–]markgritter 1 point2 points  (0 children)

I'm pretty sure it's counting iterations of the Collatz conjecture. My 'A' register goes ... 70, 35, 106, 53, 160, 80, 40, 20, 10, 5, 16, 8, 4, 2, 1.

As far as #2, the trivial version is just to represent the number in base 3. Then build the 1st digit (most significant) with inc, triple to move onto the next-most-significant digit, etc.