AEGT : list of participants, with version numbers

[Tom Likens]

Geschrieben von:/Posted by: Tom Likens at 23 July 2004 16:35:13:
Als Antwort auf:/In reply to: Re: AEGT : list of participants, with version numbers geschrieben von:/posted by: Uri Blass at 23 July 2004 16:12:24:

Yes, speed ! I spend all my time wondering how others do it .

So do I. In Gothmog, I always blamed the miserably low nodes/second count
on my complicated evaluation function. After working for some time on Gothmog's
successor, I am no longer so sure. My board representation and data structures
look good, and the code is simple, straightforward, and with no obvious
inefficiencies which I can see. The evaluation currently consists of material
and piece square tables only, and the score is incrementally updated when moves
are made/unmade.
This sounds like a speed monster, but it isn't. On my PIV 2.4 GHz, the
nodes/second count is comparable to Crafty's. Not very impressive for a
program with only incremental eval. I wonder what I am doing wrong.
Tord

Maybe Crafty is using superior compiler.
Did You try to use the same compiler that you use for gothmog for Crafty
and compare the speed of Gothmog with Crafty?
Another question is if you count nodes the same as Crafty.
As far as I know crafty includes also illegal moves as part of it's nodes.
In the case of movei I never expected to have the same speed as Crafty because my makemove update information about the attacked squares and as far as I know Crafty has not this information.
I am happy enough with the fact that movei has similiar speed to some commercial programs like Shredder or Hiarcs and I believe that no speed improvement is needed in order to be stronger then them(only better algorithm).
Latest version also does not do incremental update of piece square tables.
The problem is that there are different piece square table for opening and
endgame and I decided that it is better to lose some speed and do the code more simpler in order not to have bugs(it only costed me something like being 5% slower in nodes per second and the improvement that I did later in evaluating transition from opening to endgame based on some average between opening king table and endgame king table in similiar way to fruit is probably more than it).
Uri

Hello Uri,
I'm wrestling with this exact problem now. I'm toying with the idea of
maintaining *two* piece table variables, one for the opening/middlegame and
one for the endgame. These variables would get updated incrementally in the
make/unmake move functions and averaged in the final evaluation.
I'm not sure yet if it's worth it, since it may become too unwieldy. One
potential trouble spot is the scoring of the king's location. Djinn uses
different piece king tables in the endgame, depending on the locations of the
pawns. For example, if all the pawns (for both sides) are on the queenside
then the piece tables encourage the king to move towards the queenside, (and
of course the converse is true for the kingside).
My proposed solution for this is to hash the information about which table to
use in the pawn hash table. And while this works for this problem, there are
others that are not so easily solved.
regards,
--tom

[Igor Gorelikov]

Geschrieben von:/Posted by: Igor Gorelikov at 23 July 2004 16:40:47:
Als Antwort auf:/In reply to: Re: slight corrections of names geschrieben von:/posted by: Olivier Deville at 23 July 2004 15:51:14:

I think that we should use engine names assigned by their authors:
feature myname="Gothmog 1.0 beta 10"
feature myname="List 512"
Igor

Gothmog 1.0b10
List 5.12 (will play with no book, unless the author provides us with a book...)

You are rignt, Igor : we should all take exactly the same names for the engines. This will be much better if we put all the games together in a database anyway.
Olivier

Yes, that's very important to keep the same names!
It save us a lot of work (to correct names afterwards).
Igor

[Martin Baumung]

Geschrieben von:/Posted by: Martin Baumung at 23 July 2004 16:48:01:
Als Antwort auf:/In reply to: AEGT : list of participants, with version numbers geschrieben von:/posted by: Olivier Deville at 23 July 2004 11:35:30:

Hi all,
is Quark 2.35 available? IIRC that's the version that played in Paderborn!
Regards,
Martin

[Igor Gorelikov]

Geschrieben von:/Posted by: Igor Gorelikov at 23 July 2004 17:00:23:
Als Antwort auf:/In reply to: AEGT : list of participants, with version numbers geschrieben von:/posted by: Olivier Deville at 23 July 2004 11:35:30:

