Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Rook eval Rybka vs Fruit
1 2 3 Previous Next  
- - By Rebel (****) Date 2013-09-16 20:23
Hyatt - Fruit's half-open/open file eval does EXACTLY what Rybka does. I posted the code.   Can't read?  Can't comprehend?  Over your head?

The Zach code is false.

It has been pointed out to you several times.

Ready for assembler class ?

From the assembler......

RYBKA original ASM code

  401b50: 48 85 05 39 ca 26 00 test QWORD PTR [rip+0x26ca39],rax
  401b57: 75 3d                jne  0x401b96
  401b59: 83 c6 40             add  esi,0x40  // 64
  401b5c: 81 c7 00 01 00 00    add  edi,0x100 // 256
  401b62: 4c 85 f8             test rax,r15
  401b65: 75 0c                jne  0x401b73
  401b67: 81 c6 cb 03 00 00    add  esi,0x3cb // 971 (1035-64)
  401b6d: 81 c7 ac 00 00 00    add  edi,0xac  // 172 (428-256)


Hex-Rays C-equivalent

//    Start ROOK eval (Rybka)
//    =======================
   
if ( !(v84 & HIDWORD(qword_667BA0[0]) | v83 & qword_667BA0[0]) )  // open / semi open rook files
        {                                                         // when semi-open add:
          v271 += 256;                // 256 to endgame score 
          v6 += 64;                   // 64 to opening score
          if ( !(v84 & HIDWORD(qword_667BA8[0]) | v83 & qword_667BA8[0]) )
           {                                                      // when open file add:
            v6 += 971;                // 971 to opening score                 
            v271 += 172;              // 172 to endgame score     

             }

The values 1035 and 428 are nowhere in Rybka. It's a deliberate cheat by Zach to make Rybka look more Fruitish assuming constant folding because Zach liked it better that way.

http://www.top-5000.nl/Rook_Eval_Rybka.jpg

The left-right code is a lie.

You, a self proclaimed ASM expert, teaching your pupils in classroom still support the Zach lie.

What makes you that?
Parent - - By Ugh (*****) [fr] Date 2013-09-16 21:28
They don't mention:

the tests are byte-wise in one and 64bit-wise in the other. This is not "same" code.
the Rybka code is colour polar and presumably appears twice, the Fruit code has no polarity.
Rybka needs a fancy table, Fruit doesn't. Nowhere is this mentioned. Nor the relatively large code chunk to create the table without which Rybka's code won't work.
Rybka code is unique, it matches with no other program.
Fruit code matches Crafty code exactly. TSCP also, for example.
the work involved in taking just these few lines of Fruit code and converting it line by line is so massive (big knock on effects elsewhere) compared to simply writing it from scratch in a few minutes, that only a lunatic would even try it, and, if that was what our lunatic did, we might expect a result in perhaps 2020.

Bob is completely bonkers to even imagine this code was copied.
Parent - - By bob (Gold) [us] Date 2013-09-16 22:59
Sorry, the fruit code DOES have "color polarity".  What are you talking about?

if (board->pawn_file[me][rook_file] == 0) { // no friendly pawn
                  op[me] += RookSemiOpenFileOpening;
                  eg[me] += RookSemiOpenFileEndgame;

                  if (board->pawn_file[opp][rook_file] == 0) { // no enemy pawn
                     op[me] += RookOpenFileOpening - RookSemiOpenFileOpening;
                     eg[me] += RookOpenFileEndgame - RookSemiOpenFileEndgame;
                  }
}

Do yu not see that "pawn_file[me]" test?  check for friendly pawns.  See that "pawn_file[opp]"?  Check for enemy pawns.  Can you not read code???
Parent - - By Ugh (*****) [fr] Date 2013-09-16 23:23
stop being silly. I meant directional colour polarity brought about by the forwards aspect. Forwards from a square gives different squares depending on color of the piece. Fruit Crafty don't have this directionality requirement, Rybka does because if its unique difference. looks to me that Rybka has separate white and black code because of this, but I am just going by clues in the Zach document. Fruit crafty only need one code block since they don't have the feature.

Can I not read code? Why the insulting question? Do they come as standard when discussing with you?
Parent - By bob (Gold) [us] Date 2013-09-17 05:42
Crafty certainly has this directionality in some versions.  I like the direct attack calculation even better, however.

What you WROTE was that fruit/crafty didn't have to handle colors.  They both do.  If you want to modify your statement, that's fine.  But don't act like it was modified all the time...

Rybka does exactly what I do in similar cases...

ie mask_passed[wtm][square]

which makes it work for either side with no conditional tests or anything else...
Parent - - By Rebel (****) Date 2013-09-17 00:27
Excellent points!

the Rybka code is colour polar and presumably appears twice, the Fruit code has no polarity.

Not sure, if you mean that Rybka split the code in a white and black part while Fruit did not, then sure this is a valid point as well.
Parent - - By bob (Gold) [us] Date 2013-09-17 05:52
:)

