Yace 015 vs Lg 2.8 A blowout !

[Paul Bedrey]

Geschrieben von: / Posted by: Paul Bedrey at 14 July 2000 00:59:02:
I've heard that lgoliath has Yace's number but I'm surprised at this result.
Yace 015 4
Lgoliath 14
2 Draws

Pentium 400
no-ponder
40m in 60'
I'm tempted to replay this again. Yace has always been competive with the other
top ten programs. Is there that much difference between 15 and Yace 21? I haven't analyzed games yet but it looks like the the very aggressiveness I like
in Yace makes it easy pickings for Lgoliath.

[Dann Corbit]

Geschrieben von: / Posted by: Dann Corbit at 14 July 2000 01:17:01:
Als Antwort auf: / As an answer to: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Paul Bedrey at 14 July 2000 00:59:02:

I've heard that lgoliath has Yace's number but I'm surprised at this result.
Yace 015 4
Lgoliath 14
2 Draws

Pentium 400
no-ponder
40m in 60'
I'm tempted to replay this again. Yace has always been competive with the other
top ten programs. Is there that much difference between 15 and Yace 21?
I haven't analyzed games yet but it looks like the the very aggressiveness I like
in Yace makes it easy pickings for Lgoliath.

Version 0.20 29.06.2000
Added table bases, new (Nalimov) format, compressed or uncompressed.
Thanks to Andrew Kadatch for permisson, to use the compression code,
and of course to Eugene Nalimov. With his source and documentation,
it was much easier, than I thought. Also thanks to Mogens Chr. Larson,
Volker Pittlik and Christian Goralsiki, for testing this.
Add a line like
tbldir e:\egtb
to yace.ini. Yace will use 2 Mb of cache for the table bases (should be
adjustable soon).
Yet another try for to fix the buffer overflow of winboard. The
fix advertized for 0.18 was wrong. Now, Yace will post much less
to winboard. The left out parts will be in the yace log.
Got rid of the null_threat command. This is redundant with "inullthreat".
Was never documented, so no problem.
Got rid of some short cuts for hash table hits, when the score was mate.
This worked well, when all the mates were searched, but now, we get some
mates for free from the EGTB tables. Hope, this won't hurt too much.
New KPK evaluation code. Thanks to Dann Corbit for reporting the bug.
Don't post stupid PV's with repeated null moves from the hash table anymore.
Got rid of a small speed enhancement in search, that only speeded up test
positions a tiny little bit and slowed down real games a tiny little bit.
Added rem and ; commands to allow commenting the ini file. Comments must be
on their own lines like
rem This is a comment
; and this also.
REM You can indent comments.
ReM As with all yace commands, rem is case insensitive.
; Due to my lazyness, there must be at least one space character
; after the semicolon.
hash=10M ; This is *not* allowed.
Got rid of an old bug, where Yace sometimes started to think after a
setboard command.
Added a pointer to Mogens Larsen's site for book downloading.
Suggesting to use hash 0 before book creation, to save memory.
Print the version number into test.sum.
Fixed a stupid bug, where Yace could castle through check, when the
checking piece was a pawn. Thanks to Dan Andersson for reporting this
and providing a reproducable test case.
Version 0.18 20.06.2000
Fractional extensions.
New commands icheck, irepcheck, irecapture, ipawn7, inullthreat.
defaults: 1.0 0.59 0.59 1.0 1.0
See readme.txt under fractional extensions. This change slightly
slows down the search engine. (In Yace 0.17 and earlier, all the
defaults would have been 1.0)
No experience, if this helps in real games yet.
The null command no accepts a floating point value. (So you can write
null=2.5).
Winboard very rarely crashed, when Yace posted a long line at the end
of the search -> in xboard_mode truncate the line.
Ignore SIGTERM for xboard compability.
Penalize moving the king from the base line in early game.
Minor hash table changes and speed-ups.
Version 0.17 16.06.2000
Small addition to readme.txt
Fixed bug in Position editing. (Castling rights might have been wrong.)
Accept the name of the ini file as a command line option. This
makes testing of tuning parameters easier. So you can call
yace yacetest.ini
To make logging work, both instances must write to a different logfile.
No other command line options are accepted. When no command line
option is given, yace.ini will be used.
Fixed timing bug on some Windows system. Thanks to Volker Pittlik
for finding this, and his help with debugging.
Added loga command. (Append to logfile)
Suggesting to use loga yace.log in yace.ini (Formerly, log yace.ini
was suggested.)
While doing this found a bug in the log command. When a second log
command was given, the old file wasn't closed. (Would be closed
at program end anyway, but this way, one could run out of file
descriptors)
Added rmoves and rscore commands. When Yace detects rmoves moves
with a score smaller than rscore, it will resign. Allowed values
for rmoves are 3 = -20. rscore
can be a floatimg point value (I.e. rscore=-6.8). To let Yace resign
soon, put the following lines into yace.ini:
resign om
rmoves 3
rscore -6
Still, Yace will not resign by default. The (new) default for rscore is -8.0
and for rmoves 4. Thanks to Mogens Larsen for his suggestion.
Version 0.16 14.06.2000
(Hopefully) found the repetition bug. (Thanks to Gabor Szots for posting
the FIDE rules.) I thought the position must be repeated 3 times (vs.
occure for the third time)
Flip a penny 10 times. Count the heads and tails. A result of 2-8 would not be terribly remarkable. See how repeatable that experiment is. Are you sure you have Yace configured correctly?


