Question for Bob Hyatt

[diep]

Your values are according to wiki

3¼ 3¼ 5 9¾ Kaufman 1999 Add ½ point for the bishop pair[7] (Kaufman 1999)

That's not even close to rybka by the way.

In rybka actually the material only table gives 2 rooks against queen +0.94 for the ROOKS and that goes up, so far away from the 0.25 pawn you 'advised'.

In short you had NOTHING to do with the parameter tuning which is NCSA domain, and you are far away from those guys. Thank you.

It gives a bonus of +0.9 to +1.2 for a bishop pair

A knight is 0.6 stronger than a bishop in case of not a bishop pair running back to +0.36 of a knight being stronger. So they are not 'equal strong' at all.

Even if you had done your database research well, you can see that also Kasparov played like that (regardless of what he said).

That are the default material values in Rybka.

Please note also the rybka values are not exact rounded values to a quarter of a pawn, they are broken values of course and they don't even claim to have done database research.

Where did you get these values for Rybka?

Actually I don't believe that bishop pair values of more than maybe +0.7 make sense.

Yes of course when Anthony Cozzie asked me: "What the hell to tune?", around end 2004 for his master thesis, as about every experiment tuning before that in computerchess had failed, i suggested that he should tune material, as i guessed back then that should be able to get tuned well.

A big problem of course was the huge amounts of system time needed for such an experiment, but i understood Bob would take care for that as he had quite some hardware.

Then it was basically quiet until world champs 2005.

During the world champs Zappa did do a lot better than we all had expected, and the question asked in that cafe by Shay Bushinsky with Anthony also present, i should have treated with a bit more suspicion of course.

Crafty that world champs also played with automatic PSQ values tuned by Anthony.

I was very amazed to see how Crafty in a game against Isichess parked its white knight on a1. Isichess back then was really weak; not very well comparable with the years after that it would get a big eloboost as it seems he cut'n pasted some material values that he found on the net somewhere and also the increased search depth caused by things like LMR are important to mention.

Bob i was told, was very upset about the square a1 having such a clumsy tuning, meanwhile Zappa getting world champion in a clear manner, of course without burying a white knight on a1.

Now Zappa of course like Diep is a slow program in nps relative to what is possible and if you are a programmer like Cozzie of course you're low level quite some better than the average coder in computerchess is.

So during the world champs we wondered about how strong Fruit would be if you would rewrite its code to faster code which as i expected would be exactly factor 2 times faster and also fix a few obvious bugs in evaluation, such as it total overestimating and losing games to too optimistic passed pawn scores and of course especially the material evaluation.

Now short before world champs 2005 as i said again my big nps monster i tried to combine with diep. That was maybe at that point not such a good idea. To quote SMK: "it is difficult to combine 2 different programs with each other". He's right there. Easier is just produce 1 beancounter good in blitz.

Of course somewhere i dropped the remark that Frans Morsch had told me that the big secret of his engines as well as genius was the huge nps they got and that up until late 90s no one realized even how many nps he got.

Anthony must've remembered that.

Anthony must have combined all that brilliantly as i of course have asked him the question: "how comes that Zappa's bitboard functions which no other programmer in CCC uses, as they got a faster alternative, are inside this product?"

Anthonies reaction was: "oh Vasik's brother works here as my collegue, maybe his brother stole my code".

Another question on a specific bitboard bitmask i saw the assembler from i couldn't understand.

Anthony within 20 seconds: "h2 pawn attacks a3, that's a bug, the bitmask is wrong in rybka". That was a bit *too quick*. I didn't even know it was a bitmask.

Anyway. That was the first version, what happened after that is yet another story from which we all only like to know: "Whom pays for it?"

Oh doh, Bishop pair huh.

I emailed a random Russian guy called Alex Trofimov just now he replied:

Oh well let's give it to you with 4 pawns onthe board.

number of White Queen(s) [0..2] : 0
number of Black Queen(s) [0..2] : 0
number of White Rook(s) [0..2] : 1
number of Black Rook(s) [0..2] : 1
number of White Bishop(s) [0..2] : 2
number of Black Bishop(s) [0..2] : 1
number of White Knight(s) [0..2] : 1
number of Black Knight(s) [0..2] : 2
number of White Pawn(s) [0..8] : 4
number of Black Pawn(s) [0..8] : 4
Value in table ==> material = 175 flags = 592

So that's +1.75


Now let's take the full board ok with minimum removed:
number of White Queen(s) [0..2] : 1
number of Black Queen(s) [0..2] : 1
number of White Rook(s) [0..2] : 2
number of Black Rook(s) [0..2] : 2
number of White Bishop(s) [0..2] : 2
number of Black Bishop(s) [0..2] : 1
number of White Knight(s) [0..2] : 1
number of Black Knight(s) [0..2] : 2
number of White Pawn(s) [0..8] : 8
number of Black Pawn(s) [0..8] : 8
Value in Rybka table ==> material = 101 flags = 86

