Geschrieben von: / Posted by: Fabien Letouzey at 11 March 2004 11:34:05:
Anybody can do this?
I am thinking at least 15 0 (on fast hardware) or 20 0 otherwise. You can also use increments of course, I have no experience of time controls.
Maybe a match against Gothmog to see if Fruit gets a bit less slaughtered when given more time?
Or against engines that you think are closed in strength, so we can evaluate Fruit's place in the world.
Fruit is not designed for blitz.
Thanks,
Fabien.
Winboard Forum
Discussions (not only) about Xboard/Winboard, Computer Chess and Chess Programming
Wanted: Fruit matches at slower time controls
7 posts
• Page 1 of 1
Wanted: Fruit matches at slower time controls
by Fabien Letouzey » 11 Mar 2004, 11:34
- Fabien Letouzey
Re: Wanted: Fruit matches at slower time controls
by Kurt Utzinger » 11 Mar 2004, 11:45
Geschrieben von: / Posted by: Kurt Utzinger at 11 March 2004 11:45:10:
Als Antwort auf: / In reply to: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Fabien Letouzey at 11 March 2004 11:34:05:
Kurt
Als Antwort auf: / In reply to: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Fabien Letouzey at 11 March 2004 11:34:05:
I like to hear that Fruit is not designed for (dully) blitz -:)Anybody can do this?
I am thinking at least 15 0 (on fast hardware) or 20 0 otherwise. You can also use increments of course, I have no experience of time controls.
Maybe a match against Gothmog to see if Fruit gets a bit less slaughtered when given more time?
Or against engines that you think are closed in strength, so we can evaluate Fruit's place in the world.
Fruit is not designed for blitz.
Thanks,
Fabien.
Kurt
- Kurt Utzinger
Re: Wanted: Fruit matches at slower time controls
by Fabien Letouzey » 11 Mar 2004, 12:01
Geschrieben von: / Posted by: Fabien Letouzey at 11 March 2004 12:01:10:
Als Antwort auf: / In reply to: Re: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Kurt Utzinger at 11 March 2004 11:45:10:
But, from the way I implemented everything, Fruit should do better with more time.
This might prove wrong with testing, hence my post.
Fabien.
Als Antwort auf: / In reply to: Re: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Kurt Utzinger at 11 March 2004 11:45:10:
Of course I don't mean that "time control" is on top of my design-goal list.I like to hear that Fruit is not designed for (dully) blitz -:)
But, from the way I implemented everything, Fruit should do better with more time.
This might prove wrong with testing, hence my post.
Fabien.
- Fabien Letouzey
Re: Wanted: Fruit matches at slower time controls
by Uri Blass » 11 Mar 2004, 12:12
Geschrieben von: / Posted by: Uri Blass at 11 March 2004 12:12:04:
Als Antwort auf: / In reply to: Re: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Kurt Utzinger at 11 March 2004 11:45:10:
I wonder how the author got this conclusion even without testing it.
I expect a program with bigger evaluation to get positional decisive advantage thanks to king safety problems of fruit and when fruit is going to understand it then it is going to be too late because fruit will need to search 20 plies forward to start to see the problem with king safety for different positional reasons and even at 120/40 it cannot do it.
I also do not like adding a lot of evaluation but
I added king safety and increased my mobility evaluation that was too small after looking at games when movei lost at Leo's tournament that were at 40/40.
There were cases when movei without king safety pushed a pawn near the king and created for itself king safety problems and could not avoid the error even after a long search.
Is there something wrong with my logic?
Note that I am also interested in long time control but I do not plan to add much to my evaluation and I add something only when I see a big problem.
Uri
Als Antwort auf: / In reply to: Re: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Kurt Utzinger at 11 March 2004 11:45:10:
I think that it is counter intuitive to say that a program is not designed for blitz when it has little evaluation.I like to hear that Fruit is not designed for (dully) blitz -:)Anybody can do this?
I am thinking at least 15 0 (on fast hardware) or 20 0 otherwise. You can also use increments of course, I have no experience of time controls.
Maybe a match against Gothmog to see if Fruit gets a bit less slaughtered when given more time?
Or against engines that you think are closed in strength, so we can evaluate Fruit's place in the world.
Fruit is not designed for blitz.
Thanks,
Fabien.
Kurt
I wonder how the author got this conclusion even without testing it.
I expect a program with bigger evaluation to get positional decisive advantage thanks to king safety problems of fruit and when fruit is going to understand it then it is going to be too late because fruit will need to search 20 plies forward to start to see the problem with king safety for different positional reasons and even at 120/40 it cannot do it.
I also do not like adding a lot of evaluation but
I added king safety and increased my mobility evaluation that was too small after looking at games when movei lost at Leo's tournament that were at 40/40.
There were cases when movei without king safety pushed a pawn near the king and created for itself king safety problems and could not avoid the error even after a long search.
Is there something wrong with my logic?
Note that I am also interested in long time control but I do not plan to add much to my evaluation and I add something only when I see a big problem.
Uri
- Uri Blass
Re: Wanted: Fruit matches at slower time controls
by Fabien Letouzey » 11 Mar 2004, 12:41
Geschrieben von: / Posted by: Fabien Letouzey at 11 March 2004 12:41:11:
Als Antwort auf: / In reply to: Re: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Uri Blass at 11 March 2004 12:12:04:
Uri,
I have answered you on CCC, I did not know about this post.
Maybe it is better if you ask questions here only, because anybody in the world can read it? Can you confirm, password is needed only to post?
Fabien.
Als Antwort auf: / In reply to: Re: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Uri Blass at 11 March 2004 12:12:04:
Uri,
I have answered you on CCC, I did not know about this post.
Maybe it is better if you ask questions here only, because anybody in the world can read it? Can you confirm, password is needed only to post?
Fabien.
- Fabien Letouzey
Re: Wanted: Fruit matches at slower time controls
by Uri Blass » 11 Mar 2004, 13:26
Geschrieben von: / Posted by: Uri Blass at 11 March 2004 13:26:26:
Als Antwort auf: / In reply to: Re: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Fabien Letouzey at 11 March 2004 12:41:11:
see the rest of this post.
Uri,
Bob specifically mentioned in posts that he tried ETC and discarded it based on
testing. So the "lack" of ETC cannot make Crafty weaker.
==============================================================================
It can also mean that he did not implement ETC correctly.
I cannot imagine a reason that it cannot make crafty better if it is used far away from the leaves
==============================================================================
In my experience ETC is fine if used "far away" enough from the leaves. Most of
the time the slightly better BF only barely compensates for the loss of speed,
but in some endgames with locked pawns I believe ETC can help a lot. Also I
think the more time the more interesting ETC is.
I do think it is slow based on how I could make the code faster. OK, maybe only
50% faster. But it would make the code hard to modify in the future. I will
care about speed only when I have a clear design in mind. Actually after
version 1.0 is released next week I intend to "unoptimise" the code by removing
complex function that only slightly improve speed, so I can experiment with new
things easily.
===============================================================================
Uri:"I think that most programmers also do not optimize their programs and Bob also care about being able to modify the program so it is not a disadvantage.
I think that part of the problem of programmers is simply that they do not know how to optimize but in any case optimization for speed is not very important if it can do you only 50% faster unless you have a top program."
==============================================================================
I am only trying to understand what "search" really does. That is different
from saying "stupid eval is the way to go".
=============================================================================
Uri:"I do not say that stupid evaluation is the way to go and I only say that it is surprising if it can do better at long time control"
=============================================================================
How are you expecting me to answer a question even commercial authors don't
agree about? Compare Diep with Chess Tiger; same design? I don't think so.
Diep was stronger 10 years ago than my program will ever be, how could I say a
good eval is useless?
===============================================================
Uri:"How do you know that Diep was stronger than your program?"
===============================================================
Uri , can you understand that a chess program can be designed for other reasons
that beeing the strongest possible? I have written evaluations before, it is
too boring for me. I want to study search, and apply things to other games as
well. I will add knowledge to Fruit, but only to "fix" the biggest problems. I
don't especially believe this is the best way to obtain a strong program.
==============================================================================
Uri:"I also think that search is more interesting because it can help also for other games but I am surprised that it helped your program so much.
How much time did you work about your alphabeta and your qsearch"
I think that your results means that it is better if I do nothing with my evaluation before I fix my search to have the same advantages as your search(I have one problem and it is pruning with hash tables because my evaluation is not dependent only on the leaf position and I think to add upper bound and lower bound to the hash tables so I will be able to prune based on exact value if the upper bound is equal to the lower bound but first I will try to improve my hash without using it for pruning).
I found that my small value that is not dependent on the leaf position and is easy to calculate was priductive in games but I never used hash for pruning and one of the reason is because of my bad design decision to have 2 varaibles for depth and partial depth instead of one when I save in the hash tables only the depth without partial depth.
==============================================================================
Yes, I use only null-move pruning. There is nothing in my search that is not
known by most programmers. Actually the few differences there are might be
hurting strength, like I never "hash cut" at PV nodes (I only read the best
move) so that my PV is never truncated. Also I use a "safe version" of PVS,
where my research windows is the "full" [alpha,beta] instead of [value,beta]
where value is the result of the null-window search. I also don't update alpha
or beta based on the value in the hash table.
In the case of Fruit, I believe its lack of tactical extensions hurts a lot in
fast games. I expect that this matters less as slow time controls. This is
unrelated to evalution.
Fabien.
==============================================================================
Uri:"I do the same in movei about PVS and I also do not change alpha and beta based on the value on the hash tables.
I also never use hash tables for pruning and one of the problem is that I need to rewrite my alphabeta that is simply ugly.
==============================================================================
Als Antwort auf: / In reply to: Re: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Fabien Letouzey at 11 March 2004 12:41:11:
passward is needed in the CCC also to read so here is the post again and added comments between ===========Uri,
I have answered you on CCC, I did not know about this post.
Maybe it is better if you ask questions here only, because anybody in the world can read it? Can you confirm, password is needed only to post?
Fabien.
The lack of knowledge in crafty is also real.
Crafty does not know things like ETC.
I do not think that it is slow and it is simply crafty that is fast.
There are a lot of programs that search significantly less nodes per second.
People often claim that small evaluation should be a problem at slower time
control so if it has little evaluation it cannot do better at longer time
control.
What is your opinion about it?
Is it a wrong opinion and chess is simply a search based game when almost every
hole in the evaluation can be covered by searching few plies deeper?
I knew from the results of olithink that programs can do well even with small
evaluation but the results of your program suggest that olithink was not close
to the best that it is possible to do with small evaluation and I suspect that
it is even possible to be better than Crafty with your little evaluation(after
all I guess that you do not use all the good techniques that were mentioned and
for example you do not use history based pruning when the idea is to prune moves
that almost always failed low based on the history tables by searching them to
reduced depth,not to mention that you do not use pruning based on evaluation or
extensions except check extensions).
see the rest of this post.
Uri,
Bob specifically mentioned in posts that he tried ETC and discarded it based on
testing. So the "lack" of ETC cannot make Crafty weaker.
==============================================================================
It can also mean that he did not implement ETC correctly.
I cannot imagine a reason that it cannot make crafty better if it is used far away from the leaves
==============================================================================
In my experience ETC is fine if used "far away" enough from the leaves. Most of
the time the slightly better BF only barely compensates for the loss of speed,
but in some endgames with locked pawns I believe ETC can help a lot. Also I
think the more time the more interesting ETC is.
I do think it is slow based on how I could make the code faster. OK, maybe only
50% faster. But it would make the code hard to modify in the future. I will
care about speed only when I have a clear design in mind. Actually after
version 1.0 is released next week I intend to "unoptimise" the code by removing
complex function that only slightly improve speed, so I can experiment with new
things easily.
===============================================================================
Uri:"I think that most programmers also do not optimize their programs and Bob also care about being able to modify the program so it is not a disadvantage.
I think that part of the problem of programmers is simply that they do not know how to optimize but in any case optimization for speed is not very important if it can do you only 50% faster unless you have a top program."
==============================================================================
I am only trying to understand what "search" really does. That is different
from saying "stupid eval is the way to go".
=============================================================================
Uri:"I do not say that stupid evaluation is the way to go and I only say that it is surprising if it can do better at long time control"
=============================================================================
How are you expecting me to answer a question even commercial authors don't
agree about? Compare Diep with Chess Tiger; same design? I don't think so.
Diep was stronger 10 years ago than my program will ever be, how could I say a
good eval is useless?
===============================================================
Uri:"How do you know that Diep was stronger than your program?"
===============================================================
Uri , can you understand that a chess program can be designed for other reasons
that beeing the strongest possible? I have written evaluations before, it is
too boring for me. I want to study search, and apply things to other games as
well. I will add knowledge to Fruit, but only to "fix" the biggest problems. I
don't especially believe this is the best way to obtain a strong program.
==============================================================================
Uri:"I also think that search is more interesting because it can help also for other games but I am surprised that it helped your program so much.
How much time did you work about your alphabeta and your qsearch"
I think that your results means that it is better if I do nothing with my evaluation before I fix my search to have the same advantages as your search(I have one problem and it is pruning with hash tables because my evaluation is not dependent only on the leaf position and I think to add upper bound and lower bound to the hash tables so I will be able to prune based on exact value if the upper bound is equal to the lower bound but first I will try to improve my hash without using it for pruning).
I found that my small value that is not dependent on the leaf position and is easy to calculate was priductive in games but I never used hash for pruning and one of the reason is because of my bad design decision to have 2 varaibles for depth and partial depth instead of one when I save in the hash tables only the depth without partial depth.
==============================================================================
Yes, I use only null-move pruning. There is nothing in my search that is not
known by most programmers. Actually the few differences there are might be
hurting strength, like I never "hash cut" at PV nodes (I only read the best
move) so that my PV is never truncated. Also I use a "safe version" of PVS,
where my research windows is the "full" [alpha,beta] instead of [value,beta]
where value is the result of the null-window search. I also don't update alpha
or beta based on the value in the hash table.
In the case of Fruit, I believe its lack of tactical extensions hurts a lot in
fast games. I expect that this matters less as slow time controls. This is
unrelated to evalution.
Fabien.
==============================================================================
Uri:"I do the same in movei about PVS and I also do not change alpha and beta based on the value on the hash tables.
I also never use hash tables for pruning and one of the problem is that I need to rewrite my alphabeta that is simply ugly.
==============================================================================
- Uri Blass
Re: Wanted: Fruit matches at slower time controls
by Joachim Rang » 11 Mar 2004, 13:47
Geschrieben von: / Posted by: Joachim Rang at 11 March 2004 13:47:10:
Als Antwort auf: / In reply to: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Fabien Letouzey at 11 March 2004 11:34:05:
regards Joachim
Als Antwort auf: / In reply to: Wanted: Fruit matches at slower time controls geschrieben von: / posted by: Fabien Letouzey at 11 March 2004 11:34:05:
It nevertheless plays not bad with 2/0. See my post above.Anybody can do this?
I am thinking at least 15 0 (on fast hardware) or 20 0 otherwise. You can also use increments of course, I have no experience of time controls.
Maybe a match against Gothmog to see if Fruit gets a bit less slaughtered when given more time?
Or against engines that you think are closed in strength, so we can evaluate Fruit's place in the world.
Fruit is not designed for blitz.
Thanks,
Fabien.
regards Joachim
- Joachim Rang
7 posts
• Page 1 of 1
Return to Archive (Old Parsimony Forum)
Who is online
Users browsing this forum: Google [Bot] and 23 guests