There is NO "white/black" part of the code.  This is done in a mask.  To avoid the "duplicated" code, one simply uses

pawn_mask[enemy][square] rather than pawn_mask[square].  Trivially simple to anyone that has DONE bitboards...
Parent - By Rebel (****) Date 2013-09-17 07:26
Hyatt - There is NO "white/black" part of the code.

ASM classroom part II

From Watkins annotated disassembler...

White Rooks code

0x401b50: test   %rax,0x26ca39(%rip) # 0x66e590  white pawns
0x401b57: jne    0x401b96
0x401b59: add    $0x40,%esi                      if on half-open file
0x401b5c: add    $0x100,%edi                      add 64 in op, 256 in end
0x401b62: test   %r15,%rax                        if on full-open file (bP)
0x401b65: jne    0x401b73
0x401b67: add    $0x3cb,%esi                      add 971 in op, 172 in end
0x401b6d: add    $0xac,%edi


Black Rooks code

0x402128: mov    0x26c469(%rip),%rcx # 0x66e598
0x40212f: add    %eax,%esi
0x402131: mov    0x24a540(%r8,%r9,8),%rax
0x402139: test   %rax,%rcx
0x40213c: jne    0x402172
0x40213e: sub    $0x40,%esi
0x402141: sub    $0x100,%edi
0x402147: test   %rax,%rbx
0x40214a: jne    0x402158
0x40214c: sub    $0x3cb,%esi
0x402152: sub    $0xac,%edi


Where in Fruit ?
Parent - - By Ugh (*****) [fr] Date 2013-09-17 09:33
Posted yesterday by you:

2. Next Rybka:

file_bb = mask_open_file_w[square];
if ((Board.pieces[WP] & file_bb) == 0) {
  opening += RookSemiOpenFileOpening;
  endgame += RookSemiOpenFileEndgame;
  if ((Board.pieces[BP] & file_bb) == 0) {
    opening += RookOpenFileOpening - RookSemiOpenFileOpening;
    endgame += RookOpenFileEndgame - RookSemiOpenFileEndgame;
  }
}


Note the directional colour polarity "w".

Explain your comment in relation to the above Rybka code: "There is NO "white/black" part of the code."

Explain your comment in relation to the above Rybka code: To avoid the "duplicated" code, one simply uses pawn_mask[enemy][square] rather than pawn_mask[square]

When you've "done" or rather failed to do that, perhaps you would like to explain away the other six or so differences I listed in the seven lines of code that you claim match EXACTLY? And explain why you are filling this thread up with argumentative bullshit that is demonstrably false? Smokescreen?

Rybka is not a copy of Fruit, Bob. And no attempt by you to arrange disassembled Rybka code in an attractive graphical representation in a pretty box alongside Fruit code in a pretty box has shown to stand up to close inspection. The graphical representation looks pretty, the Rybka code is artistically and beautifully Fruitified. The pretty boxes are mostly the same size. But the code inside was not copied.
Parent - By bob (Gold) [us] Date 2013-09-17 16:56
Simple.  In THAT code it works just one way.  Notice the NEST line...  Board.pieces[WP].  Does THAT work for black?

I tend to write code a bit cleaner than that.

