Dann Corbit wrote:It is twice as good at what they call "long time control" compared to the fast time control. (about 7% improvement verses 3.5% improvement.)
Hence, when it moves to real time control (e.g. analyzing games or positions) I think it may be really excellent.
The idea is simple and so other chess engines may also benefit. If you are an author, I suggest you examine "Tweak statScore condition" by GuardianRM.
SF seems to be in a deadlock currently.
Huge hardware power, twice as many tests as in the past, and yet an incredible amount of reds and very few substantial patches.
I guess SF is simply over-tweaked and they don't know how to detweak it in order for new functional patches to start working again.
And nobody has bothered to repair it. I guess if the Sugar code left that patch out, it could easily explain the big strength difference.
It is possible that the introduction of a new book explains the dive, but all the programs in the tournaments use the book, so I doubt it.
I guess this is more of a hearsay.
no patch can account for 20 elo.
it is just latest SF development, with the addition of unused SF patches compiled randomly, that could produce random results at different TCs and diffrent number of games.
Jouni wrote:Testing framework now have Scaling Trend Prediction! Is it based on the fact, that faster computers have more draws?
Faster computers do have more draws.
But did you notice that the latest patch gets BETTER with longer time control?
That is very unusual. Normally, they become less noticeable when the time control gets longer. That is why I think it is important. I never do that ultra bullet kind of junk, so the high speed testing will tend to bubble up changes that are not very important to me.
Do we have enough games to be practically sure that the patch really get better with longer time control?
passing SPRT at LTC faster may be also because of luck.
No, but I think it is a good guess.
And looking at what the patch does, it seems logical to me also.
20 k games at LTC and 60 k games at STC control make 40 k games on average for the patch, that is just a tweak and will add some 1 elo or so.
SF needs patches that pass with some 7-15 k games on average to start gaining speed again.
The result from "Elberto One" for this patch at Short Time Control was nice! I hope it passes LTC too! Need more evaluation. Not more reduction patches for a while. Bishops on long diagonals or Bishop development patches in general have been a wish since Rebel times.
sprt @ 10+0.1 th 1 Bonus for bishop on long diagonal when center squares not occupied by pawns
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
cma6 wrote:"Sugar xpro 1.2 is stronger that either the previous 9/17/17 version of SF or the 8/25/17 version of asmfish."
Lyudmil:
Is there any point in doing an asmFish version of this superior program Sugar xpro 1.2?
If Sugar is indeed stronger than Stockfish (ignoring its large page support), then it would make sense to identify the modification(s) that make it stronger and add those to official SF.
When I took a superficial look at Sugar, it seemed to be simply Stockfish with a few patches that have failed in the testing framework. It is possible that some of those rejected patches are in fact improvements and failed only because of bad luck. But it is also possible that Sugar was just lucky in the couple of hundred test games that "proved" its superiority.
When I took a superficial look at Sugar, it seemed to be simply Stockfish with a few patches that have failed in the testing framework. It is possible that some of those rejected patches are in fact improvements and failed only because of bad luck. But it is also possible that Sugar was just lucky in the couple of hundred test games that "proved" its superiority.[/quote]
Thanks, Ronald, for the high level perspective. I am hoping that you and other engine experts like Lyudmil will be able to conclude what, if anything, Sugar contains of value. I would assume that the SF teams has been considering the matter.
cma6 wrote:When I took a superficial look at Sugar, it seemed to be simply Stockfish with a few patches that have failed in the testing framework. It is possible that some of those rejected patches are in fact improvements and failed only because of bad luck. But it is also possible that Sugar was just lucky in the couple of hundred test games that "proved" its superiority.
Thanks, Ronald, for the high level perspective. I am hoping that you and other engine experts like Lyudmil will be able to conclude what, if anything, Sugar contains of value. I would assume that the SF teams has been considering the matter.[/quote]
Eelco de Groot wrote:The result from "Elberto One" for this patch at Short Time Control was nice! I hope it passes LTC too! Need more evaluation. Not more reduction patches for a while. Bishops on long diagonals or Bishop development patches in general have been a wish since Rebel times.
sprt @ 10+0.1 th 1 Bonus for bishop on long diagonal when center squares not occupied by pawns
The first one did not pass at long time control but Stephane Nicolet managed to get an even better pass at STC, it needed less games and that one has passed LTC!
sprt @ 60+0.6 th 1 LTC: Go back to ElbertoOne's green original patch (main diagonals only), but with a pure midgame bonus
I got my wish I did not expect it anymore as Stephane's patch at LTC was not going very fast and slipping to negative values I think I saw at some point. Thanks guys !
Also a very nice patch from VoyagerOne and it's a reduction so I was wrong that Stockfish is reducing enough for the moment. But now we got both an eval and a search patch, that's what works best, congratulations to all three authors!
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
I did not expect it anymore as Stephane's patch at LTC was not going very fast and slipping to negative values I think I saw at some point. Thanks guys !