When I run your code, I see that peri, zmin and z are all numbers (z is a list of numbers, just like before in this thread), and you've taken advantage of the useful constraint x<y and y<z to put a minimum bound on z.
Thinking about this for a few seconds, I see that zmin and z (and your final result) are all functions of peri. So let's express them that way: peri=: 57 zmin=: 1 + ] >.@% 3: z=: zmin + i.@(1 <.@- zmin - ] % 2:) F=: [: +/ (1.5 <.@* z) - 0.5 >.@+ peri % 2: Testing that I have not made any mistakes: F 57 61 ... looks plausible. At this point, I can use F f. to see my "one liner" it's rather long (note that I might want to use 9!:3 to see this code expressed in different ways), but the only "inefficiency" is that zmin is calculated twice. Given that data movement - saving zmin and extracting it later also has a cost, it's probably not worth eliminating this "inefficiency". That said, both of those occurrences are in z and z currently takes only one argument. We could easily create a binary operation inside z that takes zmin as an argument. For example: z=: zmin ([ + i.@(1 <.@- [ - ] % 2:)) ] I always like to hesitate, though, when I do this - am I just doing it to be "clever" or am I accomplishing something actually useful? In this case, I do not feel that I've created a better abstraction, so I prefer the earlier expression for z, or maybe a variant such as z=: zmin + 1 i.@<.@- zmin - ] % 2: or z=: zmin + [: i. 1 <.@- zmin - ] % 2: Finally, note that I am presenting code, here. When I write it, I like using "one liners" which include representative sample data. For example, something like: (zmin + 1 i.@<.@- zmin - ] % 2:) 57 or even (z=: zmin + 1 i.@<.@- zmin - ] % 2:) 57 This helps me catch "trivial" mistakes (because I can see that the result is wrong). As for a closed form solution, if there is one, it would probably be related to whatever they are currently studying - a quick review of the class materials would probably help there. That said, I am usually comfortable with "brute force" solutions to packing problems. Thanks, -- Raul On Sat, May 25, 2013 at 9:38 AM, Olivier N. <[email protected]> wrote: > Thanks for such a detailed answer! I'll read it carefully. > It's still hard for me to develop array programming reflexes > and even harder to optimize code in J. > > In the meantime, I turn the math bit on and found another way > to compute the answer, avoiding brute force. It should even be > possible to find a direct formula but I didn't take the time. > > Here is what I suggest: > > peri =: 57 > zmin =: 1 + >. peri % 3 NB. z + (z-1) + (z-2) >: peri > z =: zmin + i.( <.1 - zmin - peri % 2) NB. z < peri % 2 > +/ (<. 1.5 * z) - >. 0.5 + peri %2 NB. (y+(y-1)>:peri-z)*.(y<z) > > I'm sure there is a much shorter way to code this in J, > even if it won't probably change a lot computing time. > Could you show me the way to a one-liner? > > Thanks in advance, > > Olivier > >> On 05/24/2013 10:36 PM, Raul Miller wrote: > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