To help Heinz and all of us I compile/squeeze/exract a draft of AEGT regulation and upload it to my site (your list is also added to it).
http://www.digichess.gr/infiniteloop/etc/AEGT_draft.txt
I will try to keep it as short as possible but include all our decisions and proposals.
Igor

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 23 July 2004 17:13:39:
Als Antwort auf:/In reply to: Re: AEGT : list of participants, with version numbers geschrieben von:/posted by: Tom Likens at 23 July 2004 16:35:13:

Yes, speed ! I spend all my time wondering how others do it .

So do I. In Gothmog, I always blamed the miserably low nodes/second count
on my complicated evaluation function. After working for some time on Gothmog's
successor, I am no longer so sure. My board representation and data structures
look good, and the code is simple, straightforward, and with no obvious
inefficiencies which I can see. The evaluation currently consists of material
and piece square tables only, and the score is incrementally updated when moves
are made/unmade.
This sounds like a speed monster, but it isn't. On my PIV 2.4 GHz, the
nodes/second count is comparable to Crafty's. Not very impressive for a
program with only incremental eval. I wonder what I am doing wrong.
Tord

Maybe Crafty is using superior compiler.
Did You try to use the same compiler that you use for gothmog for Crafty
and compare the speed of Gothmog with Crafty?
Another question is if you count nodes the same as Crafty.
As far as I know crafty includes also illegal moves as part of it's nodes.
In the case of movei I never expected to have the same speed as Crafty because my makemove update information about the attacked squares and as far as I know Crafty has not this information.
I am happy enough with the fact that movei has similiar speed to some commercial programs like Shredder or Hiarcs and I believe that no speed improvement is needed in order to be stronger then them(only better algorithm).
Latest version also does not do incremental update of piece square tables.
The problem is that there are different piece square table for opening and
endgame and I decided that it is better to lose some speed and do the code more simpler in order not to have bugs(it only costed me something like being 5% slower in nodes per second and the improvement that I did later in evaluating transition from opening to endgame based on some average between opening king table and endgame king table in similiar way to fruit is probably more than it).
Uri

Hello Uri,
I'm wrestling with this exact problem now. I'm toying with the idea of
maintaining *two* piece table variables, one for the opening/middlegame and
one for the endgame. These variables would get updated incrementally in the
make/unmake move functions and averaged in the final evaluation.
I'm not sure yet if it's worth it, since it may become too unwieldy. One
potential trouble spot is the scoring of the king's location. Djinn uses
different piece king tables in the endgame, depending on the locations of the
pawns.
then the piece tables encourage the king to move towards the queenside, (and
of course the converse is true for the kingside).
My proposed solution for this is to hash the information about which table to
use in the pawn hash table. And while this works for this problem, there are
others that are not so easily solved.
regards,
--tom

I use only one piece square table in the endgame.
I have other tables to encourage the king to be in the right place relative to the pawns but I do not call them piece square table and they are only addition to the main piece square tables because they do not give constant score to squares.
I have for example score to encourage the king to be in the file of the pawns and if the king is in the right side relative to all the pawns or in the left side relative to all the pawns then there is some table to decide how much to punish it based on the distance in files to the closest pawn(today I do not punish it in case that the distance is 1 file and I start to punish only when the distance is at least 2 files).
I do not know if punishing it when the distance is one file is productive and I did not test it.
For example, if all the pawns (for both sides) are on the queenside
I know that something similiar is used in free source code(if I remember correctly in Crafty) but I did not like it because a,b,c pawns are not the same as b,c,d pawns and I also think that in case of a,b,c files the c file is better than the a file because you can go from it to the d file when you cannot go from the a file to a-1 file so I decided always to encourage centralization of the king.

I am more interested in improvement in other ways than hash tables and I have no pawn hash tables in movei.
Uri

[Tom Likens]

Geschrieben von:/Posted by: Tom Likens at 23 July 2004 17:30:08:
Als Antwort auf:/In reply to: Re: AEGT : list of participants, with version numbers geschrieben von:/posted by: Uri Blass at 23 July 2004 17:13:39:

Yes, speed ! I spend all my time wondering how others do it .

