Author: Uri Blass
Date: 13:30:47 05/27/04
Go up one level in this thread
On May 27, 2004 at 16:17:02, Filip Tvrzsky wrote:
>On May 27, 2004 at 15:42:13, Uri Blass wrote:
>
>>On May 27, 2004 at 15:09:42, James Swafford wrote:
>>
>>>On May 27, 2004 at 14:35:54, Uri Blass wrote:
>>>
>>>>On May 27, 2004 at 07:39:37, milix wrote:
>>>>
>>>>>Hello!
>>>>>Chess enging bugs (CEBUGS) are very different than normal bugs (BUGS). They are
>>>>>very good in hiding from debuggers. They are also very good in covering one
>>>>>another so the engine seems to behave normaly, except if it plays a very
>>>>>important match. Sometimes CEBUGS are very productive and when they are
>>>>>eliminated the engine's strength drops about 50-150 points. Of course they have
>>>>>to be eliminated otherwise the engine cannot deliver a mate in KQvsK or it
>>>>>always thinks that passed pawns are Gods. CEBUGS are also layered and they are
>>>>>very cooperative. In the first layer we have the evaluation bugs (usualy +
>>>>>instead of -). In the next layer we can find search bugs (improper alpha - beta
>>>>>windows, or wrong score sign or null-move bugs). In the final layer we meet the
>>>>>most powerful bugs ever, the transposition table bugs. These bugs have a stealth
>>>>>ability, they are protecting the bugs in the first two layers while their
>>>>>actions mimic the behaviour of an evaluation term or a search property (like
>>>>>failing low).
>>>>>
>>>>>I am sure that other bugs exists in my engine but I haven't had the honor to
>>>>>meet them yet.
>>>>>
>>>>>PS: In the Null-Move search you might have forgotten to clear the ep-square as
>>>>>well as to restore it. This bug is very easy to detect and fix. But if you have
>>>>>forgotten to update the hash signature (if you encode ep square in the hash
>>>>>signature) then you are very lucky. You have met a Predator-like bug.
>>>>
>>>>I did some progress in making my book code(it is still not ready at this moment)
>>>>and I can describe some bugs in the process:
>>>>
>>>>1)I asked the computer to print the moves in the book only to discover that
>>>>printf("%s %s",move1,move2) does not work.
>>>
>>>Are move1 and move2 char* 's? If so, that should be fine.
>>>What's happening?
>>>
>>>
>>>--
>>>James
>>
>>I do not know but for me it did not work and the computer printed the first
>>string twice instead of printing 2 different strings.
>>
>>Try the following code that is part of movei:
>>
>>
>>#define rankfrom(u) (((u)>>3)&7)
>>#define rankto(u) (((u)>>9)&7)
>>#define filefrom(u) ((u)&7)
>>#define fileto(u) (((u)>>6)&7)
>>#define promotion(u) ((u)&(1<<29))
>>#define promote(u) (((u)>>16)&255)
>>
>>char *move_str(int move)
>>{
>> static char str[6];
>>
>> char c;
>>
>> if (promotion(move)) {
>> switch (promote(move)) {
>> case KNIGHT:
>> c = 'n';
>> break;
>> case BISHOP:
>> c = 'b';
>> break;
>> case ROOK:
>> c = 'r';
>> break;
>> default:
>> c = 'q';
>> break;
>> }
>> sprintf(str, "%c%d%c%d%c",
>> filefrom(move) + 'a',
>> rankfrom(move)+1,
>> fileto(move) + 'a',
>> rankto(move)+1,
>> c);
>> }
>> else
>> {
>> sprintf(str, "%c%d%c%d",
>> filefrom(move) + 'a',
>> rankfrom(move)+1,
>> fileto(move) + 'a',
>> rankto(move)+1);
>> }
>> return str;
>>}
>>
>>printf("%s %s",move_str(1),move_str(0));
>>
>>//result b1a1 b1a1
>>
>>printf("%s %s",move_str(0),move_str(1));
>>
>>//result a1a1 a1a1
>>
>>Uri
>
>This is an easy one: your strings share one common place in memory, namely the
>variable static char str[6]. Therefore when you call move_str() for the second
>time, the first string gets overwrited.
>Filip
I do not understand why they share one place in memory.
The computer is supposed to do the following:
1)calculate move_str(0)
2)forget every local varaible including str[6]
3)calculate move_str(1)
4)forget every local varaible.
Note that it seems to do it in that way when I do it in 2 different printf for 2
strings but not when I use one printf.
Uri
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.