Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Updating strange attack boards

Author: Richard Pijl

Date: 06:34:49 03/19/03

Go up one level in this thread


On March 19, 2003 at 08:28:02, Ricardo Gibert wrote:

>On March 19, 2003 at 06:33:01, Matthias Gemuh wrote:
>
>>I decided to stop chess programming but even the latest version of my program
>>sucks. How can I quit in peace?
>>It calculates this attack information (bitboards of attackers to 64 squares)
>>    BITBOARD AttacksTo[64]
>>from scratch at each node. I tried to do this incremementally and it quickly got
>>messy and buggy because of sliding pieces, castle, en passant.
>>How do you attack attack boards (even the conventional type)?
>>
>>/Matthias.
>
>
>Let me share a couple of observations I have made concerning the development of
>amateur chess programs.
>
>The 1st big mistake I see repeatedly is being in too much of a rush make their
>programs strong by adding "fancy stuff." A very simple program can be fairly
>strong (> 2200 elo). You just need to get the fundamental things to work right
>*first*. Gerbil is a good example of what is possible with a reasonably simple
>program (about 2400 ICC rating). Don't layer the "fancy stuff" on top of the
>incorrectly implemented fundamental stuff.

I agree.

>
>The 2nd big mistake I see repeatedly is thinking that speed optimizations can
>make a significant difference. Even if their dream could come true and they
>could double the NPS, this only amounts to about 50 rating points. What they
>actually achieve (usually) is to make their program less readable and less
>modifiable. In this way, they bury theirs errors and make real progress
>problematic.

I consider efficient and clear programming of functionality part of the
fundamental stuff. With inefficient programmed attackboard stuff you can limit
the depth reached by your program significantly. And yes I'm talking about
optimizations that gain more than 10%.

I agree that implementing efficient mechanisms should always result in clear and
readable code. Optimizing is imho about smart algorithms, not about unreadable
code ...

Richard.

>Concentrate on getting fundamental things done right in a clear way and only
>*after* your program is reasonably strong in this manner should you consider the
>"fancy stuff." It should take a good while before you get to this point unless
>you are Mister Amazing or you've done it all before successfully.
>
>As for optimizing, it's usually just a trap. The only speed optimizations you
>should consider are the ones that make your programs simpler and clearer.
>Otherwise, they're not worth the trouble.
>
>Remember: Think simple and clear.



This page took 0 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.