I would use something like this to avoid duplicating ANYTHING at no loss in speed...

file_bb = mask_open_file[my_color][square]
if ((Board.pieces[my_color] & file_bb) == 0) {
  ...
  if ((Board.pieces[opponent] & file_bb) == 0) {
    ..
    ..
  }
}

Works for either side.  my_color = white; opponent = my_color ^ 1;
if my_color = black, that makes opponent = white...

If I mis-remembered rybka code, fine.  I know how it SHOULD be written.  I assumed after all the "Vas is great" posts that he did things reasonably efficiently.  Point STILL stands.  At one point, SPECIFICALLY in the 19.x versions (the version Vas so blatantly copied) I had code that looked exactly like his approach.  Code to evaluate white rooks.  Code to evaluate black rooks.  I learned and did it better.  I can certainly "guess" where his "approach" came from.  :)

But back to the point.  That code is a dead-ringer for Fruit.  Mine is not.  I add one constant or the other.  Never both, never add one then remove it and add the other.  Fruit and Rybka match at the code level precisely there.  That is one "oddity".  Out of a BUNCH of oddities...

I know you want to hand-wave all of this away.  Just like you want to hand-wave the table probing.  The go_parse().  EVERYTHING.  Too much to "hand-wave" away, unfortunately.

If you have something new or useful, bring it up.  I am not going to keep repeating my interpretation of this over and over against arguments that are ridiculous...

And this circular argument doesn't work.  He couldn't copy fruit, because R 1.0 beta was much stronger than fruit.  Even though Fruit 2.3 was much stronger than Fruit 2.1 also is beside the point, apparently.  I certainly copied my own code in 1994.  It is certainly stronger today than it was back then.  By this logic it was never copied...  and that is simply wrong...
Parent - - By Rebel (****) Date 2013-09-17 22:09
the Rybka code is colour polar and presumably appears twice, the Fruit code has no polarity.

It's good that you mention this. It's another fundamental sign of Rybka originality.

Fruit -  evaluation for the white & black pieces in one block of code.
Rybka -  evaluation for the white & black pieces in 2 separate blocks of code.


For a cloner it makes no sense to split the code, the gain is zero.
Parent - By Alkelele (****) Date 2013-09-17 22:10
He did it for obfuscation, obviously...
Parent - - By Richard Vida (**) Date 2013-09-17 22:28

> the gain is zero


the gain is SPEED
Parent - - By Rebel (****) Date 2013-09-17 22:37
the gain is SPEED

You save just one "if", on the other hand you pollute the (code) cache.

Splitting code made sense in the old days when there was no cache.
Parent - - By Richard Vida (**) Date 2013-09-17 23:13

> the gain is SPEED
>
> You save just one "if", on the other hand you pollute the (code) cache.
>
> Splitting code made sense in the old days when there was no cache.


I suppose my reply was too brief. I meant that he HAD TO unroll the loop anyway - rybka has bitboards instead of piece lists.

Let's look at fruits evaluate_piece(). It has an outer loop for iterating colour, an inner loop for stepping through the piece list of the colour. Inside the inner loop there is a huge switch statement. It kills performance, but for a mailbox program there is little choice anyway. (Maybe a separate piece list for each type of piece?)

With bitboards you would want to iterate each bitboard individually - avoiding one loop and the performance killer switch statement. This also has the potential benefit of getting rid of some branches where different stuff for white/black is needed. Most bitboard programs do it this way:


for (b = w_rooks; b; clear_lsb(b)) {
  /* rook stuff */
}
for (b = b_rooks; b; clear_lsb(b)) {
  /* rook stuff */
}
for (b = w_bishops; b; clear_lsb(b)) {
  /* bishop stuff */
}
for (b = b_bishops; b; clear_lsb(b)) {
  /* bishop stuff */
}
...etc


sure, it is possible to somewhat mimic the fruity way (albeit not exactly), but that would be slower and much uglier:

