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,.c,.b,.p
j =. (]/. i.@#) ,{;~4#i.4
R =: j,&(,|:)i.16 16
FYI,
--
Raul
On Sun, Jun 19, 2022 at 1:21 PM Raul Miller <rauldmil...@gmail.com> wrote:
>
> 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 block. (Same for
> upper right, lower left, lower right, and the analogous positions
> towards the middle of the blocks.)
>
> This would require a companion value for r, c and b (and of course
> would require a similar adjustment in the calculation of R).
>
> I hope this makes sense?
>
> --
> Raul
>
> On Sun, Jun 19, 2022 at 1:12 PM Raul Miller <rauldmil...@gmail.com> wrote:
> >
> > On Sun, Jun 19, 2022 at 12:42 PM Brian Schott <schott.br...@gmail.com>
> > 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 valid candidate. Whenever there is a nonzero AC it is a
> > > unique and correct candidate, but the values for AR are selected using
> > > index of, i. . I am suspicious that the selection of AR is almost
> > > arbitrary
> > > and is causing the problem. I think a human being could do a better job of
> > > selecting among the alternatives from AR.
> >
> > My understanding is that ar and ac are approaching the solution "from
> > the opposite ends".
> >
> > ac looks for *positions* which are completely constrained -- these
> > positions have only one possible value
> >
> > ar looks for *values* which are completely constrained -- these values
> > have only one possible position. So I guess my concern could have been
> > rephrased as: what happens when ar tries to assign values when the
> > positions are not completely constrained?
> >
> > > If I am correct about using AR and AC to help a human, I would use a
> > > variation on AC that shows all of the possible results instead of the one
> > > captured by the ‘index of’ primitive. In light of that I am looking for
> > > ways to use 4 x 4 arrangements of dots to display each of the cell’s
> > > information. I was looking in the Unicode lists for 4 x 4 dot arrangements
> > > but was unable to find any, so I am trying to imagine alternatives. So far
> > > I can only think of using viewmat to construct the dot patterns.
> >
> > If viewmat is acceptable, and you are using jqt, you might want to
> > consider using wd to present the grid.
> >
> > That said, a 4 4 $ of some ascii characters might also work. (But a wd
> > based approach would allow you to "highlight" or emphasize the
> > corresponding row and column also.)
> >
> > That said, if you do not address the underlying lack of complete
> > constraint in the puzzle design, this might turn out to be quite a bit
> > more difficult than sudoku. (Do you have worked examples illustrating
> > this puzzle variation? If so, maybe the difficulty is a feature rather
> > than a bug...)
> >
> > I hope this helps,
> >
> > --
> > Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