my ftp site

[Mogens Larsen]

Geschrieben von: / Posted by: Mogens Larsen at 14 July 2000 01:40:48:
Als Antwort auf: / As an answer to: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Paul Bedrey at 14 July 2000 00:59:02:

I've heard that lgoliath has Yace's number but I'm surprised at this result.
Yace 015 4
Lgoliath 14
2 Draws

Pentium 400
no-ponder
40m in 60'
I'm tempted to replay this again. Yace has always been competive with the other
top ten programs. Is there that much difference between 15 and Yace 21? I haven't analyzed games yet but it looks like the the very aggressiveness I like
in Yace makes it easy pickings for Lgoliath.

Judging from the number of changes made to Yace the last month or so, it would be safe to say that it's adviseable to use the newest version. The older versions appeared to be best at blitz, while the newer versions seem more flexible. Try repeating the test with either 0.20 or 0.21 and tell us what results you achieve.
Best wishes...
Mogens

[Dieter Buerssner]

Geschrieben von: / Posted by: Dieter Buerssner at 14 July 2000 11:02:39:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Mogens Larsen at 14 July 2000 01:40:48:
So many nice results in such a short time

Judging from the number of changes made to Yace the last month or so, it
would be safe to say that it's adviseable to use the newest version. The
older versions appeared to be best at blitz ...

Interesting remark. I thought, I have not changed the strength of
Yace much (besides the table bases, which really should help). You can
get an almost original Yace (before it had a version number) by putting
the following lines into yace.ini
irepcheck 1
irecapture 1
null_e 3
pval 0.67
The current defaults for these numbers is 0.59 0.59 2 1.
Perhaps changing the numbers did hurt the performance. I didn't test
it much.
BTW. Don't change icheck. A number smaller 1 would introduce
some strange effects.
Regards,
Dieter

[Aaron]

Geschrieben von: / Posted by: Aaron at 14 July 2000 11:29:21:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Dieter Buerssner at 14 July 2000 11:02:39:

So many nice results in such a short time

Judging from the number of changes made to Yace the last month or so, it
would be safe to say that it's adviseable to use the newest version. The
older versions appeared to be best at blitz ...

Interesting remark. I thought, I have not changed the strength of
Yace much (besides the table bases, which really should help). You can
get an almost original Yace (before it had a version number) by putting
the following lines into yace.ini
irepcheck 1
irecapture 1
null_e 3
pval 0.67
The current defaults for these numbers is 0.59 0.59 2 1.

Isn't the lastest Yace21 using new piece values as well? I'm not convinced either way if it's better or worse than the orginaL.

Another question
regarding ipawn7, you state in the readme file tha default is 1. But apparantly when i check the variable by typing ipawn 7 ,the value returned is 0?

[Paul Bedrey]

Geschrieben von: / Posted by: Paul Bedrey at 14 July 2000 13:01:35:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Dann Corbit at 14 July 2000 01:17:01:

Flip a penny 10 times. Count the heads and tails. A result of 2-8 would not be terribly remarkable. See how repeatable that experiment is. Are you sure you have Yace configured correctly?