for (colour = WHITE; colour <= BLACK; colour++) {
  pieces = (colour == WHITE) ? w_occupied ^ w_pawns ^ w_king : b_occupied ^ b_pawns ^ b_king;
  for ( ; pieces; clear_lsb(pieces)) {
    sq = find_lsb(pieces);
    switch (type_of(squares[sq])) {
      case ROOK: /* rook stuff */
      case BISHOP: /* bishop stuff */
      ...etc
    }
  }
}
Parent - - By Richard Vida (**) Date 2013-09-17 23:21
Even if the first example above is written like

for (colour = WHITE; colour <= BLACK; colour++) {
  for (b = rooks[colour]; b; clear_lsb(b) {
    /* rook stuff */
  }
}

chances are that the compiler will unroll this automatically. It knows at compile time that the outer loop will always execute exactly 2x.
Parent - - By Rebel (****) Date 2013-09-18 06:53
Agreed, it's low performance code.

I guess Fabien either was not interested in code optimizations yet (priority) or lacked the knowledge or maybe a cocktail.
Parent - - By bob (Gold) [us] Date 2013-09-18 13:45
That's not "low performance code".  It is simply something a compiler does to eliminate the loop-control stuff, a jump at the bottom, a loop counter, etc.  It allows US to write concise, compact code, and have it unrolled for max efficiency.  Miserable to duplicate that code twice manually.  Now every time it is changed you have to change it in two places.

I'd suspect Fabien KNEW how compilers optimize, and wrote it in a way that was easy to maintain, knowing the compiler would handle the efficiency issues...
Parent - - By Rebel (****) Date 2013-09-18 22:34
Let's take a real Fruit example. From EVAL.CPP LINE 577-580

for (colour = 0; colour < ColourNb; colour++) {
      op[colour] = 0;
      eg[colour] = 0; }


Since ColourNb has a value of 2 you are saying a smart compiler would translate this to:

op[0]=0; op[1]=0; eg[0]; eg[1]=0;

Which is how I would write my code instead of an expensive for/next loop.

So, show it to me in the fruit 2.1 binary, the offset is sufficient.

More important to the VII / VIG discussion, none of that op/eg (typical Fruit) stuff is in Rybka's eval. You do realize that, don't you?
Parent - - By Richard Vida (**) Date 2013-09-18 23:03

> More important to the VII / VIG discussion, none of that op/eg (typical Fruit) stuff is in Rybka's eval. You do realize that, don't you?


Huh? Are you serious here?
Parent - - By Rebel (****) Date 2013-09-19 00:19
Since you have a passion for RE (I don't) you know yourself how easy it is to unmask a clone. The pre-Rybka's, 2 hours, Houdini 1 hour, Loop=Fruit 2.2.1 was somewhat harder. All of them leave many indisputable DNA traces of clear copying. With Rybka 1.0 that's not the case. There are some grey areas as I pointed out in my document but as a whole Rybka 1.0 is more original than the Critters written in C. Having said that, surely both of you have written your own code.

Surely you would agree with me that Fruit clones (such as Loop) can be recognized by typical unique Fabien code. If you find the odd (hence unique) Fruit QUAD function in another program you know you likely deal with a Fruit clone, same for all the op/eg stuff in the Fruit eval, it's the signature of Fabien, same for the 2 stage evaluation, Fabien's unique signature, none on the planet has it. It's the DNA of Fabien.

All of the above DNA is in Loop and none in Rybka 1.0
Parent - - By bob (Gold) [us] Date 2013-09-19 02:28
Didn't Ryan do a bitboard version of Toga?  Have you looked at it?  Might be REAL interesting to do so?  I'll see if I can locate anything...
Parent - - By user923005 (****) [us] Date 2013-09-19 03:53
Raimund Heid called Protector a "Bitboard-based Toga II with many small improvements" which can be found here:
http://sourceforge.net/projects/protector/

Ryan made a port of fruit called "Gambit Fruit" which you can find here:
http://www.superchessengine.com/gambit_fruit.htm
Direct link:
http://www.superchessengine.com/GFruit_4bx.zip

Both come with source code.
Parent - - By user923005 (****) [us] Date 2013-09-19 04:03
Bison also is "fruit inspired" and you might like to examine that engine as well.
http://sourceforge.net/projects/bison/?source=directory
Parent - - By Rebel (****) Date 2013-09-19 06:55
A few days ago Tord (on Talkchess) replied to an interesting question, "How much of Stockfish code is still from Tord Romstad?"

Tord saw enough Glaurung DNA.

Don made the same observation regarding Doch -> Komodo.
Parent - - By bob (Gold) [us] Date 2013-09-19 16:15
We saw the same for fruit/rybka, of course.

But I do plan on looking at a bit board fruit to see how it compares to the rybka executable...
Parent - - By Rebel (****) Date 2013-09-19 19:15
No you don't.

Point is that a cloner can't erase all typical DNA of an engine so easily.

Houdart is a bright engineer but he couldn't hide the origin of Houdini, and I bet he tried.

How do we recognize a Crafty clone? --> 999999 as first try. Bingo most of the time as history has proven.

With Rybka 1.0 beta things are completely different, no clear DNA, hence we argue till we drop death :wink:

I suggest a classic duel at morning dew, choose your favorite weapon and don't cheat during the countdown :wink:
Parent - By user923005 (****) [us] Date 2013-09-19 19:48
With several winboard chess engines (early in development), I have noticed that typing 'bye' at the winboard prompt will get you "Share and enjoy!", signaling that they started life as TSCP.
Usually, when you put the evidence forward, the person who has used TSCP will put the notice of credit to Tom into their readme file after you call them out onto the carpet.
I suspect that many people are simply ignorant of intellectual property rights and suppose that using someone else's program is no big deal.
Parent - - By bob (Gold) [us] Date 2013-09-19 20:29
"No I don't" what?  I am going to look at a bitboard version of Fruit.  If it looks a lot like Rybka, that will be beyond interesting, eh?

As far as the duel goes, I choose my Smith 629 44 magnum.  Iron sights.  100 yards.  :)

You'd better be GOOD.
Parent - - By user923005 (****) [us] Date 2013-09-19 20:34
It would be especially telling if (for instance) there were extreme resemblances between Ryan's fruit translation Gambit Fruit (from the end of 2005, about the same time as Rybka's emergence).
The other fruitlike engines all came much later.
Parent - - By bob (Gold) [us] Date 2013-09-19 21:46
I had looked for it a bit late last night but could not find any source distribution.  I will look again later tonight.
Parent - - By user923005 (****) [us] Date 2013-09-20 00:20
For gambit fruit, there is a source code zip inside of the distribution zip.
Protector was not available to the public until 2009:
http://www.computerchess.info/tdbb/phpBB3/viewtopic.php?f=9&t=394
Parent - By bob (Gold) [us] Date 2013-09-20 02:43
The version I found is not bitboard at all...

