Author: Peter Kappler
Date: 21:49:51 07/22/02
Go up one level in this thread
On July 23, 2002 at 00:33:52, Dann Corbit wrote:
>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()...
>...
I agree. You're going way overboard if you have per-piece versions of all those
functions. Keep it simple.
>
>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)
You could also ignore rook and bishop underpromotions. This might cost you a
half point once every 500,000 games or so, but I think the speedup is worth it.
:)
-Peter
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.