+1.01

It works.

Thanks,
Vincent

[Uri Blass]

Of course the stated value of a piece is not very important, as you can always adjust the piece location table to compensate for any error in the nominal value. The only real importance of getting the nominal value of the piece about right is if you do things like "lazy eval" or make any use of the actual material balance to make decisions. So in Rybka I tried to get them about right, but the benefit was perhaps under one Elo point. In Doch we made a special effort to get them about right at least in terms of the piece location tables and mobility being about neutral on average, so that the table values and/or mobility values can be increased or decreased by any desired percentage without much consequence to the average value of the piece in question. I think we got the pawn wrong though; our next version will correct this (mostly).

I think that you can get better lazy evaluation then piece square table.

The idea is that the difference between lazy evaluation and full evaluation is in most cases in the same direction during the last nodes of the analysis(from white point of view) so if you know the difference between the lazy evaluation and the full evaluation in the last time that you did a full evaluation then you can use this number to correct the lazy evaluation.

I am not sure if adding the full difference is the best estimate but I think that at least adding part of the difference in the last case is going to give a better estimate.
Uri

[lkaufman]

If I understand this correctly, this is exactly equivalent to increasing the value of rooks and minor pieces by X (your bad trade coefficient) and the queen by 2X. This is the exact proposal I made in one of my posts to this forum! So I think you can say that your piece values are the nominal values plus X for the rooks and minors and plus 2x for the queen, just for purposes of comparing to other programs, though as you say such values have little meaning. What are your current values for X, for the pieces, and for the bishop pair, and in the case of the bishop pair, does the value depend on other things, and if so what?

Thanks.

Larry

[lkaufman]

What version of Rybka is this bishop pair stuff taken from? It's certainly nothing like Rybka 3, where the value ranges roughly from a quarter of a pawn in the opening to half a pawn in the endgame.

[Don]

Oh doh, Bishop pair huh.

I emailed a random Russian guy called Alex Trofimov just now he replied:

Oh well let's give it to you with 4 pawns onthe board.

number of White Queen(s) [0..2] : 0
number of Black Queen(s) [0..2] : 0
number of White Rook(s) [0..2] : 1
number of Black Rook(s) [0..2] : 1
number of White Bishop(s) [0..2] : 2
number of Black Bishop(s) [0..2] : 1
number of White Knight(s) [0..2] : 1
number of Black Knight(s) [0..2] : 2
number of White Pawn(s) [0..8] : 4
number of Black Pawn(s) [0..8] : 4
Value in table ==> material = 175 flags = 592

So that's +1.75


Now let's take the full board ok with minimum removed:
number of White Queen(s) [0..2] : 1
number of Black Queen(s) [0..2] : 1
number of White Rook(s) [0..2] : 2
number of Black Rook(s) [0..2] : 2
number of White Bishop(s) [0..2] : 2
number of Black Bishop(s) [0..2] : 1
number of White Knight(s) [0..2] : 1
number of Black Knight(s) [0..2] : 2
number of White Pawn(s) [0..8] : 8
number of Black Pawn(s) [0..8] : 8
Value in Rybka table ==> material = 101 flags = 86

+1.01

It works.

Thanks,
Vincent

Where did that table come from? Is that a half megabyte table to calculate material score? And what are the flags?

[Gerd Isenberg]

I was very amazed to see how Crafty in a game against Isichess parked its white knight on a1. Isichess back then was really weak; not very well comparable with the years after that it would get a big eloboost as it seems he cut'n pasted some material values that he found on the net somewhere and also the increased search depth caused by things like LMR are important to mention.

Vincent, what are you talking about!? What eloboost? I did not copy/paste something from the net nor other programs.

Gerd

[jwes]

OK, so it is equivalent to having altered piece values. In that case, we should ignore the piece base values in Crafty, as they are just implementation details of no fundamental value, but in stead look at the effective values including the bad-trade bonuses / penalties, as they are used to decide if a certain trade is favorable or not.

It turns out that with the current imbalance values, there is no different piece values that would give the same result as the imbalance table. The correction for RvB is the same as the correction for RRvBB, and obviously unless the correction for RRvBB is exactly twice the correction for RvB, there is no different values for R and B that will give the same result.

[diep]

If I understand this correctly, this is exactly equivalent to increasing the value of rooks and minor pieces by X (your bad trade coefficient) and the queen by 2X. This is the exact proposal I made in one of my posts to this forum! So I think you can say that your piece values are the nominal values plus X for the rooks and minors and plus 2x for the queen, just for purposes of comparing to other programs, though as you say such values have little meaning. What are your current values for X, for the pieces, and for the bishop pair, and in the case of the bishop pair, does the value depend on other things, and if so what?

