Lyudmil Tsvetkov wrote: I hate personalising the thread, so it is better to stop somewhere here.
you said that I should not be criticising the SF concept/model, that I do not understand.
what is so difficult to understand? recursively reaching depth 0, SF starts doing quiescence search, as any other engine around, to only evaluate 'quiet' positions with no available captures, checks or other relevant threat moves.
without quiescence search and depth 1 SF probably plays around 1500 elo
without quiescence search and depth 10 SF probably plays around 2000 elo
with qs and depth 1 probably around same 2000 elo
with qs and depth 10 around 2500 elo, etc.
so, basically, qs should be worth at least around 500-1000 elo alone.
etc., etc., etc., too boring to discuss when minds do not quite meet.
??
SF is a search engine with an excellent eval. What we are discussing is the eval part while you constantly want to involve search into the discussion.
Lyudmil Tsvetkov wrote:I guess the best thing you could currently do is offer another engine that would play 200 elo stronger, but only on Fridays.
Your memory is good.
a single ply search is also a search.
ever seen an engine playing with just assessing the root position?
Lyudmil Tsvetkov wrote: I hate personalising the thread, so it is better to stop somewhere here.
you said that I should not be criticising the SF concept/model, that I do not understand.
what is so difficult to understand? recursively reaching depth 0, SF starts doing quiescence search, as any other engine around, to only evaluate 'quiet' positions with no available captures, checks or other relevant threat moves.
without quiescence search and depth 1 SF probably plays around 1500 elo
without quiescence search and depth 10 SF probably plays around 2000 elo
with qs and depth 1 probably around same 2000 elo
with qs and depth 10 around 2500 elo, etc.
so, basically, qs should be worth at least around 500-1000 elo alone.
etc., etc., etc., too boring to discuss when minds do not quite meet.
??
SF is a search engine with an excellent eval. What we are discussing is the eval part while you constantly want to involve search into the discussion.
Lyudmil Tsvetkov wrote:I guess the best thing you could currently do is offer another engine that would play 200 elo stronger, but only on Fridays.
Your memory is good.
a single ply search is also a search.
ever seen an engine playing with just assessing the root position?
It seems to me you are still under the impression that the fun you made out of 2 positions you posted are the result of a bad full evaluation, isn't it? If so you are wrong.
Lyudmil Tsvetkov wrote: I hate personalising the thread, so it is better to stop somewhere here.
you said that I should not be criticising the SF concept/model, that I do not understand.
what is so difficult to understand? recursively reaching depth 0, SF starts doing quiescence search, as any other engine around, to only evaluate 'quiet' positions with no available captures, checks or other relevant threat moves.
without quiescence search and depth 1 SF probably plays around 1500 elo
without quiescence search and depth 10 SF probably plays around 2000 elo
with qs and depth 1 probably around same 2000 elo
with qs and depth 10 around 2500 elo, etc.
so, basically, qs should be worth at least around 500-1000 elo alone.
etc., etc., etc., too boring to discuss when minds do not quite meet.
??
SF is a search engine with an excellent eval. What we are discussing is the eval part while you constantly want to involve search into the discussion.
Lyudmil Tsvetkov wrote:I guess the best thing you could currently do is offer another engine that would play 200 elo stronger, but only on Fridays.
Your memory is good.
a single ply search is also a search.
ever seen an engine playing with just assessing the root position?
It seems to me you are still under the impression that the fun you made out of 2 positions you posted are the result of a bad full evaluation, isn't it? If so you are wrong.
what do you mean full?
lazy eval, or pruning at root?
A similar approach is to use very short "nodestime", time (of order of ms) to equal desired number of nodes, proportional to engine's speed. I used that on STS 1500 testsuite:
Hello Tsvetkov, I think it doesn't make much sense to compare an engine X to an engine Y at fixed depth like you did. That's because the definition of depth differs between engines (it is an iteration of something different according to which engine we consider). There are other more meaningful ways to compare engines.
Some programmer guru correct me if I'm wrong.
Lyudmil Tsvetkov wrote: I hate personalising the thread, so it is better to stop somewhere here.
you said that I should not be criticising the SF concept/model, that I do not understand.
what is so difficult to understand? recursively reaching depth 0, SF starts doing quiescence search, as any other engine around, to only evaluate 'quiet' positions with no available captures, checks or other relevant threat moves.
without quiescence search and depth 1 SF probably plays around 1500 elo
without quiescence search and depth 10 SF probably plays around 2000 elo
with qs and depth 1 probably around same 2000 elo
with qs and depth 10 around 2500 elo, etc.
so, basically, qs should be worth at least around 500-1000 elo alone.
etc., etc., etc., too boring to discuss when minds do not quite meet.
??
SF is a search engine with an excellent eval. What we are discussing is the eval part while you constantly want to involve search into the discussion.
Lyudmil Tsvetkov wrote:I guess the best thing you could currently do is offer another engine that would play 200 elo stronger, but only on Fridays.
Your memory is good.
a single ply search is also a search.
ever seen an engine playing with just assessing the root position?
It seems to me you are still under the impression that the fun you made out of 2 positions you posted are the result of a bad full evaluation, isn't it? If so you are wrong.
what do you mean full?
lazy eval, or pruning at root?
You are getting close, there are more explanations.
Laskos wrote:A similar approach is to use very short "nodestime", time (of order of ms) to equal desired number of nodes, proportional to engine's speed. I used that on STS 1500 testsuite:
Laskos wrote:A similar approach is to use very short "nodestime", time (of order of ms) to equal desired number of nodes, proportional to engine's speed. I used that on STS 1500 testsuite: