Re: Help Bot Advice adopted.

Patrick Volk wrote:
> On Fri, 9 May 2008 09:57:41 -0700 (PDT), Sanny <softtanks@[EMAIL PROTECTED]
>
> wrote:
>> Yes, I will see if that can be corrected. It is very difficult to
>> modify the code as changing one line of code brings new Bugs and then
>> a week is wasted in correcting the Bugs.
> 
> That statement tells me quite at least 2 things:
> 
> 1) There's a lot of copy and paste in your code (parts tend to look
> alike, with minor modifications... some question as to whether making
> a change is the right one).

It would make sense to split the code into clean separate modules (even 
if there was initially a slight performance penalty).

It is probably well worth profiling it to see exactly where it spends 
all its time. Getting the thing to run faster would help a lot. You will 
probably find that it spends all its time in the terminal node eval.

> 2)  You're probably not using the benefits of Java. Your display might
> be OO, but I doubt that your chess analysis part did. What I know
> about some contem****ary chess engines (the company I work for built
> the boards for Deep Blue) is that they evaluate each space. 

That is a hardware accelerator tactic which can consider all the squares 
using a local sub processor per square. I don't think it works so well 
on a PC.
> 
>   You can score the piece count, but you also can score position...
> Simplistically by how many squares are controlled. You only have 3
> different kind of squares.

I get the impression it is already a bit better than that, but that 
there is something horribly wrong with its quiessence search. Perhaps 
because it thinks that pinned pieces can move or something... see the 
game with the mobile phone.

>   Also I have to agree with what someone else said. For testing
> purposes, you really should work on handling position notation. One of
> the beauties of chess is the state of the game can store in so few
> bytes (64 and be comfortable). If you have a position that is, say, a
> mate in 5, you can try that position against different versions (and
> load it against different opponents as well).

Regression testing at least means that you can be sure the program still 
gets right all the test cases you have tested and fixed so far as well 
as any new ones.

>   Checks and draws should be some sort of function... I forget whether
> you play a particular sound when the person is in check, but you can
> use it for that, and also to put a '+' in the notation (or '#' for
> checkmate). 

Human readable output needs a couple more tweaks and it would be OK. 
Like for example putting the players and dates in the right sort of 
brackets and format for standard engines to read.
> 
>> Its like when we fly Kites. When the threads messup how difficult it
>> is to correct the jumbeled threads.
>>
>> This Program is so large that if I have to read whole program line by
>> line, it will take me full day. So its very difficult to go through
>> all the codes and correct them.

Bulk spagetti code is not a viable programming model. It is time to 
restructure the code and separate the evaluation, move generation and 
alpha-beta search into clearly separate modules. Ultimately the majority 
of the changes should be in eval once the other components are stable.
> 
> 200K isn't that large, even for a one-person project.

It is large if there is no well defined overall structure.

Regards,
Martin Brown
** Posted from http://www.teranews.com
**