Hmm, there is an annoyance. } is specified in terms of {, and:
$(1 0;0 1){i.2 2
2
$(,<1 0){i.2 2
1
$''{i.2 2
0 2
On the other hand, it's _really_ annoying that the original code doesn't work.
Thoughts--would it be permissible for } to be more relaxed here? It is
difficult because im
'' ''} i.2 2
|length error
| ''''}i.2 2
Should it be an error? I would expect it not to be, because:
(,27) (,<1 0)} i.2 2
0 1
27 3
(27 28) (1 0;0 1)} i.2 2
0 28
27 3
So the original snippet is just the degenerate case where no indices are
supplied. But I want to ensure I am
Taking this a bit further (though I have not actually tested this, so
I might be way off base), I suspect that I and R here should be:
conf =. {{ (#.y*"1#:i.256)+/#.(-.y)#inv"1#:i.16}}
r =. conf 4#1 0
c =. conf 4#0 1
b =. conf 8$2#1 0
p =. conf 8$2#0 1
I =: ~."1 r,
FWIW, I've been looking at this, and my own slower and more
space-consuming versions.
I tried amending Roger's similar original code, posted in the forum, I
think, with obvious
changes as follows. Some of his verbs, including your ac & ar I think
differ in the wiki article
from the ones I
P.S. for the "fourth constraint", I imagine that "position within the
block" would be "the right approach".
In other words, you have a 4x4 grid of 4x4 blocks. So, for example, it
should be forbidden for the upper left corner of any block to have the
same value as the upper left corner of any other
On Sun, Jun 19, 2022 at 12:42 PM Brian Schott wrote:
> Instead I want to look more closely at his results for the verbs
> AR and AC. In his algorithm he takes the larger of the two results, that is
> the larger of AR or AC , where he expects one of each pair to be zero and
> the other to be a vali
Raul,
I truly appreciate your comments and while they seem very reasonable I do
not know how to delve more deeply into the permutations as you suggest. I
am leaning more to dropping the idea of finding a solution based on Roger’s
algorithm. Instead I want to look more closely at his results for th