So far I've flipped the penny 160+ times and Yace has scored 44 %. This
is against the other top ten winboard engines. I'll try version 21 but
I doubt it will change anything. I still think it is a question of style.
The one game I examined in Rebel showed that Yace made a mistake by pushing
its pawn to open the position but it left its queen open to attack. I'm gone
this weekend so I won't be able to look at the other 19 until next week.
I'm not complaining though Yace is still my favorite. I am thinking of creating
a book of "strange openings" (stonewall, gambits, bird,colle) anything that
opens up the position. I think Yace might be a holy terror against a human
opponent.

[Dieter Buerssner]

Geschrieben von: / Posted by: Dieter Buerssner at 14 July 2000 21:10:28:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Aaron at 14 July 2000 11:29:21:

Isn't the lastest Yace21 using new piece values as well? I'm not
convinced either way if it's better or worse than the orginaL.
regarding ipawn7, you state in the readme file tha default is 1. But
apparantly when i check the variable by typing ipawn 7 ,the value
returned is 0?

No, in the last minute I made the new piece values optional. I
think they make everything worse. Probably the only method,
to avoid bad trades, like 3P vs B or R+2P vs B+N is to write
code for it. Of course, I'd be interested in other suggestions.
And I will think about Dan Anderssons's suggestion in an other threat,
although, if I understand correctly, it cannot handle both of the
above cases.
You cannot check the value of a parameter by typing its name.
Just type
param
and you will get an overview of the current values of the most important
(and some very obscure and unimportant) parameters.
Regards,
Dieter

[Dan Andersson]

Geschrieben von: / Posted by: Dan Andersson at 15 July 2000 00:26:42:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Dieter Buerssner at 14 July 2000 21:10:28:

Isn't the lastest Yace21 using new piece values as well? I'm not
convinced either way if it's better or worse than the orginaL.

No, in the last minute I made the new piece values optional. I
think they make everything worse. Probably the only method,
to avoid bad trades, like 3P vs B or R+2P vs B+N is to write
code for it. Of course, I'd be interested in other suggestions.
And I will think about Dan Anderssons's suggestion in an other threat,
although, if I understand correctly, it cannot handle both of the
above cases.

If you want to fix that you could make an array lookup:
piecesVsPawns[deltaNOPieces][deltaNOPawns],
this hashes piece/pawn data. There will be some collisions of course. The full array is [-5..5][-8..8] but one can get away with a smaller array if necessary (even make a discrete function). This is compatible with coding special cases. For each special case you only have to subtract the piecesVsPawns value. piecesVsPawns could even have the dimension gameStage:
[root,earlyOpening..lateOpening,openingToMidgameTransition,earlyMidgame..,,EGTB]
to take into account the shift in pawn and knight values. I have about two hundred other ideas about this topic. I do feel it imperative to have a function that promotes pieces over pawns in general. Then code special cases separately.

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 15 July 2000 06:57:05:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Dieter Buerssner at 14 July 2000 21:10:28:

Isn't the lastest Yace21 using new piece values as well? I'm not
convinced either way if it's better or worse than the orginaL.

No, in the last minute I made the new piece values optional. I
think they make everything worse. Probably the only method,
to avoid bad trades, like 3P vs B or R+2P vs B+N is to write
code for it.

Another method is simply to reduce the value of the pawn without changing the value of other pieces.
I know that one of the changes in Junior(Junior6 realtive to Junior5) is that the value of the pawn was reduced.
I guess that for Junior it is productive in playing but counter productive in test position because in test positions sacrifing a piece for pawns is more common than sacrificing a pawn.
Uri

[Aaron]

Geschrieben von: / Posted by: Aaron at 15 July 2000 13:34:14:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Dieter Buerssner at 14 July 2000 11:02:39:

So many nice results in such a short time

Judging from the number of changes made to Yace the last month or so, it
would be safe to say that it's adviseable to use the newest version. The
older versions appeared to be best at blitz ...

Interesting remark. I thought, I have not changed the strength of
Yace much (besides the table bases, which really should help). You can
get an almost original Yace (before it had a version number) by putting
the following lines into yace.ini
irepcheck 1
irecapture 1
null_e 3
pval 0.67
The current defaults for these numbers is 0.59 0.59 2 1.
Perhaps changing the numbers did hurt the performance. I didn't test
it much.
BTW. Don't change icheck. A number smaller 1 would introduce
some strange effects.