So do I. In Gothmog, I always blamed the miserably low nodes/second count
on my complicated evaluation function. After working for some time on Gothmog's
successor, I am no longer so sure. My board representation and data structures
look good, and the code is simple, straightforward, and with no obvious
inefficiencies which I can see. The evaluation currently consists of material
and piece square tables only, and the score is incrementally updated when moves
are made/unmade.
This sounds like a speed monster, but it isn't. On my PIV 2.4 GHz, the
nodes/second count is comparable to Crafty's. Not very impressive for a
program with only incremental eval. I wonder what I am doing wrong.
Tord

Maybe Crafty is using superior compiler.
Did You try to use the same compiler that you use for gothmog for Crafty
and compare the speed of Gothmog with Crafty?
Another question is if you count nodes the same as Crafty.
As far as I know crafty includes also illegal moves as part of it's nodes.
In the case of movei I never expected to have the same speed as Crafty because my makemove update information about the attacked squares and as far as I know Crafty has not this information.
I am happy enough with the fact that movei has similiar speed to some commercial programs like Shredder or Hiarcs and I believe that no speed improvement is needed in order to be stronger then them(only better algorithm).
Latest version also does not do incremental update of piece square tables.
The problem is that there are different piece square table for opening and
endgame and I decided that it is better to lose some speed and do the code more simpler in order not to have bugs(it only costed me something like being 5% slower in nodes per second and the improvement that I did later in evaluating transition from opening to endgame based on some average between opening king table and endgame king table in similiar way to fruit is probably more than it).
Uri

Hello Uri,
I'm wrestling with this exact problem now. I'm toying with the idea of
maintaining *two* piece table variables, one for the opening/middlegame and
one for the endgame. These variables would get updated incrementally in the
make/unmake move functions and averaged in the final evaluation.
I'm not sure yet if it's worth it, since it may become too unwieldy. One
potential trouble spot is the scoring of the king's location. Djinn uses
different piece king tables in the endgame, depending on the locations of the
pawns.
then the piece tables encourage the king to move towards the queenside, (and
of course the converse is true for the kingside).
My proposed solution for this is to hash the information about which table to
use in the pawn hash table. And while this works for this problem, there are
others that are not so easily solved.
regards,
--tom

I use only one piece square table in the endgame.
I have other tables to encourage the king to be in the right place relative to the pawns but I do not call them piece square table and they are only addition to the main piece square tables because they do not give constant score to squares.
I have for example score to encourage the king to be in the file of the pawns and if the king is in the right side relative to all the pawns or in the left side relative to all the pawns then there is some table to decide how much to punish it based on the distance in files to the closest pawn(today I do not punish it in case that the distance is 1 file and I start to punish only when the distance is at least 2 files).
I do not know if punishing it when the distance is one file is productive and I did not test it.
For example, if all the pawns (for both sides) are on the queenside
I know that something similiar is used in free source code(if I remember correctly in Crafty) but I did not like it because a,b,c pawns are not the same as b,c,d pawns and I also think that in case of a,b,c files the c file is better than the a file because you can go from it to the d file when you cannot go from the a file to a-1 file so I decided always to encourage centralization of the king.
I am more interested in improvement in other ways than hash tables and I have no pawn hash tables in movei.
Uri

If memory serves me correctly, I implemented these tables after a CCC post by
Jon Dart of Arasan fame. Of course, it's very possible that he got the idea
from Crafty. I haven't actually looked at Crafty's code in a long time, but
probably should since I'm sure Bob has implemented a number of good ideas.
In a lot of ways, Djinn has been drifting further and further from the way
Bob has built Crafty. I think Tord's ideas have had the biggest influence
on me recently, with perhaps a bit of Christophe Theron and Sergei Markoff
thrown in for good measure.
I find that interesting. Have you tried them in the past and determined they
weren't advantegeous? I'm surprised, because they gave my engine a substantial
speed boost. The hit rate is very high (~98-99%), which means that the pawn
evaluation can be very substantial (i.e. slow) without being too detrimental
to the overall NPS.
--tom

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 23 July 2004 17:44:44:
Als Antwort auf:/In reply to: Re: AEGT : list of participants, with version numbers geschrieben von:/posted by: Tom Likens at 23 July 2004 17:30:08:

