Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Parallel algorithms in chess programming

Author: José Carlos

Date: 06:32:57 04/18/01

Go up one level in this thread


On April 18, 2001 at 00:25:17, Tony Werten wrote:

>On April 17, 2001 at 16:14:02, José Carlos wrote:
>
>>On April 17, 2001 at 15:16:46, Tony Werten wrote:
>>
>>>On April 17, 2001 at 09:21:42, José Carlos wrote:
>>>
>>>>On April 17, 2001 at 03:08:42, Tony Werten wrote:
>>>>
>>>>>On April 16, 2001 at 18:15:52, Dieter Buerssner wrote:
>>>>>
>>>>>>In a different discussion, Vincent wrote the following:
>>>>>>
>>>>>>>It is not difficult to implement the form of parallellism as used by
>>>>>>>Rudolf. Invented by a frenchman who couldn't spell a word english and
>>>>>>>who wrote an impossible article for JICCA (did anyone proofread it at
>>>>>>>the time as i'm pretty sure they didn't get his parallel idea?).
>>>>>>>
>>>>>>>At the time when i read the article i was pathetically laughing about it
>>>>>>>actually as i also didn't get the idea of the frenchman. But it appears
>>>>>>>everyone who can make a chessprogram work under win2000 can also get
>>>>>>>within an afternoon his program parallel to work. Then some debugging
>>>>>>>and a day later it works cool.
>>>>>>
>>>>>>I'd be very interested in this algorithm, that can be implemented at an
>>>>>>afternoon :-)
>>>>>>
>>>>>>Could you point elaborate on this.
>>>>>>
>>>>>>BTW. In Paderborn, Roland Pfister also told me, that he knows this from Rudolf
>>>>>>Huber, and he even started to explain it to me. Somhow, we (or me) got
>>>>>>distracted, and I cannot remember the essential things.
>>>>>>
>>>>>>What I remember is, that the time consuming work, of making your
>>>>>>search/evaluation routines free from all those global variables is not needed.
>>>>>>
>>>>>>Regards,
>>>>>>Dieter
>>>>>
>>>>>I haven't tried parallelism yet, but my (very) simple approach would be:
>>>>>
>>>>>Since my program spends most of its time in eval(), split it in evalblack() and
>>>>>evalwhite(). No need for many changes. Haven't got a clue what the speedup would
>>>>>be, but it's easy to try.
>>>>>
>>>>>cheers,
>>>>>
>>>>>Tony
>>>>
>>>>  Are you sure you spend most of your time in eval? My problem is inCheck()
>>>>since ever. That's where my prog spends most of the time.
>>>
>>>Then you're doing something wrong.
>>>
>>>Take the last move. To make it easy: If it's a special move do your normal check
>>>code.
>>>
>>>If it's not look if the fromsquare is a queenmove from the king. If not it
>>>cannot be a discovered check else walk from to king in the direction of that
>>>square and look if there a checking piece. Stop if blocked.
>>>
>>>Do the same for the to square.
>>
>>  I'm trying something like that in my new rewrite, but it's much more
>>complicated. Consider en passant captures (which removes an enemy pawn)
>>a promotion (which makes a new pice to appear on the board), castling, captures...
>>  You must check for _many_ special cases.
>
>No, actually only castle and en passant are special. All the other moves are the
>same. A piece disappears of the fromsquare (giving the possibility of discovered
>check ) and a piece appears on the tosquare (possibly giving check if the piece
>on the square can attack the kingsquare )
>
>It's even easier for checking legal moves (ie not leaving yourself in check) if
>you were not in check to start with.

  Mmm, I was talking about this (checking legal moves) from the beginning.
Actually the biggest problems occur when you are already in check, and have to
decide if the move you've just done eliminates the check.
  But I'm begining to suspect I'm missing something anywhere. I'll rethink all
of this.

  José C.


[snip]



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.