On Mon, 12 May 2008 08:38:04 +0100, Martin Brown
<|||newspam|||@[EMAIL PROTECTED]
> wrote:
>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.
C&P is a consequence generally of wandering design. You find some code
that could work, and instead of re-factoring it to fulfill all cases,
you copy and modify it for each.
One of the levels of programming hell (hell not only to maintain, but
to test)!
>
>> 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.
It used at least one processor per square. A PC could thread it, yeah,
not as fast, but it lends itself to replication.
>>
>> 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.
Where A-B pruning comes in. At the level it's at, I don't think you're
going to find a queen sacrifice 4 plies down. Bail!
>
>> 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.
Sanny's idea of regression testing is release, and saying how it's
improved 200%.
>
>> 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.
Exactly my point. His comments indicate he may not have painted
himself into the corner just yet, but there's probably no doorways or
windows around.
A program isn't philosophically a journey - it's more like a tour.
You have a list of sights to see.
>>
>> 200K isn't that large, even for a one-person project.
>
>It is large if there is no well defined overall structure.
Very true.
>
>Regards,
>Martin Brown
>** Posted from http://www.teranews.com
**
|
