Speaking of false evidence...

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

User avatar
geots
Posts: 4790
Joined: Sat Mar 11, 2006 12:42 am

Re: Speaking of false evidence...

Post by geots »

Zach Wegner wrote:
geots wrote:Exactly what world did you wake up in Graham- if it is the truth- which i am quite certain it is- they will ignore it and/or divert attention away from it. This was never a quest for truth- merely a witchhunt.
George,

When can I expect my apology?

:lol:

Zach, you see what i am telling you about jumping the gun. No matter what is proved or disproved in this one particular thread, it makes Vas guilty of nothing. So what am i apologizing for. In the end that is my primary concern. His guilt or innocence.
User avatar
Graham Banks
Posts: 41423
Joined: Sun Feb 26, 2006 10:52 am
Location: Auckland, NZ

Re: Speaking of false evidence...

Post by Graham Banks »

Zach Wegner wrote:[I have no ill will towards you Graham. I just ask that speculative comments are kept to a minimum, and you seem to be one of the few here who is reasonable enough to listen.
Yeah - I have no wish to make enemies either, but having been a moderator makes one good at it unfortunately (even without trying). :)
I know you think you're right. Just be careful. Make sure that you're your own master and not somebody else's puppet.

Regards, Graham.
gbanksnz at gmail.com
User avatar
Zach Wegner
Posts: 1922
Joined: Thu Mar 09, 2006 12:51 am
Location: Earth

Re: Speaking of false evidence...

Post by Zach Wegner »

geots wrote:Zach, you see what i am telling you about jumping the gun. No matter what is proved or disproved in this one particular thread, it makes Vas guilty of nothing.
I completely agree. But it was you who said that we are not interested in truth. You have from the beginning assumed Vas to be innocent, and when Dann posts something that might show I am wrong, it takes you less than 10 minutes to post "And they have taken this poor innocent kid, pumped him up, and sit back and shamelessly let his name be drug thru the mud". But for each piece of evidence I have posted, nothing.

You immediately assumed that Dann was right because it supported your argument. Yet when it is quickly shown to be false, complete silence. Now who exactly is interested in the truth?? I know of at least two times that I have been wrong in this discussion, and I was quick to admit my fault. The ball is in your court now George. If you want your words to hold any weight, now is the time to speak up.
User avatar
Zach Wegner
Posts: 1922
Joined: Thu Mar 09, 2006 12:51 am
Location: Earth

Re: Speaking of false evidence...

Post by Zach Wegner »

Graham Banks wrote:I know you think you're right. Just be careful. Make sure that you're your own master and not somebody else's puppet.
Hehe, you can be sure of that. :twisted:

Unfortunately, sometimes I feel like I could say the same thing to this whole community...

Take it easy Graham. We are in this for the fun after all! :D

Regards,
Zach
Damir
Posts: 2801
Joined: Mon Feb 11, 2008 3:53 pm
Location: Denmark
Full name: Damir Desevac

Re: Speaking of false evidence...

Post by Damir »

I do not understand you guys, nobody wanted to know if Rybka had some of the Fruit code inside 2 years ago.
Vas made himself clear that he looked on the free source of Fruit and took many things when he created Rybka in that interview on superchessengines.
The guy has been honest all along.
Why jumping the gun around, and accuse Vas of beeing a cloner?
User avatar
geots
Posts: 4790
Joined: Sat Mar 11, 2006 12:42 am

Re: Speaking of false evidence...

Post by geots »

Zach Wegner wrote:
geots wrote:Zach, you see what i am telling you about jumping the gun. No matter what is proved or disproved in this one particular thread, it makes Vas guilty of nothing.
I completely agree. But it was you who said that we are not interested in truth. You have from the beginning assumed Vas to be innocent, and when Dann posts something that might show I am wrong, it takes you less than 10 minutes to post "And they have taken this poor innocent kid, pumped him up, and sit back and shamelessly let his name be drug thru the mud". But for each piece of evidence I have posted, nothing.

You immediately assumed that Dann was right because it supported your argument. Yet when it is quickly shown to be false, complete silence. Now who exactly is interested in the truth?? I know of at least two times that I have been wrong in this discussion, and I was quick to admit my fault. The ball is in your court now George. If you want your words to hold any weight, now is the time to speak up.

No Zach, im no progammmer and never claimed to be. I still dont know who is right and who is wrong about the above figures. I dont even know what they mean. But i know Vas better than anyone here- that is why i know the truth. And the above figures dont make a case either way. if i led you to believe i thought this was the final word- i am sorry. But i can promise you this- when push comes to shove, by your above comments, you dont know me at all. If you are my friend- I will be there for you when the world has left.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Speaking of false evidence...

Post by bob »

Zach Wegner wrote:
geots wrote:Zach, you see what i am telling you about jumping the gun. No matter what is proved or disproved in this one particular thread, it makes Vas guilty of nothing.
I completely agree. But it was you who said that we are not interested in truth. You have from the beginning assumed Vas to be innocent, and when Dann posts something that might show I am wrong, it takes you less than 10 minutes to post "And they have taken this poor innocent kid, pumped him up, and sit back and shamelessly let his name be drug thru the mud". But for each piece of evidence I have posted, nothing.

You immediately assumed that Dann was right because it supported your argument. Yet when it is quickly shown to be false, complete silence. Now who exactly is interested in the truth?? I know of at least two times that I have been wrong in this discussion, and I was quick to admit my fault. The ball is in your court now George. If you want your words to hold any weight, now is the time to speak up.
Zach, one part of this discussion speaks _volumes_. What part?

Here's an exercise: Count the number of posts in each thread spawned by this discussion. Guess which ones are the shortest, and quickly drop to the bottom due to no recent posts? You got it - posts where you or others have posted actual data, which is not what most want to see.

Which threads have the most activity? The ones where everybody is either "attaboy'ing Dann or someone else". That is, the threads with no useful content about the main point that has been raised.

Some say "show me the data." Someone tells them "it is here" and they can't/won't find it. Someone posts a link. Dead silence or "oh, _THAT_ thread". Some want to declare the debate over before it is even started, no doubt hoping that will kill it before it can produce enough evidence to settle the issue. I've never seen anything quite like it.

What is particularly of interest is that 90% of the posts are from people that have no clue (a) what is being technically discussed; (b) how to interpret the technical aspects that are being discussed; (c) understand anything about developing large software systems.

It would be funny, if it were not so sad. I get a ton of grief when I say "blocks of identical code are not commonly produced, even when the application is as well-defined as computer chess." You get grief about the presence or absence of strtok() when it is not even clear the detractors know what the devil it actually does. Pick any two of Rybka, strelka and fruit and discuss them, and someone is always going to say "but that has nothing to do with xxx (which was the one omitted in that particular post)".

There is a trend. They say some have "made up their mind already." I have said I have not, but I have also said that the evidence is mounting, and that things IMHO look somewhat suspicious. But I have made up my mind, according to "them". Of course, the fact that they had their mind made up before seeing the first piece of data is unimportant. Because apparently "we" have made ours up.

But just watch the technical discussions/presentations drop like a brick to the bottom of the threads, because they are not going to respond to _those_ and actually try to help figure out what exactly has happened, if anything. They hope they can drown the discussion out in the old "if you can't dazzle me with brilliance, baffle me with bullshit" approach to debate. And so it goes.

But eventually the truth will come out, whatever it is. And contrary to some, whatever the result, there is no "shame" in raising the issue in light of the things that have already been shown. They'd prefer everyone think otherwise. They want to threaten. Insinuate legal problems. Let 'em go for it for real and see how that goes...
Tony

Re: Speaking of false evidence...

Post by Tony »

Dann Corbit wrote:Here are assembly listings created from the binaries of Strelka 1.0, Rybka 1.0 Beta, Fruit 2.1 using IdaPro freeware:
http://cap.connx.com/chess-engines/new- ... ompare.zip

It is interesting to note that the UCI parser of Rybka 1.0 definitely does not even call strtok().

We have been quibbling over false information. These so-called source code dumps are whimsical fabrications.

You can get IdaPro Freeware here:
http://www.hex-rays.com/idapro/idadownfreeware.htm

and repeat the experiment for yourselves. The UCI parsers of Fruit 2.1 and Rybka 1.0 are not terribly similar and Rybka clearly does not use strtok() at all.

I suggest that it will be a worthwhile exercise to perform the experiments yourselves and not rely on the words of someone else (including me!)
Dan,

why are you trying to look like a neutral casual passer by ? You know you're not.

You saw the Strelka code before ( one of the first) and didn't even recognize Fruit in it.

When I disagreed with you, you stated that either one of us had to bare the consequences and threw away his credibility.

It seems it is again you.

Tony
CThinker
Posts: 388
Joined: Wed Mar 08, 2006 10:08 pm

Re: Speaking of false evidence...

Post by CThinker »

