Fruit 0.98 - Ruffian 2.1.0: 53 - 211

[Joachim Rang]

Geschrieben von: / Posted by: Joachim Rang at 11 March 2004 13:46:01:

Playing conditions:
Athlon 1500 MHz, 16 MB HAsh, each, Hiarcs9-Book under chessbase-GUI 2m/game
Result: 53-211
Well, I didn't expect that Fruit will be able to compete with Ruffian 2.1.0 I just wanted to look if there are any bugs in such a long eng-eng-match. I had a brief look and it seems everything went smoothly, no loss on time even in such bullet-time, no crash, no illegal move (I didn't check all games but a few).
240 Elopoints weaker than Ruffe 2.1.0 is not so bad after all.
regards Joachim

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 11 March 2004 13:51:43:
Als Antwort auf: / In reply to: Fruit 0.98 - Ruffian 2.1.0: 53 - 211 geschrieben von: / posted by: Joachim Rang at 11 March 2004 13:46:01:

Playing conditions:
Athlon 1500 MHz, 16 MB HAsh, each, Hiarcs9-Book under chessbase-GUI 2m/game
Result: 53-211
Well, I didn't expect that Fruit will be able to compete with Ruffian 2.1.0 I just wanted to look if there are any bugs in such a long eng-eng-match. I had a brief look and it seems everything went smoothly, no loss on time even in such bullet-time, no crash, no illegal move (I didn't check all games but a few).
240 Elopoints weaker than Ruffe 2.1.0 is not so bad after all.
regards Joachim

Yes I'm only looking for big problems at the moment, and all os OK so far.
I am still adding a bit more UCI support, and I intend to add UCI search options to make version 1.0
Yes I think Fruit loses on time in some 1 0 games, but not 2 0.
Fabien.

[Joachim Rang]

Geschrieben von: / Posted by: Joachim Rang at 11 March 2004 14:04:46:
Als Antwort auf: / In reply to: Re: Fruit 0.98 - Ruffian 2.1.0: 53 - 211 geschrieben von: / posted by: Fabien Letouzey at 11 March 2004 13:51:43:

Playing conditions:
Athlon 1500 MHz, 16 MB HAsh, each, Hiarcs9-Book under chessbase-GUI 2m/game
Result: 53-211
Well, I didn't expect that Fruit will be able to compete with Ruffian 2.1.0 I just wanted to look if there are any bugs in such a long eng-eng-match. I had a brief look and it seems everything went smoothly, no loss on time even in such bullet-time, no crash, no illegal move (I didn't check all games but a few).
240 Elopoints weaker than Ruffe 2.1.0 is not so bad after all.
regards Joachim

Yes I'm only looking for big problems at the moment, and all os OK so far.
I am still adding a bit more UCI support, and I intend to add UCI search options to make version 1.0
Yes I think Fruit loses on time in some 1 0 games, but not 2 0.
Fabien.

well Multivariation-Mode would be great (but it has time).
regards Joachim

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 11 March 2004 14:20:26:
Als Antwort auf: / In reply to: Re: Fruit 0.98 - Ruffian 2.1.0: 53 - 211 geschrieben von: / posted by: Joachim Rang at 11 March 2004 14:04:46:

well Multivariation-Mode would be great (but it has time).

Clearly not planned for version 1.0
Very easy to do in a crappy way (works but slow)
Not so easy to integrate a fine implementation without a lot of new code
Also I fail to understand how Fruit could be useful for analysis ...
Fabien.

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 11 March 2004 14:45:35:
Als Antwort auf: / In reply to: Re: Fruit 0.98 - Ruffian 2.1.0: 53 - 211 geschrieben von: / posted by: Fabien Letouzey at 11 March 2004 14:20:26:

well Multivariation-Mode would be great (but it has time).

Clearly not planned for version 1.0
Very easy to do in a crappy way (works but slow)
Not so easy to integrate a fine implementation without a lot of new code
Also I fail to understand how Fruit could be useful for analysis ...
Fabien.

If fruit is really better with more time then it can be the best if you give it 24 hours to search and correspondence players may use it.
Note that I do not claim that it is better with longer time control and it is a possibility that you suggested to check.
It is also possible that it is not fruit that is better at long time control but most amateurs that are worse at long time control.
Uri

[Joachim Rang]

Geschrieben von: / Posted by: Joachim Rang at 12 March 2004 17:21:55:
Als Antwort auf: / In reply to: Re: Fruit 0.98 - Ruffian 2.1.0: 53 - 211 geschrieben von: / posted by: Fabien Letouzey at 11 March 2004 14:20:26:

well Multivariation-Mode would be great (but it has time).

Clearly not planned for version 1.0
Very easy to do in a crappy way (works but slow)
Not so easy to integrate a fine implementation without a lot of new code
Also I fail to understand how Fruit could be useful for analysis ...
Fabien.

...because the PV is always "correct". This is a great feature for analysis purposes and helps a lot to spot possible plans in the position.
regards Joachim

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 12 March 2004 18:13:18:
Als Antwort auf: / In reply to: Re: Fruit 0.98 - Ruffian 2.1.0: 53 - 211 geschrieben von: / posted by: Joachim Rang at 12 March 2004 17:21:55:

well Multivariation-Mode would be great (but it has time).

Clearly not planned for version 1.0
Very easy to do in a crappy way (works but slow)
Not so easy to integrate a fine implementation without a lot of new code
Also I fail to understand how Fruit could be useful for analysis ...
Fabien.

...because the PV is always "correct". This is a great feature for analysis purposes and helps a lot to spot possible plans in the position.
regards Joachim

The pv is always correct also in stronger programs than fruit like Crafty.
I also always read the pv from the pv array and not from hash tables.
I think reading the pv from hash tables that means possible wrong pv is in contradiction to some good search ideas that I may use in the future.
Uri

[Joachim Rang]

Geschrieben von: / Posted by: Joachim Rang at 13 March 2004 10:55:08:
Als Antwort auf: / In reply to: Re: Fruit 0.98 - Ruffian 2.1.0: 53 - 211 geschrieben von: / posted by: Uri Blass at 12 March 2004 18:13:18:

well Multivariation-Mode would be great (but it has time).

Clearly not planned for version 1.0
Very easy to do in a crappy way (works but slow)
Not so easy to integrate a fine implementation without a lot of new code
Also I fail to understand how Fruit could be useful for analysis ...
Fabien.

...because the PV is always "correct". This is a great feature for analysis purposes and helps a lot to spot possible plans in the position.
regards Joachim

The pv is always correct also in stronger programs than fruit like Crafty.
I also always read the pv from the pv array and not from hash tables.
I think reading the pv from hash tables that means possible wrong pv is in contradiction to some good search ideas that I may use in the future.
Uri

but afaik crafty does hash cuts even in the pv. How is ist possible, that than the pv is always reliable?
regards Joachim