one question about knowledge chess engine match one ply ?

[chrisw]

Robert
Of course you are correct in some of the statements you made. However, of a period of 15 years I could not get past one ply as I was unable to inplement alpha/beta so during that time I tried hundreds of different things to increase my little programs playing strength. Without changing any of the evals I went to a deeper sort and discovered that some of those functions I needed at one ply because of the 'horizon' were not necessary at depth.
I still only have one evaluation routine and work on it as I would a one ply system, with some informed considerations of course. I am sure that some of you know that my experience in programming and in chess especialy I am still considered very weak, but my little program gets a little stronger with each passing day?, month? year? Sometime progress is very slow.
Bill

I have always thought of it like this: "Evaluation is just a poor substitute for accurate search". If you can search deep enough, no evaluation is needed at all. That being said, there are things that help, clearly, and some that hurt, such as the pawn scoring issue we had in 1986 that almost lost the WCCC for us...

This concept, a Bob favourite for many years, is true in an absolute sense but can be rejected for current paradigm. It would only be true in a full width, no pruning, depth sufficient to see to EGTB/mate, but since such a search is effectively impossible it renders the concept meaningless and valueless.

Current paradigm is (in part) to use some form of forward pruning (null move for example) to cut back the search width. To do that requires an evaluation function of some sort. Which parts of the search tree get thrown out and which are searched is then completely dependent on the evaluation function, such that different programs will search different trees. This was the idea of CSTal of course.

So, programmers, don't be misled by Bob's favourite 'truth'

In the context I gave it, it is an _absolute_ truth, not conjecture. And the original statement, "evaluation is a poor substitute for search" is also absolute truth. Otherwise why don't you write a program with _no_ searching? Evaluation is code written to pick up where the search leaves off and try to make some basic sense of the resulting positions for comparison purposes. But we _know_ it is beyond "highly inaccurate". Otherwise everyone would be quite happy with 1 ply searches...

By your logic why don't you write a program with no evaluation? Which would prove "search is a poor substitute for evaluation", equally well proven, if not better.

Or go write it, and come back when you get a result ..........

Arguing with concepts impossibly stretched to infinity leads to your nonsense statement of search is all. Yes, if you have until the end of the universe to wait. Equally, given a giant lookup table of all possible positions, it could be all done in 'evaluation' at one-ply.

And btw, null-move and all forms of forward pruning fail without an evaluation function, rendering the search even slower.

The problem with your view of eval-search is it leads to search concentration with resultant material and numbers fetishism. It leads to exclusion of evaluation concentration and thus lack of human/emotional side to chess. Basically your view leads to numbers boredom as represented by automated game collection and rating lists.

[bob]

Robert
Of course you are correct in some of the statements you made. However, of a period of 15 years I could not get past one ply as I was unable to inplement alpha/beta so during that time I tried hundreds of different things to increase my little programs playing strength. Without changing any of the evals I went to a deeper sort and discovered that some of those functions I needed at one ply because of the 'horizon' were not necessary at depth.
I still only have one evaluation routine and work on it as I would a one ply system, with some informed considerations of course. I am sure that some of you know that my experience in programming and in chess especialy I am still considered very weak, but my little program gets a little stronger with each passing day?, month? year? Sometime progress is very slow.
Bill

I have always thought of it like this: "Evaluation is just a poor substitute for accurate search". If you can search deep enough, no evaluation is needed at all. That being said, there are things that help, clearly, and some that hurt, such as the pawn scoring issue we had in 1986 that almost lost the WCCC for us...

This concept, a Bob favourite for many years, is true in an absolute sense but can be rejected for current paradigm. It would only be true in a full width, no pruning, depth sufficient to see to EGTB/mate, but since such a search is effectively impossible it renders the concept meaningless and valueless.

Current paradigm is (in part) to use some form of forward pruning (null move for example) to cut back the search width. To do that requires an evaluation function of some sort. Which parts of the search tree get thrown out and which are searched is then completely dependent on the evaluation function, such that different programs will search different trees. This was the idea of CSTal of course.

So, programmers, don't be misled by Bob's favourite 'truth'

In the context I gave it, it is an _absolute_ truth, not conjecture. And the original statement, "evaluation is a poor substitute for search" is also absolute truth. Otherwise why don't you write a program with _no_ searching? Evaluation is code written to pick up where the search leaves off and try to make some basic sense of the resulting positions for comparison purposes. But we _know_ it is beyond "highly inaccurate". Otherwise everyone would be quite happy with 1 ply searches...

By your logic why don't you write a program with no evaluation? Which would prove "search is a poor substitute for evaluation", equally well proven, if not better.

Because I have already said "we can't yet search deeply enough." But as the search reaches a depth where it "understands" a tactial theme, then evaluating that theme is generally harmful because it wastes time.

Or go write it, and come back when you get a result ..........

Arguing with concepts impossibly stretched to infinity leads to your nonsense statement of search is all. Yes, if you have until the end of the universe to wait. Equally, given a giant lookup table of all possible positions, it could be all done in 'evaluation' at one-ply.

And btw, null-move and all forms of forward pruning fail without an evaluation function, rendering the search even slower.

Hmm... mine doesn't even use evaluation, particularly on things like reductions (forward pruning), extensions, and whether or not to try a null-move.

The problem with your view of eval-search is it leads to search concentration with resultant material and numbers fetishism. It leads to exclusion of evaluation concentration and thus lack of human/emotional side to chess. Basically your view leads to numbers boredom as represented by automated game collection and rating lists.

