I did solve it, but I didn't use J for that one. I wrote a translator in Perl that converted their assembly into C. C, because it's easier to read, plus I thought that some brute forcing might be required and compiled C will run faster than interpreting their assembly.
While studying that generated C code I discovered that there are 14 very similar segments, each segment belonging to one of two types. Segments of one type increased the value of z and segments of another type decreased the value of z given some condition. That allowed me to reduce the size of search space from 9^14 (too large) to 9^7 (very manageable). -- Eugene On Thu, Jan 13, 2022 at 2:17 PM Raul Miller <rauldmil...@gmail.com> wrote: > https://adventofcode.com/2021/day/24 > > I have not completed the day 24 puzzle. > > The day 24 puzzle has a sequence of instructions representing a > calculation to verify a model number (and conceptually enable features > based on that model number -- though part A of the puzzle does not > provide any details about that). > > The processing unit performs integer calculations, and has four > registers: W, X, Y and Z. > > There are six instructions, one which inputs a digit of the model > number, an add instruction, a multiply instruction, an integer > division instruction, a modulo instruction and an equals instruction. > > The input instruction always inputs to register W (and is the only > instruction used to update W). The div instruction always divides by 1 > or 26. The modulo instruction is always used to find a remainder > modulo 26 (and always only operates on positive values, or 0 for the > numerator). The multiply instruction seems to always multiply by 0 or > powers of 26. (To load a value into a register, the register is first > multiplied by 0 and then has another value added to it.) > > A certain amount of simplifications are possible using math identities > and range constraints. But I do not have much more that's useful to > say until I've found a way of solving the puzzle. > > Here's a snapshot of where I'm at, trying to work through these issues > (looks sloppy with a proportionally spaced font): > > ... > digit13 NB. W234=: W216 inp 13 [ 1 thru 9 > 0 NB. X235=: X223 mul 0 [ 0 > add Z228 Y232 NB. X236=: X235 add Z233 [ 9 thru 5520918021 > mod 26|Z233 26 NB. X237=: X236 mod 26 [ 0 thru 25 > mul <.Z210%26 X223 NB. Z238=: Z233 div 26 [ 0 thru 212343000 > add X237 _4 NB. X239=: X237 add -4 [ _4 thru 21 > eql X239 digit13 NB. X240=: X239 eql W234 [ 0 thru 1 > eql X240 0 NB. X241=: X240 eql 0 [ 0 thru 1 > 0 NB. Y242=: Y232 mul 0 [ 0 > 25 NB. Y243=: Y242 add 25 [ 25 > mul 25 X241 NB. Y244=: Y243 mul X241 [ 0 thru 25 > add Y244 1 NB. Y245=: Y244 add 1 [ 1 thru 26 > mul <.Z228%26 Y245 NB. Z246=: Z238 mul Y245 [ 0 thru 5520918000 > 0 NB. Y247=: Y245 mul 0 [ 0 > digit13 NB. Y248=: Y247 add W234 [ 1 thru 9 > add digit13 7 NB. Y249=: Y248 add 7 [ 8 thru 16 > mul Y249 X241 NB. Y250=: Y249 mul X241 [ 0 thru 16 > add Z246 Y250 NB. Z251=: Z246 add Y250 [ 0 thru 5520918016 > > I am currently working on some tree unification mechanisms (maximum > common subtree elimination to let me better inspect the partially > resolved calculations). > > I believe Eugene Nonko has solved this one, though I do not know if he > found J useful in his approach. > > FYI, > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