Yes, speed ! I spend all my time wondering how others do it .

So do I. In Gothmog, I always blamed the miserably low nodes/second count
on my complicated evaluation function. After working for some time on Gothmog's
successor, I am no longer so sure. My board representation and data structures
look good, and the code is simple, straightforward, and with no obvious
inefficiencies which I can see. The evaluation currently consists of material
and piece square tables only, and the score is incrementally updated when moves
are made/unmade.
This sounds like a speed monster, but it isn't. On my PIV 2.4 GHz, the
nodes/second count is comparable to Crafty's. Not very impressive for a
program with only incremental eval. I wonder what I am doing wrong.
Tord

Maybe Crafty is using superior compiler.
Did You try to use the same compiler that you use for gothmog for Crafty
and compare the speed of Gothmog with Crafty?
Another question is if you count nodes the same as Crafty.
As far as I know crafty includes also illegal moves as part of it's nodes.
In the case of movei I never expected to have the same speed as Crafty because my makemove update information about the attacked squares and as far as I know Crafty has not this information.
I am happy enough with the fact that movei has similiar speed to some commercial programs like Shredder or Hiarcs and I believe that no speed improvement is needed in order to be stronger then them(only better algorithm).
Latest version also does not do incremental update of piece square tables.
The problem is that there are different piece square table for opening and
endgame and I decided that it is better to lose some speed and do the code more simpler in order not to have bugs(it only costed me something like being 5% slower in nodes per second and the improvement that I did later in evaluating transition from opening to endgame based on some average between opening king table and endgame king table in similiar way to fruit is probably more than it).
Uri

Hello Uri,
I'm wrestling with this exact problem now. I'm toying with the idea of
maintaining *two* piece table variables, one for the opening/middlegame and
one for the endgame. These variables would get updated incrementally in the
make/unmake move functions and averaged in the final evaluation.
I'm not sure yet if it's worth it, since it may become too unwieldy. One
potential trouble spot is the scoring of the king's location. Djinn uses
different piece king tables in the endgame, depending on the locations of the
pawns.
then the piece tables encourage the king to move towards the queenside, (and
of course the converse is true for the kingside).
My proposed solution for this is to hash the information about which table to
use in the pawn hash table. And while this works for this problem, there are
others that are not so easily solved.
regards,
--tom

I use only one piece square table in the endgame.
I have other tables to encourage the king to be in the right place relative to the pawns but I do not call them piece square table and they are only addition to the main piece square tables because they do not give constant score to squares.
I have for example score to encourage the king to be in the file of the pawns and if the king is in the right side relative to all the pawns or in the left side relative to all the pawns then there is some table to decide how much to punish it based on the distance in files to the closest pawn(today I do not punish it in case that the distance is 1 file and I start to punish only when the distance is at least 2 files).
I do not know if punishing it when the distance is one file is productive and I did not test it.
For example, if all the pawns (for both sides) are on the queenside
I know that something similiar is used in free source code(if I remember correctly in Crafty) but I did not like it because a,b,c pawns are not the same as b,c,d pawns and I also think that in case of a,b,c files the c file is better than the a file because you can go from it to the d file when you cannot go from the a file to a-1 file so I decided always to encourage centralization of the king.
I am more interested in improvement in other ways than hash tables and I have no pawn hash tables in movei.
Uri

If memory serves me correctly, I implemented these tables after a CCC post by
Jon Dart of Arasan fame. Of course, it's very possible that he got the idea
from Crafty. I haven't actually looked at Crafty's code in a long time, but
probably should since I'm sure Bob has implemented a number of good ideas.
In a lot of ways, Djinn has been drifting further and further from the way
Bob has built Crafty. I think Tord's ideas have had the biggest influence
on me recently, with perhaps a bit of Christophe Theron and Sergei Markoff
thrown in for good measure.
I find that interesting. Have you tried them in the past and determined they
weren't advantegeous? I'm surprised, because they gave my engine a substantial
speed boost. The hit rate is very high (~98-99%), which means that the pawn
evaluation can be very substantial (i.e. slow) without being too detrimental
to the overall NPS.
--tom

