Similarity tool myth - debunked.

[Adam Hair]

The fact is, they don't.

For the same reason you mention, there 2-3 suitable moves in many positions to pick from. Expand this over 1000 positions and a higher match means a clear similarity in move selection or style.

Miguel

May be you are right but... I do not trust in statistics. are chess lottery game?

I think creative people are losing their energy for designig detective tools. It is a role for others.

No, chess is not a lottery. But, it is subject to statistical laws. A great amount of the strength increase over the past few years is due to a better understanding of this fact by engine authors. Few new ideas have been introduced. The existing ideas have been refined with the application of statistics.

[Rebel]

Over the many months since I released the similarity tool I have heard a LOT of comments implying that the similarity test is highly
sensitive to pieces square tables.

As long as PST values are reasonable in two (good) programs (and they of course are) no drastic similarity change is to be expected. PST cells contain some basic chess knowledge and you can not sin against that.

A while back I imported the Fruit PST's in mine to check this PST claim made and similarity with Fruit only raised 0.6% but the different move choices were remarkable.

One can only fool the similarity tool by seriously hurting a program's strength. Don also here is absolutely right.

[Uri Blass]

I remember that your similiarity tool detected also that Critter is too similiar to IvanHoe when you have the source of Critter and
Richard copied only the piece square table
so what worked for komodo did not work for Critter and it seems that not all the top programs are the same.

What are you talking about? I think Critter is closely patterned after Ivanhoe in more ways than just the piece square tables. But much less so that Houdini which started out from the same exact code based as Robbolitto.

What is it that worked and did not work? I don't know what you are saying here.

I simply write based on what I read here and I remember reading that Critter has big similiarity to Ivanhoe because Richard copied the piece square table and he did not copy other parts(It is based on what richard Vida said based on my memory) so I thought that the situation with Critter is different and if you change the piece square table in Critter you remove the similiarity to Ivanhoe

[Uri Blass]

I remember that your similiarity tool detected also that Critter is too similiar to IvanHoe when you have the source of Critter and
Richard copied only the piece square table
so what worked for komodo did not work for Critter and it seems that not all the top programs are the same.

What are you talking about? I think Critter is closely patterned after Ivanhoe in more ways than just the piece square tables. But much less so that Houdini which started out from the same exact code based as Robbolitto.

What is it that worked and did not work? I don't know what you are saying here.

I simply write based on what I read here and I remember reading that Critter has big similiarity to Ivanhoe because Richard copied the piece square table and he did not copy other parts(It is based on what richard Vida said based on my memory) so I thought that the situation with Critter is different and if you change the piece square table in Critter you remove the similiarity to Ivanhoe

Here is the relevant discussion and richard's post made the impression that the similiar piece square table of Critter is the reason for the similiarity that it has with the Ippo family

http://www.talkchess.com/forum/viewtopi ... 71&t=39577

Note that
I did not believe him and said exactly what you said that piece square table is a small part of the evaluation but I guessed from richard's posts that at least it is not the case for Critter.

If you say that Critter is closely patterned after Ivanhoe in more ways than just the piece square tables then I expect changing the piece square table to make only little change in the similiarity of Critter to the ippo family and I could expect Richard not to say that the similarity is mainly because of the piece square table.

[Don]

I remember that your similiarity tool detected also that Critter is too similiar to IvanHoe when you have the source of Critter and
Richard copied only the piece square table
so what worked for komodo did not work for Critter and it seems that not all the top programs are the same.

What are you talking about? I think Critter is closely patterned after Ivanhoe in more ways than just the piece square tables. But much less so that Houdini which started out from the same exact code based as Robbolitto.

What is it that worked and did not work? I don't know what you are saying here.

I simply write based on what I read here and I remember reading that Critter has big similiarity to Ivanhoe because Richard copied the piece square table and he did not copy other parts(It is based on what richard Vida said based on my memory) so I thought that the situation with Critter is different and if you change the piece square table in Critter you remove the similiarity to Ivanhoe

I understand what you meant now.

As you see the piece square tables have no special status - it's the entire evaluation function that counts. Of course some programs could make heavy use of them and others none at all, so it's totally dependent on how big a part of the evaluation function the piece square tables are. But for the really strong programs the piece squares tables are the equivalent of a few evaluation features and not a major component.

I don't think Richard was lying, but he may not have realized how much of Ivanhoe he borrowed. I know that Richard looks at all the programs and is exceptionally good at reverse engineering them. He looks at Houdini as well as Komodo - I know because within a day or two of release he will make some comment about a change I have made.

[CRoberson]

It has always been my belief that what is typically in PSTs should be used as tie-breaker values, thus they should not be dominate.

There are some programs that have little more than PST values, thus PSTs dominate the move choice. Also, one could make them dominate via extreme values. I would not recommend that.

[Don]

It has always been my belief that what is typically in PSTs should be used as tie-breaker values, thus they should not be dominate.

There are some programs that have little more than PST values, thus PSTs dominate the move choice. Also, one could make them dominate via extreme values. I would not recommend that.

Right. We basically do things we would do anyway even if we did not have pieces square tables. The example I gave was a knight on the edge of the board and some bonuses for centralizing the knight. That does not have to be done with piece square tables but it particularly efficient to do it that way when we can. Our knights also get a lot of dynamic bonuses and penalties, centralization is just one little piece.

So really, at least in Komodo, the pieces square tables mean absolutely nothing - they are just an implementation detail, a way to implement a few terms that are highly static in nature. I think I could even re-code the program in order to remove them without suffering much of a performance penalty.