Author: Dann Corbit
Date: 21:33:52 07/22/02
Go up one level in this thread
On July 23, 2002 at 00:14:49, Russell Reagan wrote:
>I am attempting to use an object-oriented approach in developing my engine, and
>I have a problem and question about handling promotions.
>
>My problem is that my object-oriented design prevents me from handling promotion
>as efficiently as I'd like. I would like to handle it by storing the piece to
>promote to in my move structure, then to promote it's simply a copy of the piece
>type over the existing pawn type. Something like this:
>
>squares[move.to] = move.promotePiece;
>
>That's nice and simple, and it probably doesn't get much faster. Using an
>object-oriented approach, I have to do something like this:
>
>if (move.isPromotion()) {
> if (move.isPromotionToQueen())
> squares[move.to()].promoteToQueen();
> else if (move.isPromotionToRook())
> squares[move.to()].promoteToRook();
> else if // you get the idea
>}
>
>This isn't quite as simple, and not quite as fast, but it's not exactly huge or
>complex either. I suppose that it's not a huge penalty since we usually promote
>to queen anyway.
>
>I really have two questions regarding this. Can anyone think of a better way to
>handle this without the position class having to access the move class' private
>data? I'd like to avoid those dependencies, since if I allow them that kind of
>defeats the purpose of doing it object-oriented in the first place. Perhaps I'm
>trying to force a non-OOP shape into the OOP shaped hole.
>
>My second question is, is the case of promotion rare enough for this to not
>really be an issue? I think it probably isn't, but I have nothing other than a
>hunch to back that up. Then again, if promotion is there but it's still quite a
>few plys away, the slightly less efficient method would increase that
>inefficiency exponentially.
>
>I also wonder if it even matters, since one side is about to promote and gain a
>(usually) decisive advantage, it shouldn't matter if it slowed down horribly for
>a breif time.
>
>Any thoughts?
Why all the is() functions? The promotions are just another possible move.
Do you say:
if (move.isKnightMove()..)
else if move.isPawnPush()...
...
BTW, generate them in this order:
promote to queen (almost all the time it is this choice)
promote to knight (this one takes up almost all of the remainder)
promote to bishop (rook and bishop promotions are very, very rarely of any use)
promote to rook (see above -- I doubt if it matters whether it is rook or bishop
first, but the first two are keenly important for your move order)
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.