Dann Corbit wrote:
Zach Wegner wrote:Sorry again Dann, but you are again wrong. It is there, without the function name.

Please Dann, if you are going to say that what I post is "whimsical fabrications", please investigate it a little more.

Code: Select all

.text:0040EDDB strtok          proc near               ; CODE XREF: start_go+A9p
.text:0040EDDB                                         ; start_go+B4p ...
.text:0040EDDB
.text:0040EDDB var_2C          = dword ptr -2Ch
.text:0040EDDB var_28          = dword ptr -28h
.text:0040EDDB var_24          = dword ptr -24h
.text:0040EDDB var_4           = dword ptr -4
.text:0040EDDB arg_0           = dword ptr  8
.text:0040EDDB arg_4           = dword ptr  0Ch
.text:0040EDDB
.text:0040EDDB                 push    ebp
.text:0040EDDC                 mov     ebp, esp
.text:0040EDDE                 sub     esp, 2Ch
.text:0040EDE1                 mov     eax, dword_663608
.text:0040EDE6                 xor     eax, ebp
.text:0040EDE8                 mov     [ebp+var_4], eax
.text:0040EDEB                 mov     eax, [ebp+arg_0]
.text:0040EDEE                 push    ebx
.text:0040EDEF                 push    esi
.text:0040EDF0                 mov     esi, [ebp+arg_4]
.text:0040EDF3                 push    edi
.text:0040EDF4                 mov     [ebp+var_2C], eax
.text:0040EDF7                 call    sub_411438
.text:0040EDFC                 push    8
.text:0040EDFE                 pop     ecx
.text:0040EDFF                 mov     [ebp+var_28], eax
.text:0040EE02                 xor     eax, eax
.text:0040EE04                 lea     edi, [ebp+var_24]
.text:0040EE07                 push    7
.text:0040EE09                 rep stosd
.text:0040EE0B                 pop     edi
.text:0040EE0C
.text:0040EE0C loc_40EE0C:                             ; CODE XREF: strtok+4Aj
.text:0040EE0C                 mov     dl, [esi]
.text:0040EE0E                 movzx   ecx, dl
.text:0040EE11                 mov     eax, ecx
.text:0040EE13                 and     ecx, edi
.text:0040EE15                 mov     bl, 1
.text:0040EE17                 shl     bl, cl
.text:0040EE19                 shr     eax, 3
.text:0040EE1C                 lea     eax, [ebp+eax+var_24]
.text:0040EE20                 or      [eax], bl
.text:0040EE22                 inc     esi
.text:0040EE23                 test    dl, dl
.text:0040EE25                 jnz     short loc_40EE0C
.text:0040EE27                 mov     edx, [ebp+var_2C]
.text:0040EE2A                 test    edx, edx
.text:0040EE2C                 jnz     short loc_40EE3B
.text:0040EE2E                 mov     eax, [ebp+var_28]
.text:0040EE31                 mov     edx, [eax+18h]
.text:0040EE34                 jmp     short loc_40EE3B
.text:0040EE36 ; ---------------------------------------------------------------------------
.text:0040EE36
.text:0040EE36 loc_40EE36:                             ; CODE XREF: strtok+77j
.text:0040EE36                 test    al, al
.text:0040EE38                 jz      short loc_40EE54
.text:0040EE3A                 inc     edx
.text:0040EE3B
.text:0040EE3B loc_40EE3B:                             ; CODE XREF: strtok+51j
.text:0040EE3B                                         ; strtok+59j
.text:0040EE3B                 mov     al, [edx]
.text:0040EE3D                 movzx   esi, al
.text:0040EE40                 xor     ebx, ebx
.text:0040EE42                 mov     ecx, esi
.text:0040EE44                 and     ecx, edi
.text:0040EE46                 inc     ebx
.text:0040EE47                 shl     ebx, cl
.text:0040EE49                 shr     esi, 3
.text:0040EE4C                 mov     cl, byte ptr [ebp+esi+var_24]
.text:0040EE50                 test    bl, cl
.text:0040EE52                 jnz     short loc_40EE36
.text:0040EE54
.text:0040EE54 loc_40EE54:                             ; CODE XREF: strtok+5Dj
.text:0040EE54                 mov     ebx, edx
.text:0040EE56                 jmp     short loc_40EE70
.text:0040EE58 ; ---------------------------------------------------------------------------
.text:0040EE58
.text:0040EE58 loc_40EE58:                             ; CODE XREF: strtok+98j
.text:0040EE58                 movzx   esi, byte ptr [edx]
.text:0040EE5B                 xor     eax, eax
.text:0040EE5D                 mov     ecx, esi
.text:0040EE5F                 and     ecx, edi
.text:0040EE61                 inc     eax
.text:0040EE62                 shl     eax, cl
.text:0040EE64                 shr     esi, 3
.text:0040EE67                 mov     cl, byte ptr [ebp+esi+var_24]
.text:0040EE6B                 test    al, cl
.text:0040EE6D                 jnz     short loc_40EE77
.text:0040EE6F                 inc     edx
.text:0040EE70
.text:0040EE70 loc_40EE70:                             ; CODE XREF: strtok+7Bj
.text:0040EE70                 cmp     byte ptr [edx], 0
.text:0040EE73                 jnz     short loc_40EE58
.text:0040EE75                 jmp     short loc_40EE7B
.text:0040EE77 ; ---------------------------------------------------------------------------
.text:0040EE77
.text:0040EE77 loc_40EE77:                             ; CODE XREF: strtok+92j
.text:0040EE77                 mov     byte ptr [edx], 0
.text:0040EE7A                 inc     edx
.text:0040EE7B
.text:0040EE7B loc_40EE7B:                             ; CODE XREF: strtok+9Aj
.text:0040EE7B                 mov     eax, [ebp+var_28]
.text:0040EE7E                 mov     ecx, [ebp+var_4]
.text:0040EE81                 mov     [eax+18h], edx
.text:0040EE84                 mov     eax, ebx
.text:0040EE86                 sub     eax, edx
.text:0040EE88                 neg     eax
.text:0040EE8A                 sbb     eax, eax
.text:0040EE8C                 pop     edi
.text:0040EE8D                 and     eax, ebx
.text:0040EE8F                 pop     esi
.text:0040EE90                 xor     ecx, ebp
.text:0040EE92                 pop     ebx
.text:0040EE93                 call    sub_4116F5
.text:0040EE98                 leave
.text:0040EE99                 retn
.text:0040EE99 strtok          endp
Vas's UCI parser does call this routine, but it is clearly not strtok() because it only passes two parameters:
[/code]
; ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ S U B R O U T I N E ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ


sub_40EAE0 proc near ; CODE XREF: sub_4092E0+10p
; sub_4092E0+1Dp ...

arg_0 = dword ptr 4
arg_4 = dword ptr 8

mov ecx, [esp+arg_4]
push edi
push ebx
push esi
mov dl, [ecx]
mov edi, [esp+0Ch+arg_0]
test dl, dl
jz short loc_40EB60
mov dh, [ecx+1]
test dh, dh
jz short loc_40EB4D

loc_40EAF8: ; CODE XREF: sub_40EAE0+58j
; sub_40EAE0+6Bj
mov esi, edi
mov ecx, [esp+0Ch+arg_4]
mov al, [edi]
add esi, 1
cmp al, dl
jz short loc_40EB1E
test al, al
jz short loc_40EB18

loc_40EB0B: ; CODE XREF: sub_40EAE0+36j
mov al, [esi]
add esi, 1

loc_40EB10: ; CODE XREF: sub_40EAE0+45j
cmp al, dl
jz short loc_40EB1E
test al, al
jnz short loc_40EB0B

loc_40EB18: ; CODE XREF: sub_40EAE0+29j
pop esi
pop ebx
pop edi
xor eax, eax
retn
; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

loc_40EB1E: ; CODE XREF: sub_40EAE0+25j
; sub_40EAE0+32j
mov al, [esi]
add esi, 1
cmp al, dh
jnz short loc_40EB10
lea edi, [esi-1]

loc_40EB2A: ; CODE XREF: sub_40EAE0+69j
mov ah, [ecx+2]
test ah, ah
jz short loc_40EB59
mov al, [esi]
add esi, 2
cmp al, ah
jnz short loc_40EAF8
mov al, [ecx+3]
test al, al
jz short loc_40EB59
mov ah, [esi-1]
add ecx, 2
cmp al, ah
jz short loc_40EB2A
jmp short loc_40EAF8
; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

loc_40EB4D: ; CODE XREF: sub_40EAE0+16j
xor eax, eax
pop esi
pop ebx
pop edi
mov al, dl
jmp loc_40EB86
; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

loc_40EB59: ; CODE XREF: sub_40EAE0+4Fj
; sub_40EAE0+5Fj
lea eax, [edi-1]
pop esi
pop ebx
pop edi
retn
; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