Yes
I tried in the past to hash pawn information and found that there was no significant improvement relative to calculating it based on bitboards.
I did not try to hash scores.
Today I use only the number of isolated pawns to evaluate isolated pawns but I consider to test improvement of this evaluation and I do not like the idea to hash scores only later to undo it when I change my evaluation.
I evaluate passed pawns also based on the question if they are blocked and here hashing scores cannot help because the evaluation is not dependent only on pawn structure.
Uri

[Olivier Deville]

Geschrieben von:/Posted by: Olivier Deville at 23 July 2004 18:10:42:
Als Antwort auf:/In reply to: draft geschrieben von:/posted by: Igor Gorelikov at 23 July 2004 17:00:23:

To help Heinz and all of us I compile/squeeze/exract a draft of AEGT regulation and upload it to my site (your list is also added to it).
http://www.digichess.gr/infiniteloop/etc/AEGT_draft.txt
I will try to keep it as short as possible but include all our decisions and proposals.
Igor

ChessWar

[Olivier Deville]

Geschrieben von:/Posted by: Olivier Deville at 23 July 2004 18:11:29:
Als Antwort auf:/In reply to: Re: draft geschrieben von:/posted by: Olivier Deville at 23 July 2004 18:10:42:




ChessWar

[Olivier Deville]

Geschrieben von:/Posted by: Olivier Deville at 23 July 2004 18:15:21:
Als Antwort auf:/In reply to: Quark ? geschrieben von:/posted by: Martin Baumung at 23 July 2004 16:48:01:

Hi all,
is Quark 2.35 available? IIRC that's the version that played in Paderborn!
Regards,
Martin

Hello Martin
Thomas Mayer doesn't mind if we give the download link for Quark 2.35 :
http://www.quarkchess.de/quark/Quark235.zip
And the book is here :
http://www.quarkchess.de/quark/QuarkLeoN5.zip
Enjoy !
Olivier


ChessWar

[Tord Romstad]

Geschrieben von:/Posted by: Tord Romstad at 23 July 2004 20:50:09:
Als Antwort auf:/In reply to: Re: AEGT : list of participants, with version numbers geschrieben von:/posted by: Fabien Letouzey at 23 July 2004 15:14:26:

Don't forget that Crafty uses lazy evaluation. I suspect on average the speed of the whole program is not so far away from one with incremental evaluation.
Fruit 1.0 is clearly slower than Crafty and is not doing much either (some stuff like ETC at depth>=4, 4-probe HT and fail-high null move slow down here and there, NPS-wise that is).
I would say getting the speed of Crafty is good! Now you can start adding your magic code to evaluate twice as good and twice as deep
Don't worry and move forward

Thanks to you and everybody else for the encouragement and the interesting
discussion!
Actually I don't worry very much. Unrolling some loops in the static
exchange evaluator gave a big speedup in my new hexagonal chess engine, and I
expect the same change to be equally effective in the twin engine for normal
chess. The hexagonal program now searches 500 kN/s with an eval containing pawn
structure, mobility and some rudimentary king safety in addition to material and
piece square tables.
Tord

[Martin Baumung]

Geschrieben von:/Posted by: Martin Baumung at 24 July 2004 08:02:27:
Als Antwort auf:/In reply to: Re: Quark ? geschrieben von:/posted by: Olivier Deville at 23 July 2004 18:15:21:

Hi all,
is Quark 2.35 available? IIRC that's the version that played in Paderborn!
Regards,
Martin

Hello Martin
Thomas Mayer doesn't mind if we give the download link for Quark 2.35 :
http://www.quarkchess.de/quark/Quark235.zip
And the book is here :
http://www.quarkchess.de/quark/QuarkLeoN5.zip
Enjoy !
Olivier

[Norm Pollock]

Geschrieben von:/Posted by: Norm Pollock at 24 July 2004 15:19:23:
Als Antwort auf:/In reply to: Re: Quark ? geschrieben von:/posted by: Olivier Deville at 23 July 2004 18:15:21:

Hi all,
is Quark 2.35 available? IIRC that's the version that played in Paderborn!
Regards,
Martin

