Als Antwort auf:/In reply to: Re: now the impact--gantlet Fruit 1.5, 600 games (Blitz) geschrieben von:/posted by: Dann Corbit at 15 June 2004 23:41:03:
No it is not.The effect is identical.NoI think that this last change is probably what accounts for the big Elo jump.Hi,There was an intermediate version Fruit X 05/21 that played in someFruit1.0 was improved by better evaluation and it is not news but the
main surprise is the improvement from Fruit X05/09 to Fruit1.5
I got the impression from fabian's words that the improvement from
Fruit X05/09 to Fruit1.5 is only thanks to better time management and
better compiler.
I understand that fruit did not know to use more time in case of fail
low in X05/09 and maybe there were more improvement in time
management(I did not read the relevant part of fruit source to find
out) but I did not think that it should give more than 30 elo
improvement.
together with better compiler 40 elo improvement make sense but 100
elo seems too good to be correct.
It is possible that I underestimated the time management improvement
and the meaning of it is the same of being twice faster.
Uri
tournaments (e.g. WBEC division qualifications).
Fruit X 05/21 and Fruit 1.5 are very similar in strength.
As far as I can remember, the only differences between Fruit X 05/09
and Fruit X 05/21 were:
1) time management
2) 20% speed improvement (on Linux)
I will check in my log files.
I mentionned the compiler as a way of thanking Slater Wold. I
obtained some speed improvement by changing low-level data structures.
Only Windows users can measure the actual difference in NPS. Joachim
Rang has the development executables and Dann probably does as well.
We can measure that if you want. You can't compare with Fruit 1.0
though because mobility slowed it down quite a lot.
I don't use aspiration search so I have no fail low. But Fruit 1.0
always stops the search when the time limit is reached, even if it
could "know" (with appropriate code) that the move is very bad.
Bear in mind that Fruit 1.0 has a hard time limit (no time management
by my standards). Fixing this is part of what I call "time management"
If fruit avoids a bad move even one time in a game, it will make a very large change. If the bad move leads to a loss, it is worth it even to lose on time to resolve something better.
So why not sit and think about it until you find something that minimizes the damage? Even if the clock expires you were going to lose anyway.
That is why I think it is not a good thing to remove programs that lose on time from tournaments. They are probably doing the right thing, sometimes.
By losing on time you can be sure of losing the game.
If you play the oponnent can blunder later.
If you lose a full pawn against a computer, it is very difficult to come back. If you lose a full piece, it will take a miracle. If you lose a major piece, then you can forget it.
No
losing on time is never the right thing.
If you think that there is no practical chance then it is better to resign.
resigning is encouraged by Leo.
Engines that lose on time cannot play in Leo's tournament.
Gnu did not play because of that problem(fortunately the problem was fixed by thomas mayer based on my memory so gnuchess can play in Leo's tournament)
And the problem is that you have no idea how long it will take to resolve the search.
You do not need to know.
It is enough to check for the time frequently based on node count.
To decide how much time to consume is a programmer decision, and the resolution of the time checks in the search could cause a failure to detect it has run out of time.
Movei checks for the time every 8192 nodes and if it is using more than half of the remaining time it plays immediatly(It does not happen often and usually movei stops the search at the end of the iteration).
>So if I see I have suddenly lost a huge part of my score, I may decide to allocate a great deal of time to resolve it. It would be nice if I never used all that remains, but I think it is excusable to do so.
I think that it is very easy to avoid it.
You can expect number of nodes that you start to be in danger of losing on time and you can tell the program to check for time if the number of nodes that it searched is above it and to play if the time is low enough even if it did not solve the fail low.
Uri