Are you going to make null_high 4 that you recommended as default for the next version of Yace? It's definitely (as definite as you can tell from "tossing coins" as Dann likes to say) plays better against Crafty..
But the problem of course is that it might be weaker against the rest, but i doubt that..

[Dieter Buerssner]

Geschrieben von: / Posted by: Dieter Buerssner at 15 July 2000 16:02:33:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Dan Andersson at 15 July 2000 00:26:42:
If this technical discussion is not appropriate for this forum,
I'll stop.
Dan, thanks for your answer.

... Probably the only method,
to avoid bad trades, like 3P vs B or R+2P vs B+N is to write
code for it. Of course, I'd be interested in other suggestions.
And I will think about Dan Anderssons's suggestion in an other threat,
although, if I understand correctly, it cannot handle both of the
above cases.

If you want to fix that you could make an array lookup:
piecesVsPawns[deltaNOPieces][deltaNOPawns],
this hashes piece/pawn data. There will be some collisions of course.
The full array is [-5..5][-8..8] but one can get away with a smaller
array if necessary (even make a discrete function).
I have about two hundred other ideas about this topic.

First a stupid language related question. With pieces, you don't
include pawns, right?
Then I think the dimension should be [-7..7][-8..8] (and as
you noted, a third dimension, gameStage would be approppriate).
Would you like to suggest some numbers for the most important
cases say, for early middle game. (I use B to mean B or N, also add
any number of pawns, like I indicated in the first line) say, for early middle game.
B +nP vs R
R vs 2B
3B vs Q
2R vs Q
R+B vs Q
Did I miss something?
Obviously, only the almost equal cases are interesting, otherwise
the game will be over anyway.
Please share your ideas I have the feeling that at least one forth
of the losses of Yace against Crafty, is because of bad trades.
(Other losses, or lost wins, I wouldn't recognize, because the
bad trades are the not recognized refutation of some line)
Regards,
Dieter

[Dieter Buerssner]

Geschrieben von: / Posted by: Dieter Buerssner at 15 July 2000 16:09:32:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Uri Blass at 15 July 2000 06:57:05:

... Probably the only method,
to avoid bad trades, like 3P vs B or R+2P vs B+N is to write
code for it.

Another method is simply to reduce the value of the pawn without changing the value of other pieces.

I tried various experiments with piece values - all failed
What usually happens against Crafty is the following. Both show even score.
Yace sees a stupid trade R+2P against B+N. Score for Yace rises to +0.7,
score for Crafty rises to +0.5 - game over for Yace About ten
moves later Yace will loose a pawn, another ten moves later, it will loose
another pawn.
So with your suggestion, the pawn value should be (if I trust Crafty's
evaluation) 0.4. I think, this won't work.
Regards,
Dieter

[Dieter Buerssner]

Geschrieben von: / Posted by: Dieter Buerssner at 15 July 2000 16:12:22:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Aaron at 15 July 2000 13:34:14:

Are you going to make null_high 4 that you recommended as default for the next version of Yace? It's definitely (as definite as you can tell from "tossing coins" as Dann likes to say) plays better against Crafty..

I'll wait a little bit, and try against different programs. Unfortunately,
the testing takes a lot of time. I invite everybody to try out null_high 4.
Regards,
Dieter

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 15 July 2000 18:44:42:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Dieter Buerssner at 15 July 2000 16:09:32:

... Probably the only method,
to avoid bad trades, like 3P vs B or R+2P vs B+N is to write
code for it.

Another method is simply to reduce the value of the pawn without changing the value of other pieces.

I tried various experiments with piece values - all failed
What usually happens against Crafty is the following. Both show even score.
Yace sees a stupid trade R+2P against B+N. Score for Yace rises to +0.7,
score for Crafty rises to +0.5 - game over for Yace About ten
moves later Yace will loose a pawn, another ten moves later, it will loose
another pawn.
So with your suggestion, the pawn value should be (if I trust Crafty's
evaluation) 0.4. I think, this won't work.
Regards,
Dieter

I guess that in this case you need also to increase the value of bishops and knights.
You can get -0.1 instead of +0.7 for R+2P vs B+N if you increase bishops and knights values by 0.2 and reduce pawn value by 0.2.
It is not enough to get the evaluation of crafty but I guess that it is enough to avoid most of the bad trades.
Uri

