My point being, if Michael Rice is exploring how to solve peg solitaire,
it's often useful to work on small(er) problems, before perhaps getting
stuck in a long loop, or seeing the memory climb and one's pc seize up
and need rebooting.
But he'll know all this stuff anyway!
BTW, re Raul's useful thoughts on union matters, same thread, earlier post.
I've just noticed that the intersection I posted, ix = [-.-. , is,
perhaps, "lazy";
better might be ~.@([-.-.), but neither is appropriate for bit-vector
comparisons!
Cheers,
Mike
On 06/06/2017 10:28, Raul Miller wrote:
On Tue, Jun 6, 2017 at 4:09 AM, 'Mike Day' via Programming
<programm...@jsoftware.com> wrote:
if I were developing a solver for solitaire, I'd include a variable as a
parameter for
the size of problem, eg the number of rows, 1 2 3 etc, or the ravel-size,
eg 1 3 6 etc.
You had not specified that previously, but note that implementing this
is a simple change.
For example:
flip=: [ ~: i.@#@[ e. ]
solitaire=:3 :0
5 solitaire y
:
path=. (y flip~ 1#~ 0 0.5 0.5 p. x) search i.0 3
if. #path do. path else. 'No solution' end.
)
That said, the 'No solution' cases require a time-consuming exhaustive
search, and in the few tests I did with sizes other than 5, I was
hitting no solution cases. It's time consuming because each
permutation of moves that leads to a final board state gets tested.
Still, I hope this helps,
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
