15
The ration between CCRL Elo and age is 138. Anyone above this?
You beat me; I am at 123
Are you 20?
well researched
I did my first computerchess-related project when I was around 16: http://members.chello.at/cm-codeman/Chess/
It is a simple web chess gui I made in Javascript (it is only compatible with IE, not Firefox or Chrome)
The engine programming started about 2 years after that.
AFAIK that is illegal
(I'm a die-hard FF user, though I use Opera & Chrome sometimes)
I did my first computerchess-related project when I was around 16: http://members.chello.at/cm-codeman/Chess/
It is a simple web chess gui I made in Javascript (it is only compatible with IE, not Firefox or Chrome)
The engine programming started about 2 years after that.
AFAIK that is illegal
(I'm a die-hard FF user, though I use Opera & Chrome sometimes)
I did my first computerchess-related project when I was around 16: http://members.chello.at/cm-codeman/Chess/
It is a simple web chess gui I made in Javascript (it is only compatible with IE, not Firefox or Chrome)
The engine programming started about 2 years after that.
AFAIK that is illegal
(I'm a die-hard FF user, though I use Opera & Chrome sometimes)
?! It's a lot easier to write JavaScript for FF than IE.... *drools*
Like, I mean, seriously, it's not even funny implementing your own DOM functions, testing for window.ActiveXObject all the time, etc. Yeesh. I hate IE.....
That looks good, but doesn't work for Firefox 3.6.x. Fortunately, this one does.
?! It's a lot easier to write JavaScript for FF than IE.... *drools*
Like, I mean, seriously, it's not even funny implementing your own DOM functions, testing for window.ActiveXObject all the time, etc. Yeesh. I hate IE.....
That looks good, but doesn't work for Firefox 3.6.x. Fortunately, this one does.
Peter
Nowadays things have changed. If you think, the project was done around 2006. At that time firefox was still in its beginning somewhere between version 1.5 and 2.0. Were you a true believer already then? At that time the dominance of IE was so evident I didn't even consider any cross browser checks. Today I would!
Don wrote:Komodo does not do under-promotions in the tree search other than the root node.
This is because Komodo is a selective search program and under-promotion is not the best move 99.999% of the time. Most of the strength of Komodo is based on figuring out which moves not to consider and it's not possible to be right 100% of the time, but this one is certainly a no-brainer if any move is, it's almost always wrong.
What I might consider doing is to consider knight promotions when they also happen to be check. I don't think this was weaken the program in any measurable way and I think it would cover 99% of the cases where it's best to promote to a knight.
I think Rybka does the same - I have heard people complain about this on the Rybka forum.
One simple optimization is to not try underpromotions if the move that causes the queen promotion to fail low is a capture of the promoted piece since you know that the underpromotions would also fail low. I think that if you only take the cases where the queen promotion fails low and the refutation move is not a capture of the promoted queen, the statistics would not be so one-sided. Another idea is to only try underpromotions if either there are stalemates in the search tree under the queen promotion or the knight underpromotion gives check.
?! It's a lot easier to write JavaScript for FF than IE.... *drools*
Like, I mean, seriously, it's not even funny implementing your own DOM functions, testing for window.ActiveXObject all the time, etc. Yeesh. I hate IE.....
That looks good, but doesn't work for Firefox 3.6.x. Fortunately, this one does.
Peter
Nowadays things have changed. If you think, the project was done around 2006. At that time firefox was still in its beginning somewhere between version 1.5 and 2.0. Were you a true believer already then? At that time the dominance of IE was so evident I didn't even consider any cross browser checks. Today I would!
Yeah, I suppose that's true.
Alright, back in 06 I was in 3rd grade and had no clue what a 'Firefox' was .
I have to remind myself to test with IE (8 is the only released version I support) periodically as I develop....
Do you know what elo gain you got from removing underpromotions ?
This has been on my todolist for long (i was just planning to add a reduction in the main search and removing them from qsearch) because i did not expect significant gain. But significant is getting smaller and smaller this days
Do you know what elo gain you got from removing underpromotions ?
This has been on my todolist for long (i was just planning to add a reduction in the main search and removing them from qsearch) because i did not expect significant gain. But significant is getting smaller and smaller this days
Let's remove en-passant pawn captures and long castling while we are at it for the +5 Elo gain.
Do you know what elo gain you got from removing underpromotions ?
This has been on my todolist for long (i was just planning to add a reduction in the main search and removing them from qsearch) because i did not expect significant gain. But significant is getting smaller and smaller this days
I cannot give you a precise answer, but it's non-trivial and of course that will depend on your definition of non-trivial.
The slowdown will not appear very significant in most positions, but the issue is what happens when there is a fight to promote a pawn? In such battles search speed matters a LOT. It is a drag on search speed when every time you promote you have to search 4 subtree's instead of 1. And 3 of those sub trees are almost certainly wrong if the first one is.
Do you know what elo gain you got from removing underpromotions ?
This has been on my todolist for long (i was just planning to add a reduction in the main search and removing them from qsearch) because i did not expect significant gain. But significant is getting smaller and smaller this days
Let's remove en-passant pawn captures and long castling while we are at it for the +5 Elo gain.
If it really gain 5 ELO it would be worth it, but it probably doesn't gain anything and would weaken the program. Both of these kinds of moves are reasonable moves to try when they are possible. It's not so much how frequently they occur but how likely it is to be the best move when it happens.
Of course any "hard" pruning rule makes the program a little bit incorrect, but so does hash table implementations with GHI issues.
I think the right way to handle such omissions of moves is in a scalable way - make sure that as you iterate you alway see more - for instance by having a rule such as "don't look at bishop promotions unless depth > 15 or something like that. Then your program will always find a bishop under-promotion given enough search depth.
.