Hello Martin
Thomas Mayer doesn't mind if we give the download link for Quark 2.35 :
http://www.quarkchess.de/quark/Quark235.zip
And the book is here :
http://www.quarkchess.de/quark/QuarkLeoN5.zip
Enjoy !
Olivier

I noticed a time management problem when Quark235 is used in the fritz8 gui under fischer time. (I used 4 min + 2 sec.) If Quark gets into a drawish ending with about 8 pieces on the board, Quark may lose on time. Quark uses more than the incremental time per move (2 sec per move) so its reserve time dwindles down. Maybe it's also the fault of the fritz8 gui for wiping out the hash of the previous move, or the time lag to access tablebases, or something else. But Quark should not get that close to zero time in the first place.

[Olivier Deville]

Geschrieben von:/Posted by: Olivier Deville at 24 July 2004 15:42:05:
Als Antwort auf:/In reply to: Re: Quark ? geschrieben von:/posted by: Norm Pollock at 24 July 2004 15:19:23:

Hi all,
is Quark 2.35 available? IIRC that's the version that played in Paderborn!
Regards,
Martin

Hello Martin
Thomas Mayer doesn't mind if we give the download link for Quark 2.35 :
http://www.quarkchess.de/quark/Quark235.zip
And the book is here :
http://www.quarkchess.de/quark/QuarkLeoN5.zip
Enjoy !
Olivier

I noticed a time management problem when Quark235 is used in the fritz8 gui under fischer time. (I used 4 min + 2 sec.) If Quark gets into a drawish ending with about 8 pieces on the board, Quark may lose on time. Quark uses more than the incremental time per move (2 sec per move) so its reserve time dwindles down. Maybe it's also the fault of the fritz8 gui for wiping out the hash of the previous move, or the time lag to access tablebases, or something else. But Quark should not get that close to zero time in the first place.

Hi Norm
I would say (just my guess) that time lag to access tablebases may be the explanation. I had no time to test seriously Quark 2.35, and did not notice this behaviour until now.
Let's say that the bug you describe in the Fritz GUI (the GUI wiping out the hash at each move) is no longer extant : this was a bug of the old ChessBase adaptor. Wb2Uci never had such a bug.
Olivier


ChessWar

[Norm Pollock]

Geschrieben von:/Posted by: Norm Pollock at 24 July 2004 16:02:27:
Als Antwort auf:/In reply to: Re: Quark ? (slightly OT) geschrieben von:/posted by: Olivier Deville at 24 July 2004 15:42:05:

Hi all,
is Quark 2.35 available? IIRC that's the version that played in Paderborn!
Regards,
Martin

Hello Martin
Thomas Mayer doesn't mind if we give the download link for Quark 2.35 :
http://www.quarkchess.de/quark/Quark235.zip
And the book is here :
http://www.quarkchess.de/quark/QuarkLeoN5.zip
Enjoy !
Olivier

I noticed a time management problem when Quark235 is used in the fritz8 gui under fischer time. (I used 4 min + 2 sec.) If Quark gets into a drawish ending with about 8 pieces on the board, Quark may lose on time. Quark uses more than the incremental time per move (2 sec per move) so its reserve time dwindles down. Maybe it's also the fault of the fritz8 gui for wiping out the hash of the previous move, or the time lag to access tablebases, or something else. But Quark should not get that close to zero time in the first place.

Hi Norm
I would say (just my guess) that time lag to access tablebases may be the explanation. I had no time to test seriously Quark 2.35, and did not notice this behaviour until now.
Let's say that the bug you describe in the Fritz GUI (the GUI wiping out the hash at each move) is no longer extant : this was a bug of the old ChessBase adaptor. Wb2Uci never had such a bug.
Olivier

Hi Oliver-
I agree. It could be the tablebase access time. Btw, I defragmented the drive partition where the tablebases are located. Every little microsecond helps. But still, Quark lives on the edge of time expiration.
-Norm

[Heinz van Kempen]

Geschrieben von:/Posted by: Heinz van Kempen at 24 July 2004 16:30:47:
Als Antwort auf:/In reply to: Re: Quark ? geschrieben von:/posted by: Norm Pollock at 24 July 2004 15:19:23:

Hi all,
is Quark 2.35 available? IIRC that's the version that played in Paderborn!
Regards,
Martin

Hello Martin
Thomas Mayer doesn't mind if we give the download link for Quark 2.35 :
http://www.quarkchess.de/quark/Quark235.zip
And the book is here :
http://www.quarkchess.de/quark/QuarkLeoN5.zip
Enjoy !
Olivier

I noticed a time management problem when Quark235 is used in the fritz8 gui under fischer time. (I used 4 min + 2 sec.) If Quark gets into a drawish ending with about 8 pieces on the board, Quark may lose on time. Quark uses more than the incremental time per move (2 sec per move) so its reserve time dwindles down. Maybe it's also the fault of the fritz8 gui for wiping out the hash of the previous move, or the time lag to access tablebases, or something else. But Quark should not get that close to zero time in the first place.

Hi Norm,
I used Quark 2.35 in my Nunn tournaments with also 4+2 and 5 men EGTB under Fritz GUI, but do not remember any losses on time.
I had time exceeds with an older beta 1.76b, but not with Fischer clock. I think it was either total time per game or 40 moves in x.
Best Regards
Heinz

[Günther Simon]

Geschrieben von:/Posted by: Günther Simon at 24 July 2004 17:47:33:
Als Antwort auf:/In reply to: Re: Quark ? (slightly OT) geschrieben von:/posted by: Olivier Deville at 24 July 2004 15:42:05:

Hi all,
is Quark 2.35 available? IIRC that's the version that played in Paderborn!
Regards,
Martin

Hello Martin
Thomas Mayer doesn't mind if we give the download link for Quark 2.35 :
http://www.quarkchess.de/quark/Quark235.zip
And the book is here :
http://www.quarkchess.de/quark/QuarkLeoN5.zip
Enjoy !
Olivier

I noticed a time management problem when Quark235 is used in the fritz8 gui under fischer time. (I used 4 min + 2 sec.) If Quark gets into a drawish ending with about 8 pieces on the board, Quark may lose on time. Quark uses more than the incremental time per move (2 sec per move) so its reserve time dwindles down. Maybe it's also the fault of the fritz8 gui for wiping out the hash of the previous move, or the time lag to access tablebases, or something else. But Quark should not get that close to zero time in the first place.

Hi Norm
I would say (just my guess) that time lag to access tablebases may be the explanation. I had no time to test seriously Quark 2.35, and did not notice this behaviour until now.
Let's say that the bug you describe in the Fritz GUI (the GUI wiping out the hash at each move) is no longer extant : this was a bug of the old ChessBase adaptor. Wb2Uci never had such a bug.
Olivier

Sorry to disagree Olivier, but IIRC there was a recent discussion
in CCC, where Mike Byrne could prove that WB2UCI unfortunately
has exactly the same behaviour, as old crappy WB adapters.
Mike showed logs from the WB2UCI adapter with a 'new' command
before _every_ move. He said that Fritz seems to send a command which
the adapter translates into a 'new'...
Best,
Guenther

[Thomas Mayer]

Geschrieben von:/Posted by: Thomas Mayer at 25 July 2004 00:16:32:
Als Antwort auf:/In reply to: Re: Quark ? geschrieben von:/posted by: Norm Pollock at 24 July 2004 15:19:23:

Hi Norm,
well, I do not have much experience with Quark in Fritz GUI, and when I use it I play with ponder=on... In Ponder=on games I recommand LevelExtend=FailSafe because else it loses on time sometimes. The bad effect is, that from time to time it gets a "new" through the wb2uci adapter which harms it's strength a bit... but better to have a new from time to time then losing on time...
If you want, you can sent me a logfile of Quark of a game where it does lose on time, I would be interested in it... -> I am quite sure that it is not a problem of Quark itself, because with WinBoard I have not seen it losing on time for ages... at least not with increments...
Greets, Thomas
P.S.: This version has played several thousand games at various testers, but of course it's still possible that it has some problems...
PPS.: I would also like to have some information about your hardware... It is possible that it has some problems with very slow hardware...