loc_40EB60: ; CODE XREF: sub_40EAE0+Fj
mov eax, edi
pop esi
pop ebx
pop edi
retn
sub_40EAE0 endp

; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
align 10h
; START OF FUNCTION CHUNK FOR sub_40EB80

loc_40EB70: ; CODE XREF: sub_40EB80+1Fj
lea eax, [edx-1]
pop ebx
retn
; END OF FUNCTION CHUNK FOR sub_40EB80
; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
align 10h
[/code]

Where is the code that you claim to be strtok() or the entry point?
If the strtok() routine were in the CRT runtime DLL, we would see the reference or the program would not work.
If the strtok() routine were included from the CRT library, we would see the code inline with the _strtok symbol name. There could be a clone of strtok() somewhere. Will you show me where it is?
That segment of code that Zach provided looks like strtok() built from the MS CRT source. When you install Visual Studio, you have the option to install the CRT source.

You will notice these easily:
1. The variables 4 match (3 DWORDS and a 32-byte array).
2. There is the call to _getptd().
3. Then there is the zeroing of the 32-byte array variable (8 stosd)
4. The very tight while loop that involves shift 3 to right, and 1 being shifted to the left in variable steps.

I could match the entire function, but I believe the point has been made.

The CRT library is liked statically to the EXE and then stripped of symbols.

Btw, ages ago, we used to have a disassembler that can identify common CRT functions even without symbols. It is specially easy with string functions.

Code: Select all

// I stripped out all the comments, and the 'secure' version

char * __cdecl strtok (
        char * string,
        const char * control
        )
{
        unsigned char *str;
        const unsigned char *ctrl = control;

        unsigned char map[32];
        int count;

        _ptiddata ptd = _getptd();

.text:0040EDFC                 push    8
.text:0040EDFE                 pop     ecx
.text:0040EDFF                 mov     [ebp+var_28], eax
.text:0040EE02                 xor     eax, eax
.text:0040EE04                 lea     edi, [ebp+var_24]
.text:0040EE07                 push    7
.text:0040EE09                 rep stosd
.text:0040EE0B                 pop     edi 

        for &#40;count = 0; count < 32; count++)
                map&#91;count&#93; = 0;

text&#58;0040EE0C                 mov     dl, &#91;esi&#93;
.text&#58;0040EE0E                 movzx   ecx, dl
.text&#58;0040EE11                 mov     eax, ecx
.text&#58;0040EE13                 and     ecx, edi
.text&#58;0040EE15                 mov     bl, 1
.text&#58;0040EE17                 shl     bl, cl
.text&#58;0040EE19                 shr     eax, 3
.text&#58;0040EE1C                 lea     eax, &#91;ebp+eax+var_24&#93;
.text&#58;0040EE20                 or      &#91;eax&#93;, bl
.text&#58;0040EE22                 inc     esi
.text&#58;0040EE23                 test    dl, dl
.text&#58;0040EE25                 jnz     short loc_40EE0C

         do &#123;
                map&#91;*ctrl >> 3&#93; |= &#40;1 << (*ctrl & 7&#41;);
        &#125; while (*ctrl++);

        if &#40;string&#41;
                str = string;
        else
                str = _TOKEN;

        while ( &#40;map&#91;*str >> 3&#93; & &#40;1 << (*str & 7&#41;)) && *str )
                str++;

        string = str;

        for ( ; *str ; str++ )
                if ( map&#91;*str >> 3&#93; & &#40;1 << (*str & 7&#41;) ) &#123;
                        *str++ = '\0';
                        break;
                &#125;

        _TOKEN = str;

        if ( string == str )
                return NULL;
        else
                return string;
&#125;
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Speaking of false evidence...

Post by bob »

Graham Banks wrote:Should be interesting to see how the accusers respond to this! :wink:
Sad to say, but the "accusers" here seem to agree that the only false evidence provided was provided in this thread. Which is unfortunate. And then the inflammatory subject line looks _really_ bad in light of that, since it is simply dead wrong.

go figure...

Dann is usually dead on in his comments. But here was the rare exception when he was dead wrong, unfortunately. And not just once, but in several statements he made (can't be strtok() as they only provided two arguments, strtok() is not included, it is not called, etc.) I don't know what his background with assembly on X86 is, but it is not enough apparently. I personally use this stuff every semester since I teach the course where it is covered. That's why I avoid many of Gerd's impossible posts, because I have not tried to get my head around his Kogge-Stone stuff enough to understand and comment about it. Others would do well to follow that same model here, and contribute if qualified, watch and learn if not.