the file was GFruit4bx.zip and it is a normal mailbox fruit.  Any others?
Parent - - By bob (Gold) [us] Date 2013-09-19 23:28
I have started to look.  I am starting in "evaluatec.c (not a typo, extra c is there).

First thing of note.  Protector has black/white duplication just like rybka, even though fruit did not.  As I said, this is a natural and easy starting point.  Most would think "OK, bitboards are hard enough, I'm going to translate to bit boards using the simplest approach possible, and maybe remove the duplicate code after all the code actually works."  First point, then, is Ed's claim of "rybka having black and white code duplication indicates it is unique" is completely wrong.  Since protector comes directly from fruit, it shows that this is the most reasonable way to start the conversion.  This does NOT help Vas' case at all.

Second thing of note.  Remember the open/half-open file code.  Fruit considers all squares on a file when checking for friendly or enemy pawns.  Rybka just considers all squares in front of the rook, ignoring those behind it.

Both do this:

if (no friendly pawns) {
  score += half-open-file-bonus
  if (no enemy pawns)
    score -= half-open-file-bonus + open_file_bonus
}

First, protector is a little cleverer.  I'll try to write readable pseudocode...

if (no friendly pawns anywhere on file) {
  if (opponent has no pawns, bishops or knights on this file, somewhere in FRONT of this rook, supported by a pawn) {
    if (opponent has no pawns in front of rook)
      score += 20;
    else
      score += 10;
  }
  else if (opponent has no protected pawns in front of rook)
      score += 8;
}

So APPARENTLY, someone intentionally copies fruit, converts it to bitboards, and decides to make a significant modification to the code.  What I would actually expect, as opposed to copying exactly except for one mask change as was in Rybka.

When I have more time I will take another eval term or two and compare to fruit/rybka.
Parent - - By user923005 (****) [us] Date 2013-09-20 00:22
Protector does not come directly from fruit, though it is heavily fruit inspired.  This is from the readme file:

"Protector is based on many great ideas from the following people: Fabien Letouzey (pvnodes, blending of opening and endgame values, eval params), Thomas Gaksch (pvnode extensions, extended futility pruning, space attack eval), Robert Hyatt (consistent hashtable entries), Stefan Meyer-Kahlen (UCI), Gerd Isenberg [4] /Lasse Hansen (magic bitboards), Marco Costalba/Tord Romstad/Joona Kiiski (Glaurung/Stockfish sources), Igor/Yakov (Robbolito sources), Andrew Kadatch/Eugene Nalimov (endgame tablebases), Frank Rahde (testing) and Wolf Stephan Kappesser (Adaptations for Mac OS). Without their contributions Protector would not be what it is. Thank you so much."
Parent - - By Lukas Cimiotti (Bronze) [de] Date 2013-09-20 06:36
So maybe Hyatt's example has been taken from Robbolito - a Rybka clone? Maybe someone might check Robbolito for it?
Parent - - By user923005 (****) [us] Date 2013-09-20 10:28
The public Protector came after:
Fruit by Fabien Letouzey
Toga by Thomas Gaksch
Crafty by Robert Hyatt
Glaurung by Tord Romstad
Stockfish  by Marco Costalba/Tord Romstad/Joona Kiiski
Robbolito by Igor/Yakov (Robbolito sources)
and his end notes say clearly that he studied all of these.

The white/black separation is clearly present in Robbolito.  Robbolito is quite possibly a reverse engineered Rybka.
I did not check that code specifically yet.
I am not sure what similarities between Fruit, Rybka and Protector would mean anyway.  I do not really understand the goal of Dr. Hyatt in this experiment.
Parent - - By Lukas Cimiotti (Bronze) [de] Date 2013-09-21 00:20

>I do not really understand the goal of Dr. Hyatt in this experiment.


Maybe Alan's theory about him is right: http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=386896#pid386896
Parent - By bob (Gold) [us] Date 2013-09-21 16:49
Or maybe his theory is just rambling nonsense posted by someone that is not competent to discuss computer chess programming whatsoever...
Parent - By bob (Gold) [us] Date 2013-09-21 16:48
My interest was as follows:

(1) Ed claims the black/white separation shows originality in Rybka, since Fruit did not have it.

(2) I claimed it was a natural way of writing bitboard code for the first time.  Crafty was like that for almost 15 years before I rewrote it to simplify the code.  The rewrite took MONTHS and gained zero other than cleaner code.

(3) finding a known fruit-to-bitboard program would give additional insight into how someone ELSE did exactly what we believe Vas did.  If we had real fruit-derived bitboard source, we could see whether it track's Rybka closely or not.  If it is close, it would refute this "original" claim by Ed.  But so far, I have not found a fruit derivative other than perhaps Sloppy.  But sloppy was done differently, removing the C++ stuff as well.  There are plenty of similarities, but it would be cleaner if we had a real C++ implementation to see how the classes, methods and objects compare, directly...

That was my intent, nothing to do with the rybka case per se, just something to satisfy my personal curiosity..
Parent - - By Rebel (****) Date 2013-09-19 22:19
"No I don't" what?  I am going to look at a bitboard version of Fruit.  If it looks a lot like Rybka, that will be beyond interesting, eh?

Reminds of a challenge I put on Watkins. Take the Fruit source code and change all evaluation values to Rybka values, then measure the percentage difference with similarity tester. Watkins took the challenge and reported only a 4% increase.

