Re: "Attack" -- Find Solutions for N Non-Attacking Chess Pieces

I have not tried running this, or even looked at your code very carefully, but i wanted to make a suggestion regarding the format of your Legal.pm...

It seems like it might be a lot more readable (and probably reusable when defining hypothetical pieces) if you created named hash refrences for the two major classifications of move types: diagonally and horizontally. Then defined the legal attacks for the individual pieces based on those where appropriate (ie: bishop is an alias for the diagonal hash, rook is an alias for the horisontal hash, queen is a merge of both).

Alternatly (and the more i think about it, even better) you could impliment the set of legal attacks for a peice as a function ref instead of a hash ref -- where the function takes in a current location, and returns the list of legal atacks -- for simple pieces like the rook, pawn and king these functions are trivial. for things like bishop, and knight the math is a little more complicated, but still much shorter then your giant hashes. Once again the queen can be implimented by calling both the rook and bishop functions and unioning the results.

Comment on Re: "Attack" -- Find Solutions for N Non-Attacking Chess Pieces

Replies are listed 'Best First'.
Re^2: "Attack" -- Find Solutions for N Non-Attacking Chess Pieces by liverpole (Monsignor) on Jan 14, 2006 at 14:02 UTC
Well, let me explain why I didn't choose any of those methods for implementing the data structure. I implemented the data structure before anything else, including the original Eight Queens Problem, and one of my foremost priorities for it was speed. That would rule out function references; if you're trying to make things as fast as possible, you can't make each legal move a function call. As far as why I didn't define things in terms of diagonals versus horizontal/vertical moves: the data structure needed to contain AoA for each square for each piece rather than simply an array, and the reason for that was, when calculating the directions for a piece such as a bishop, rook or queen, you have to stop as soon as you hit another piece (if the piece is of the opposite color, it can be captured, of course). Besides which, pawns, knights and kings wouldn't follow those same rules, so what would be the point? When I created the data structure, I did actually calculate the rook moves and bishop moves first, and then just "added" them together to get the queen. So I hope you understand my reasoning. Maybe if you try running the program, you'll see why optimizing for speed was my primary goal. @ARGV=split//,"/:L"; map{print substr crypt($_,ord pop),2,3}qw"PerlyouC READPIPE provides"	[reply]

Replies are listed 'Best First'.

Re^2: "Attack" -- Find Solutions for N Non-Attacking Chess Pieces
by liverpole (Monsignor) on Jan 14, 2006 at 14:02 UTC

I implemented the data structure before anything else, including the original Eight Queens Problem, and one of my foremost priorities for it was speed. That would rule out function references; if you're trying to make things as fast as possible, you can't make each legal move a function call.

As far as why I didn't define things in terms of diagonals versus horizontal/vertical moves: the data structure needed to contain AoA for each square for each piece rather than simply an array, and the reason for that was, when calculating the directions for a piece such as a bishop, rook or queen, you have to stop as soon as you hit another piece (if the piece is of the opposite color, it can be captured, of course). Besides which, pawns, knights and kings wouldn't follow those same rules, so what would be the point?

When I created the data structure, I *did* actually calculate the rook moves and bishop moves first, and then just "added" them together to get the queen.

So I hope you understand my reasoning. Maybe if you try running the program, you'll see why optimizing for speed was my primary goal.

@ARGV=split//,"/:L"; map{print substr crypt($_,ord pop),2,3}qw"PerlyouC READPIPE provides"

[reply]