Thanks.

Larry

The procedure works as follow. I ship questions to Moscow, then first The Hague has to give clearance, secondly it goes to Tel Aviv for clearance, then most importantly Washington DC has their say, before anything about Rybka can be said. Those ex-soviets work very burocratic and Alex Trofimov has been born during soviet times.

Vincent

p.s. that you ask whether it is rybka3 is selfexplaining. Yes, there isn't much difference in material tuning between the different rybka's. You know it is even an irrelevant question whether it is "rybka3" having that tuning. If you can already produce something that kicks butt based upon tuning, some total other tuning based upon ideas from the 1930s won't work of course.

[diep]

Perhaps the question about tuning parameters for evaluation need to ask Vasik. I think he uses the best method of tuning the weights.

I'm a bit amazed by the +20 elo claim i saw from Herman from a neural network as a gain for his material values. I really like to know the original values to understand the small elowin better.

When in 2005 i bugfixed my old material values of diep quite a bit, so i did NOT change the code at all. I just put the material values from diep from

pawn=1000 , knight = 3625, bishop 3675

to the current basic values, realize there is all kind of other influences in diep's material code, but this is the basic values. I did not change that influence code back in 2005 after world champs 2005.

{ 1000, 3875, 3875, 6175, 12350 }, /* 0 */

pawn=1000, knight = 3875

This is also the CURRENT values. Note they were initially a bit more polite like 3.825. So i did very slightly change it but not a lot.

Those slight changes i hardly noticed in elorating either. However the jump from 3.6 to 3.8 of course first took some readjusting values of other parameters. Instantly it got up like 200 elopoints, not 20.

A magic change it was, really. Not +20 elo.

So i don't really understand that change of +20 elo that Hermann got.

Small sample snip that your collegue Alex Trofimov dug up. Maybe it is time you take a photo from him at work?

Lots of code look like the blow code. If you look at the code does it look like produced by a neural network or by mankind?

Code: Select all

