zamar wrote:
Their search algorithms still differ a lot. IPP* has different pruning rules close to the leaves compared to Stockfish. You can't just blindly copy Rule X from IPP* to SF. The search is one picture. And we don't want to copy the whole search, it would just be pointless.
Yes, pruning is different near the leaves, but our tests indicate that generally speaking the SF approach is not inferior here to the IPP* approach. Probably you agree or you would have made a change in this respect.
An interesting question is what would happen if someone ported the SF eval to an IPP* derivative or the IPP* eval to SF, with appropriate changes to scale so margins are valid. Has anyone done so? Any opinions on what would happen in each of these two cases?
mcostalba wrote:
Because this question has been, for some reason, posted on the programmers subforum I assume the author was interested to give some fact and receive some fact back. Amazingly currently I don't see neither
Anyhow I'll keep looking at this post in the remote case something semi-serious emerges....
I don't understand your reaction, because the question is interesting. I have the same experience as Larry: if I replace one of my techniques by the one from Stockfish, my ELO drops a little. If I replace them by something from Ippolit, ELO drops a lot. If I replace one of the techniques in Ippolit by something from me, ELO drops a lot.
This non-transitivity is really funny, and for me quite unexpected. It's as if Ippolit is sitting on a very steep local minimum, and a different one from where DS and Stockfish are sitting.
bob wrote:
It doesn't mean that at all. It might mean stockfish does 2x the work at a single node. Whether that is good or bad is unknown. But it is not bad purely because it is slower.
I don't know the innards of both engines very well, but I assumed the evaluation function of Stockfish and Houdini to be roughly of the same complexity.
Evaluation is not the only thing. What about the code used to deal with pruning, reductions and such. Some use simple rules. Some toss in an eval call, + possibly a SEE call. Making a single node more expensive, but possibly more accurate as well...
Possibly...
When I look at my own program most of the time is spent in the quiescense search and evaluation. Things that I do in lower parts of the tree - like an extra SEE or eval call - hardly make any difference in total nodes per second.
For Stockfish it can be different of course. One major difference is that Stockfish uses the transposition table in its quiescense search.
mcostalba wrote:
Because this question has been, for some reason, posted on the programmers subforum I assume the author was interested to give some fact and receive some fact back. Amazingly currently I don't see neither
Anyhow I'll keep looking at this post in the remote case something semi-serious emerges....
I don't understand your reaction, because the question is interesting. I have the same experience as Larry: if I replace one of my techniques by the one from Stockfish, my ELO drops a little. If I replace them by something from Ippolit, ELO drops a lot. If I replace one of the techniques in Ippolit by something from me, ELO drops a lot.
This non-transitivity is really funny, and for me quite unexpected. It's as if Ippolit is sitting on a very steep local minimum, and a different one from where DS and Stockfish are sitting.
The ELO difference between SF and Ippo should be around 20 ELO or less. You cannot build up a "theory" out of such a small difference: anything can account for that, few tweaks or few slightly differences are enough and we have much more then slightly differences bewteen Ippo and SF. So the original question is badly expressed IMHO.
Instead your concerns are much more interesting and actually have more arguments inside.
P.S: Probably the correct (and honest) way to present the original question should have been: "Komodo is much weaker then SF and in Ippo although we have tried all the ideas both in SF and Ippo: how can do that ?"
The ELO difference between SF and Ippo should be around 20 ELO or less. You cannot build up a "theory" out of such a small difference: anything can account for that, few tweaks or few slightly differences are enough and we have much more then slightly differences bewteen Ippo and SF. So the original question is badly expressed IMHO.
The 20 Elo figure is based on comparing the latest SF with Robbo or an early clone of it. But SF has been vastly improved over the last year, and now so has Robbo in the form of Houdini. So if you compare say SF 1.6 to Robbo and SF 2.0 to Houdini the gap remains around a hundred Elo.
Instead your concerns are much more interesting and actually have more arguments inside.
P.S: Probably the correct (and honest) way to present the original question should have been: "Komodo is much weaker then SF and in Ippo although we have tried all the ideas both in SF and Ippo: how can do that ?"[/quote]
No, I wasn't asking why we haven't (yet) passed SF, I want to know why passing SF won't make us #1!
lkaufman wrote: No, I wasn't asking why we haven't (yet) passed SF, I want to know why passing SF won't make us #1!
Sorry but you have a bit of confusion: #1 is currenty houdini not ippo and houdini is 60-70 ELO far away....so I think you have to wait for someone to disassemble Houdini for you and reveals the couple of extra tricks that Robert but on top of what we already know to achieve that extra boost
lkaufman wrote: No, I wasn't asking why we haven't (yet) passed SF, I want to know why passing SF won't make us #1!
Sorry but you have a bit of confusion: #1 is currenty houdini not ippo and houdini is 60-70 ELO far away....so I think you have to wait for someone to disassemble Houdini for you and reveals the couple of extra tricks that Robert but on top of what we already know to achieve that extra boost
I don't think it's quite fair to compare the highly optimized SF 2.0 with the very first Ippo derivative. Houdini 1.5 represents optimization of Ippo in the same sense as SF 2.0 is optimization of SF 1.6 or so, so I think it's fair to say that for reasons neither of us understands the Ippo derivatives have some large innate advantage.
lkaufman wrote: No, I wasn't asking why we haven't (yet) passed SF, I want to know why passing SF won't make us #1!
Sorry but you have a bit of confusion: #1 is currenty houdini not ippo and houdini is 60-70 ELO far away....so I think you have to wait for someone to disassemble Houdini for you and reveals the couple of extra tricks that Robert but on top of what we already know to achieve that extra boost
I don't think it's quite fair to compare the highly optimized SF 2.0 with the very first Ippo derivative. Houdini 1.5 represents optimization of Ippo in the same sense as SF 2.0 is optimization of SF 1.6 or so, so I think it's fair to say that for reasons neither of us understands the Ippo derivatives have some large innate advantage.
I don't agree. Houdini 1.03 _could be_ more or less Ippo cleaned up and refined, perhaps throwing in some SF stuff.
But Houdini 1.5 has some new tricks in IMHO, otherwise you cannot get 70 ELO jump only fine tuning an engine that, by the way, is already very well tuned.
mcostalba wrote:
I don't agree. Houdini 1.03 _could be_ more or less Ippo cleaned up and refined, perhaps throwing in some SF stuff.
But Houdini 1.5 has some new tricks in IMHO, otherwise you cannot get 70 ELO jump only fine tuning an engine that, by the way, is already very well tuned.
I agree completely about Houdini. But wouldn't you say that between version 1.6 and 2.0 of SF you did more that just tuning? I think there were some significant new ideas in that interval.
lkaufman wrote:
An interesting question is what would happen if someone ported the SF eval to an IPP* derivative or the IPP* eval to SF, with appropriate changes to scale so margins are valid. Has anyone done so? Any opinions on what would happen in each of these two cases?
I think you are the man who should know, because you wrote IPPO's eval IPPO's eval is much more complex than SF's eval (fx. SF has only one open file bonus, but IPPO has many different weights depending on piece blockade on the file. And there are many other fine tunings for different terms, as we both know).
At some point we tried to implement those IPPO's eval terms in SF, but their possible ELO strength increase seems to be so minor that our testing system is not enough accurate to reliably measure the improvement.
Of course we could just take everything at one shot, but we don't want to put SF on same legally grey waters on which IPP* is sailing.
IPPO's eval is much more complex than SF's eval (fx. SF has only one open file bonus, but IPPO has many different weights depending on piece blockade on the file. And there are many other fine tunings for different terms, as we both know).