Devastating.........
Parent - - By bob (Gold) [us] Date 2013-09-19 23:38
Why is that "devastating"?  If you scale all the eval terms similarly, I would be surprised if it improved 1%, much less 4%.
Parent - - By Rebel (****) Date 2013-09-20 07:07 Edited 2013-09-20 09:19
Guess you misunderstood what's been done, so in more detail...

From Zach's document - Simply put, Rybka's evaluation is virtually identical to Fruit's.

So if we give Fruit (or R10b for that matter) all the same evaluation values then (using Zach's words) Fruit and Rybka are virtually identical. Naturally Watkins liked the idea, enough for him to put considerable time in the idea, for me the outcome would be a decisive moment. If suddenly similarity tester would report sky-high numbers then certainly that would have been the end of my criticism.

And the Rybka-Fruit similarity went up from 54% to 58%.

Now 58% similarity is a very poor number for 2 identical evaluations.

If we take the 58% and compare it with Adam's clone study it doesn't even make it to the top-30 of the suspect engines list.

1. Fruit 2.2.1        vs  Loop 2007          84.73% (similarity)
2. Fruit 2.2.1        vs  Loop 10.32f        84.13%
3. Strelka 1.8        vs  Rybka 1.0 Beta     73.11%
4. Fruit 2.1          vs  TogaII 1.0         72.43%
5. Fruit 2.1          vs  Loop 2007          70.81%
6. RobboLito 0.085d1  vs  Houdini 1.00       70.37%
................
29. Glaurung 1.2.1    vs  Alfil 8.1.1        59.47%
30. Rybka 3           vs  Houdini 1.00       59.37%

So how can Zach's statement - Simply put, Rybka's evaluation is virtually identical to Fruit's possibly be true?
Parent - - By user923005 (****) [us] Date 2013-09-20 10:31
The version we should be comparing is Rybka 2.3.2a (or the contest version "Rajilch.exe?" would be even better).
Rybka 1.0 never played in any ICGA contest.
Parent - - By Rebel (****) Date 2013-09-20 12:03
Indeed.

I haven't looked at the available Watkins analysis of version 2.3.2 that is generally assumed to have played. The document is here. After a quick look at the code it seems that Rajlich has dropped the interpolation evaluation (mg/eg) although Watkins seems to suggest it is still present. However I could be missing the obvious.

A snippet from the (in the between time) well known rook evaluation, see page 7.

Left column Rybka 1.0                             Right column Rybka 2.3.2
0x401b59: add   $0x40,%esi   # add 64 op          add $0x68010c,%ebx   # (104,268)
0x401b5c: add   $0x100,%edi  # and 256 eg   
0x401b62: test  %r15,%rax    # full open test
0x401b65: jne   0x401b73     # if so
0x401b67: add   $0x3cb,%esi  # add 971 op         add $0x27300b4,%ebx # (627,180)
0x401b6d: add   $0xac,%edi   # and 172 eg


As one can see there are only 2 add's in 2.3.2 and not 4, no score update by constants but use of memory values. Not very fruitish.
Parent - - By Richard Vida (**) Date 2013-09-20 16:20

> As one can see there are only 2 add's in 2.3.2 and not 4


Packs two 16bit values into 32 bits. Upper 16bits for opening, lower 16bits for endgame. Logically it is same, just a tiny bit faster (1 additions vs 2).

> no score update by constants


$0x68010c looks constant enough for me
Parent - - By Rebel (****) Date 2013-09-20 16:28 Edited 2013-09-20 16:35
$0x68010c looks constant enough for me

:lol:

Yeah, need new glasses.

Nice trick BTW.
Parent - - By bob (Gold) [us] Date 2013-09-20 18:23
It's been discussed on CCC for a couple of years.  Several are doing it.  I didn't think it worth the time, since it just supplies a pair of adds to help keep the arithmetic pipes busier..
Parent - - By Rebel (****) Date 2013-09-21 16:04
But not Fruitish.
Parent - - By bob (Gold) [us] Date 2013-09-21 16:20
two scores is "fruitish".  Combining them into one value is simple evolution.
Up Topic Rybka Support & Discussion / Rybka Discussion / Rook eval Rybka vs Fruit
1 2 3 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill