Author: Dann Corbit
Date: 22:01:54 07/22/02
Go up one level in this thread
On July 23, 2002 at 00:49:51, Peter Kappler wrote:
>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.
>:)
It might also win you a few games. I have seen "short sighted" underpromotions
to rook or bishop that look like a good idea for 8-9 plies or some such thing in
a blitz game. Longer analysis would have said to push to a queen. The same
also happens for underpromotion to knight {more rarely}. It think an
underpromotion penalty that is a function of the depth in plies analyzed might
be a good idea.
This page took 0.02 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.