static UINT64
materialize_valuations (int white_pawns_count, int white_knight_count, int [white_bishop_count, int white_bishop_count_1, int white_bishop_count_2, int white_rook_count, int white_queen_count, int black_pawns_count, int black_knight_count, int black_bishop_count, int black_bishop_count_1, int black_bishop_count_2, int black_rook_count, int black_queen_count)
{
  UINT64 value = 0;
  value += &#40;white_bishop_count / 2 - black_bishop_count / 2&#41; * (((&#40;UINT64&#41; 55&#41; << 48&#41; + ((&#40;UINT64&#41; 50&#41; << 32&#41; + ((&#40;UINT64&#41; 40&#41; << 16&#41; + ((&#40;UINT64&#41; 35&#41; << 0&#41;);
  value += &#40;white_pawns_count - black_pawns_count&#41; * (((&#40;UINT64&#41; 125&#41; << 48&#41; + ((&#40;UINT64&#41; 110&#41; << 32&#41; + ((&#40;UINT64&#41; 90&#41; << 16&#41; + ((&#40;UINT64&#41; 80&#41; << 0&#41;);
  value += &#40;white_knight_count - black_knight_count&#41; * (((&#40;UINT64&#41; 355&#41; << 48&#41; + ((&#40;UINT64&#41; 320&#41; << 32&#41; + ((&#40;UINT64&#41; 280&#41; << 16&#41; + ((&#40;UINT64&#41; 265&#41; << 0&#41;);
  value += &#40;white_rook_count - black_rook_count&#41; * (((&#40;UINT64&#41; 610&#41; << 48&#41; + ((&#40;UINT64&#41; 550&#41; << 32&#41; + ((&#40;UINT64&#41; 450&#41; << 16&#41; + ((&#40;UINT64&#41; 405&#41; << 0&#41;);
  value += &#40;white_queen_count - black_queen_count&#41; * (((&#40;UINT64&#41; 1150&#41; << 48&#41; + ((&#40;UINT64&#41; 1025&#41; << 32&#41; + ((&#40;UINT64&#41; 875&#41; << 16&#41; + ((&#40;UINT64&#41; 800&#41; << 0&#41;);
  value += &#40;white_bishop_count - black_bishop_count&#41; * (((&#40;UINT64&#41; 360&#41; << 48&#41; + ((&#40;UINT64&#41; 325&#41; << 32&#41; + ((&#40;UINT64&#41; 295&#41; << 16&#41; + ((&#40;UINT64&#41; 280&#41; << 0&#41;);
  if &#40;white_rook_count == 2&#41;
    value -= (((&#40;UINT64&#41; 32&#41; << 48&#41; + ((&#40;UINT64&#41; 28&#41; << 32&#41; + ((&#40;UINT64&#41; 20&#41; << 16&#41; + ((&#40;UINT64&#41; 16&#41; << 0&#41;);
  if &#40;black_rook_count == 2&#41;
    value += (((&#40;UINT64&#41; 32&#41; << 48&#41; + ((&#40;UINT64&#41; 28&#41; << 32&#41; + ((&#40;UINT64&#41; 20&#41; << 16&#41; + ((&#40;UINT64&#41; 16&#41; << 0&#41;);
  if &#40;white_queen_count + white_rook_count >= 2&#41;
    value -= (((&#40;UINT64&#41; 16&#41; << 48&#41; + ((&#40;UINT64&#41; 14&#41; << 32&#41; + ((&#40;UINT64&#41; 10&#41; << 16&#41; + ((&#40;UINT64&#41; 8&#41; << 0&#41;);
  if &#40;black_queen_count + black_rook_count >= 2&#41;
    value += (((&#40;UINT64&#41; 16&#41; << 48&#41; + ((&#40;UINT64&#41; 14&#41; << 32&#41; + ((&#40;UINT64&#41; 10&#41; << 16&#41; + ((&#40;UINT64&#41; 8&#41; << 0&#41;);
  value -= &#40;white_pawns_count - 5&#41; * white_rook_count * (((&#40;UINT64&#41; 0&#41; << 48&#41; + ((&#40;UINT64&#41; 2&#41; << 32&#41; + ((&#40;UINT64&#41; 4&#41; << 16&#41; + ((&#40;UINT64&#41; 5&#41; << 0&#41;);
  value += &#40;white_pawns_count - 5&#41; * white_knight_count * (((&#40;UINT64&#41; 5&#41; << 48&#41; + ((&#40;UINT64&#41; 4&#41; << 32&#41; + ((&#40;UINT64&#41; 2&#41; << 16&#41; + ((&#40;UINT64&#41; 0&#41; << 0&#41;);
  value += &#40;black_pawns_count - 5&#41; * black_rook_count * (((&#40;UINT64&#41; 0&#41; << 48&#41; + ((&#40;UINT64&#41; 2&#41; << 32&#41; + ((&#40;UINT64&#41; 4&#41; << 16&#41; + ((&#40;UINT64&#41; 5&#41; << 0&#41;);
  value -= &#40;black_pawns_count - 5&#41; * black_knight_count * (((&#40;UINT64&#41; 5&#41; << 48&#41; + ((&#40;UINT64&#41; 4&#41; << 32&#41; + ((&#40;UINT64&#41; 2&#41; << 16&#41; + ((&#40;UINT64&#41; 0&#41; << 0&#41;);
  return value;
&#125;

comeon we can talk a lot of crap, this is a neural network in action. Maybe for herman things weren't statistical tested very well, or some other beginners mistake in the proces. You make those easily of course. Or is it just plain desinformation?

My point is, in some buggy diep version (all kind of bugs in passed pawns for example in 2005 diep which was disaster and co - still suffer from that to some extend, fixing it rapidly now though) it already mattered +200 elo.

If i'd put back the values i had back during and before world champs 2005 in diep's material evaluation, Diep would lose of course more than 200 elopoints nowadays.

You'll say now of course in choir: "but if you gave in 2004 the tip to put a piece at 4.2 for Fruit, why didn't you do it yourself".

Yeah you know, how silly can one be. I have other 'compensation code' of course when you have a bunch of pawns against a piece. That just didn't work in the case you have 1 pawn against a piece.

The compensation you have in that case with old values is +2.6 versus today it's +2.8. If you look at it like this it seems like peanuts to talk about and it is, but it mattered really a lot of elo for diep.

The 1930s values of 3 or 3.25 for 1 piece in number of pawns is just so so ugly bad elowise, and it takes up to 3.8-4.3 pawns to flatten off and really work well.

It really matters a lot of elo. Yet if you look to that code that the other functions around it, does it look like a neural network to you or does it look like someone tried to win the worldchampionships bitshifting?

Vincent

[lkaufman]

I'm afraid I have no idea what you are talking about regarding getting information about Rybka values. But I can tell you that when I joined the Rybka team (around the time of version 2.1) the evaluation, both for material and positional terms, was quite bizarre, having been tuned in a purely automated way. Probably the values you are quoting come from some early version. Despite these crazy values, Rybka dominated the scene, perhaps due to superior search and/or coding. After I got involved the evaluation gradually became more and more like that of human Grandmasters (though not completely so, because some changes tested poorly), and by the time Rybka 3 came out the evals produced were quite reasonable and the program had advanced by roughly a class from when I first became involved (I'm not claiming that all or even most of the gain was from eval, though a good part was).