[Dan Andersson]

Geschrieben von: / Posted by: Dan Andersson at 15 July 2000 19:10:21:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Dieter Buerssner at 15 July 2000 16:02:33:

First a stupid language related question. With pieces, you don't
include pawns, right?
Then I think the dimension should be [-7..7][-8..8] (and as
you noted, a third dimension, gameStage would be appropriate).

Right!
Yes, I accidentally misused the range of piece types. I use that in my endgame experiments.
These values should be tweaked to fit in with positional scores.
B +nP vs R minus two and a half pawns
R vs 2B minus two pawns maybe more
3B vs Q plus one and a half pawn
2R vs Q plus half a pawn other bonuses should dominate
R+B vs Q minus two pawns maybe more
new permutations
R+2B vs Q +nPawn plus three pawns
2B vs Q a very special case, in general a clear plus for the queen but not if there is
a) an attack
b) the opposing side is severely restricted or
c) a piece is out of play for the opponent.
its safest if all three conditions are met.

[Dieter Buerssner]

Geschrieben von: / Posted by: Dieter Buerssner at 16 July 2000 20:18:40:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Dan Andersson at 15 July 2000 19:10:21:

These values should be tweaked to fit in with positional scores.
B +nP vs R minus two and a half pawns
R vs 2B minus two pawns maybe more
3B vs Q plus one and a half pawn
2R vs Q plus half a pawn other bonuses should dominate
R+B vs Q minus two pawns maybe more
new permutations
R+2B vs Q +nPawn plus three pawns
2B vs Q a very special case, in general a clear plus for the queen but not if there is
a) an attack
b) the opposing side is severely restricted or
c) a piece is out of play for the opponent.
its safest if all three conditions are met.

Thank you very much for your suggestions, which I saved away.
I cannot see, how this would work by an array lookup, though.
For the same DeltaNoPieces there are different "correction factors".
Anyway, a few branches shouldn't cost much performance.
Do you accidently have a position, where 2B+nP against a queen
are relatively strong.
Regards,
Dieter

[Dieter Buerssner]

Geschrieben von: / Posted by: Dieter Buerssner at 16 July 2000 20:21:46:
Als Antwort auf: / As an answer to: Re: Yace 015 vs Lg 2.8 A blowout ! geschrieben von: / posted by: Uri Blass at 15 July 2000 18:44:42:

What usually happens against Crafty is the following. Both show even score.
Yace sees a stupid trade R+2P against B+N. Score for Yace rises to +0.7,
score for Crafty rises to +0.5 - game over for Yace About ten
moves later Yace will loose a pawn, another ten moves later, it will loose
another pawn.
So with your suggestion, the pawn value should be (if I trust Crafty's
evaluation) 0.4. I think, this won't work.

I guess that in this case you need also to increase the value of bishops and knights.
You can get -0.1 instead of +0.7 for R+2P vs B+N if you increase bishops and knights values by 0.2 and reduce pawn value by 0.2.
It is not enough to get the evaluation of crafty but I guess that it is enough to avoid most of the bad trades.

Thanks for your suggestion. I was very sceptical, because I tried
similar things before. My old piece values were
100 320 330 500 1000. I tried 80 340 350 500 1000, and made a match
(G/20) from Nunn 2 positions against Crafty. The result looks promising.
The former result was Crafty - Yace 21 : 19. Now I got 18.5 : 21.5,
with the results from the different position largely differing.
(Note that Crafty seems not to run very fast on my AMD K6-2, this
is shown by comparing nodes/s of Crafty and Yace on my computer and
an higher end machine of Mogens Larsen.)
The start of a second match, where I adjusted the positional
scores by a factor of 0.8 (to make up for the smaller pawn
value) and also adjusted the initial search window by the same
factor looks even more promising.
Regards,
Dieter
The error in my previous experiments was, that I increased the
value of the rook as well, which was just stupid.
No doubt, the suggestions made by Dan Anderson will yield a better
eval, but, as you said, the change in piece values seems to work well
enough to avoid most bad trades. It has also some other significant
advantages for my search. The positional scores will be smaller, and
the material value alone will be a better estimation of the eval.
This leads to cheaper decisions for a cutoff in qsearch or an
early exit in eval.
Regards,
Dieter