There are a number of J solutions in the project euler forum thread for the problem if you have already solved it.
I don't think you need to fill the diagonals that are too short: 4&(<\each) </. i. 5 5 ┌┬┬┬───────────┬──────────────────────┬────────────┬┬┬┐ ││││┌─────────┐│┌─────────┬──────────┐│┌──────────┐││││ │││││3 7 11 15│││4 8 12 16│8 12 16 20│││9 13 17 21│││││ ││││└─────────┘│└─────────┴──────────┘│└──────────┘││││ └┴┴┴───────────┴──────────────────────┴────────────┴┴┴┘ 4&(*/\each) </. i. 5 5 ┌┬┬┬────┬──────────┬─────┬┬┬┐ ││││3465│6144 30720│41769││││ └┴┴┴────┴──────────┴─────┴┴┴┘ ; <@(4&(*/\))/. i. 5 5 3465 6144 30720 41769 On Sun, Sep 25, 2011 at 8:06 PM, bill lam <[email protected]> wrote: > No idea on the problem or forgotten. > > conjunction binds to the left so that you need brackets, eg. > 5&({.!.1) /. (5 5 $i. 25) > > or if you are only interested in the product, it might be > > *//. (5 5 $i. 25) > > Вск, 25 Сен 2011, Nick Simicich писал(а): >> I'm working on euler 11 from projecteuler.org. I got the answer by doing >> something really crummy, and I decided to go back and do proper code for the >> diagonals. The problem is to take the greatest product of four consecutive >> numbers in a 20 by 20 array where the possibilities are rows, columns and >> diagonals. >> >> Rows and columns are trivial, and now that I understand that /. does not >> only take the longest diagonal the diagonals are not much harder. >> >> Because this is a product, I wanted to use a 1 fill. >> >> a is a 20 by 20 array of small numbers. >> >> My first attempt was to box the diagonals, and then fill them, the unbox >> them and then do my product on the crosswise bits, and then take the max, >> so >> >> >./(,4 */\ a) ,(,4 */\ |:a) ,(,4*/\"1 > 20{.!.1 L:_1 </.a),(,4*/\"1 > >> 20{.!.1 L:_1 </.|:a) >> >> I transpose the array to get the other diagonals, and do it again so that I >> can do the horizontals and verticals. >> >> I used a box for the diagonals because my thought was that they were all >> different lengths, so they needed to be boxed. Once I fixed them to be >> conformant, I could unbox them. >> >> Then I looked and determined that I could get an array with the diagonals on >> the lines as: >> >> 20&{. /.aa >> >> And this gives (the small, forum appropriate version): >> 5&{. /. (5 5 $i. 25) >> 0 0 0 0 0 >> 1 5 0 0 0 >> 2 6 10 0 0 >> 3 7 11 15 0 >> 4 8 12 16 20 >> 9 13 17 21 0 >> 14 18 22 0 0 >> 19 23 0 0 0 >> 24 0 0 0 0 >> >> But because it is a product, I need a 1 fill. I am using a 1 fill with take >> above, when I am taking from the lines individually. >> >> 5&{.!.1 /. (5 5 $i. 25) >> |domain error >> | 5&{.!.1/.(5 5$i.25) >> >> I could not, at first, figure out why the domain error was occuring. Take >> should fix the length of the line no matter what the length of the incoming >> line. >> >> Then I thought, suppose it is calculating a number of things to add to the >> vector, and the second vector it tries to finesse the calculation, using the >> same value to produce a line, and then having a domain error when that value >> of pad produces an unsquare array. What if I change the rank of the verb to >> try and get it, say, not to run on all of the lines produced by /. at the >> same time, but instead to run on each line? So I tried a few different >> values for the rank. >> >> (5&{.!.1)"_1 /. (5 5 $i. 25) >> |domain error >> >> I won't bore you by repeating this, but that theory simply didn't work. I >> could not get the verb to stop reporting an error. >> >> 0+/. a builds me a zero filled array that looks exactly like 20{. . Can't >> use 1+ or a verb with a test assuming I could get it to work (usually can't, >> I'm new to this) because there are zeros in the array that I think I have to >> leave alone. >> >> Maybe the real problem is that the fill is not coming from where I expect it >> to come from. But I think they come from the take verb when I do 20{. >> /. aand well, this is interesting: >> >> (#,5&{.) /. (5 5 $i. 25) >> 1 0 0 0 0 0 >> 2 1 5 0 0 0 >> 3 2 6 10 0 0 >> 4 3 7 11 15 0 >> 5 4 8 12 16 20 >> 4 9 13 17 21 0 >> 3 14 18 22 0 0 >> 2 19 23 0 0 0 >> 1 24 0 0 0 0 >> >> >> so the lines are clearly not being padded before the verb is called. >> >> and, um-- well, I think I just don't understand things more complex, it >> implies that if I can derive the length I should be able to prepend >> (5-#L$1), instead of hash but I always get hung in anything complex. >> >> Is this a bug or a feecher? Other than boxing it, is there a way to code >> it? Am I just missing how to do it? >> >> >> >> >> >> -- >> Of course I can ride in the carpool lane, officer. Jesus is my constant >> companion. >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