Let's get back to reality. The discussion was about some evaluation terms that become redundant when you can search deeply enough. And which can actually hurt in several ways, from slowing you down, to double-penalizing something when the search understands it as well as the evaluation does. Evaluating forks and pins are good examples. I haven't evaluated either since somewhere in the late 70's, and I haven't been burned by a fork or pin that I can recall in the past 5-10 years. Search goes deeply enough to make forks and pins a non-issue. There are lots of other examples of things that used to be important in an evaluation, but no longer are due to deep search depths of today (in the last 45+10 tournament we held on ICC, I was seeing depths of 19-20 plies on an 8-core box, for reference). I once (1986) made a horrible eval change that worked well at depths of 4-5, but failed miserably at depths of 10-11 on the cray. The search slowly subsumes lots of old evaluation ideas, although there are still plenty of things left to evaluate since the search is still a long way from being "deep enough".

[Uri Blass]

Robert
Of course you are correct in some of the statements you made. However, of a period of 15 years I could not get past one ply as I was unable to inplement alpha/beta so during that time I tried hundreds of different things to increase my little programs playing strength. Without changing any of the evals I went to a deeper sort and discovered that some of those functions I needed at one ply because of the 'horizon' were not necessary at depth.
I still only have one evaluation routine and work on it as I would a one ply system, with some informed considerations of course. I am sure that some of you know that my experience in programming and in chess especialy I am still considered very weak, but my little program gets a little stronger with each passing day?, month? year? Sometime progress is very slow.
Bill

I have always thought of it like this: "Evaluation is just a poor substitute for accurate search". If you can search deep enough, no evaluation is needed at all. That being said, there are things that help, clearly, and some that hurt, such as the pawn scoring issue we had in 1986 that almost lost the WCCC for us...

This concept, a Bob favourite for many years, is true in an absolute sense but can be rejected for current paradigm. It would only be true in a full width, no pruning, depth sufficient to see to EGTB/mate, but since such a search is effectively impossible it renders the concept meaningless and valueless.

Current paradigm is (in part) to use some form of forward pruning (null move for example) to cut back the search width. To do that requires an evaluation function of some sort. Which parts of the search tree get thrown out and which are searched is then completely dependent on the evaluation function, such that different programs will search different trees. This was the idea of CSTal of course.

So, programmers, don't be misled by Bob's favourite 'truth'

In the context I gave it, it is an _absolute_ truth, not conjecture. And the original statement, "evaluation is a poor substitute for search" is also absolute truth. Otherwise why don't you write a program with _no_ searching? Evaluation is code written to pick up where the search leaves off and try to make some basic sense of the resulting positions for comparison purposes. But we _know_ it is beyond "highly inaccurate". Otherwise everyone would be quite happy with 1 ply searches...

By your logic why don't you write a program with no evaluation? Which would prove "search is a poor substitute for evaluation", equally well proven, if not better.

Because I have already said "we can't yet search deeply enough." But as the search reaches a depth where it "understands" a tactial theme, then evaluating that theme is generally harmful because it wastes time.

Or go write it, and come back when you get a result ..........

Arguing with concepts impossibly stretched to infinity leads to your nonsense statement of search is all. Yes, if you have until the end of the universe to wait. Equally, given a giant lookup table of all possible positions, it could be all done in 'evaluation' at one-ply.

And btw, null-move and all forms of forward pruning fail without an evaluation function, rendering the search even slower.

Hmm... mine doesn't even use evaluation, particularly on things like reductions (forward pruning), extensions, and whether or not to try a null-move.

The problem with your view of eval-search is it leads to search concentration with resultant material and numbers fetishism. It leads to exclusion of evaluation concentration and thus lack of human/emotional side to chess. Basically your view leads to numbers boredom as represented by automated game collection and rating lists.

Let's get back to reality. The discussion was about some evaluation terms that become redundant when you can search deeply enough. And which can actually hurt in several ways, from slowing you down, to double-penalizing something when the search understands it as well as the evaluation does. Evaluating forks and pins are good examples. I haven't evaluated either since somewhere in the late 70's, and I haven't been burned by a fork or pin that I can recall in the past 5-10 years. Search goes deeply enough to make forks and pins a non-issue. There are lots of other examples of things that used to be important in an evaluation, but no longer are due to deep search depths of today (in the last 45+10 tournament we held on ICC, I was seeing depths of 19-20 plies on an 8-core box, for reference). I once (1986) made a horrible eval change that worked well at depths of 4-5, but failed miserably at depths of 10-11 on the cray. The search slowly subsumes lots of old evaluation ideas, although there are still plenty of things left to evaluate since the search is still a long way from being "deep enough".

I do not believe in your theories the fact that you did not lose because of a fork does not mean that fork is irrelevant in the evaluation because
seeing the fork earlier may help simply to play better positional moves.

The side that does not consider forks in the evaluation is going to see it in search but only after making some positional mistake and it can avoid the positional mistake at least in the same depth by having forks inside the evaluation.

You can say that you can get bigger depth without evaluating forks but the same is correct also for small depths.

I can add that by your logic with no evaluation you can simply drop material in KQP vs KQ endgame because every move draws(and no evaluation means also no material evaluation) and if you do things like it then you can practically miss a win because you do not make moves that help your opponent to blunder.

I do not evaluate forks in movei because it is not easy to do it correctly
and I did not try it but my opinion is that it can be a good idea if it is done correctly.

Uri