Moderators: hgm, Rebel, chrisw
That's interesting. You seem very sure about this. Could you please explain me why ?bob wrote:
Does this mean you are only comparing stock G2.1 to your modified version? That won't tell you anything useful at all...
Tord has access to my git repository so he knows every bit of change and also the rationale behind it.Eelco de Groot wrote:Thanks very much for your Glaurung version Marco! I only had a short look yet at the sources but it looks very interesting and there also seems to be a substantial amount of changes that are more programming-technical in nature, changes I think Tord, or other programmers, here will be interested in, even if it is just to compare different possibilities for doing things?
I have asked if Jim Ablett maybe could make a compile for us, I hope that is possible! That way there would also be a standardized version to compare any testresults. But I don't know if Jim has the time.
Regards, Eelco
I have had this in my program for a while, and took it out recently. My version also included spending less time if your opponent had more time than you. I have mixed feelings on it. My last thought was that if your opponent is better at allocating time than you are the heuristic is useful (since it acts to make your time usage per move similar to your opponents over the course of the game) and if your opponent is worse at time allocation than is harmful. It is not really something I do as a human (I strive to make my time usage independent of opponent) and I don't really have a good feel for whether the idea has merit or not. One idea I considered but have not tried is when opponent is super low on time, use extensions to calculate a series of moves and than blitz them out (something humans sometimes do). This seems like it might be fairly effective, particularly against humans...but also against computers as it robs their usage of ponder. Anyway, I think time usage is an interesting area to explore, and am interested in hearing your findings in that area as you encounter them.- Opponent time info
The last one was originated from my way to play chess: when I am in a trouble position I take a bit more time to analize. And if I am in great time advantage against my opponent I take also more time.
I have coded this empirical rule and the results were positive. Indeed I was surprised to NOT find any consideration regarding opponent remaining time in any of the chess engine I have checked, not only in Glaurung...perhaps I'm missing something...
Marco, here are the compiles from Jim Ablett. Jim writes that the version you made seems to have a slightly lower nodes per second than the original Glaurung 2.1 and that he is interested in the testresults. A lower nodes per second does not always mean a lower speed of finding things I think, sometimes a huge nps is not a good sign at all -I don't really know if this is correct but I believe to have seen cases when I thought those nodes were maybe all from a qsearch "explosion" for instance and the speed then means there are no hashhits-. But here is the link that Jim gave:mcostalba wrote:Tord has access to my git repository so he knows every bit of change and also the rationale behind it.Eelco de Groot wrote:Thanks very much for your Glaurung version Marco! I only had a short look yet at the sources but it looks very interesting and there also seems to be a substantial amount of changes that are more programming-technical in nature, changes I think Tord, or other programmers, here will be interested in, even if it is just to compare different possibilities for doing things?
I have asked if Jim Ablett maybe could make a compile for us, I hope that is possible! That way there would also be a standardized version to compare any testresults. But I don't know if Jim has the time.
Regards, Eelco
By now most changes are code style and cleanup related because I know more C++ then chess programming
I hope that improving my chess programming knowledge will bring also more substantial changes...
Anyhow the (few) real changes are:
- Superlinear interpolation
- Hashing in qsearch
- Opponent time info
The last one was originated from my way to play chess: when I am in a trouble position I take a bit more time to analize. And if I am in great time advantage against my opponent I take also more time.
I have coded this empirical rule and the results were positive. Indeed I was surprised to NOT find any consideration regarding opponent remaining time in any of the chess engine I have checked, not only in Glaurung...perhaps I'm missing something...
To have properly compiled versions for 32 and 6f bits would be great !
Thanks
Marco
mcostalba wrote:That's interesting. You seem very sure about this. Could you please explain me why ?bob wrote:
Does this mean you are only comparing stock G2.1 to your modified version? That won't tell you anything useful at all...
Answering to other comments in this thread, I would think the truncation is an integral part of the algorithm, that's what makes it non linear.
But it is true I have not tested by simply increasing the maximum value from 128 to say 160 and see what happens...I'll do.
Marco
Eelco de Groot wrote:
Marco, here are the compiles from Jim Ablett. Jim writes that the version you made seems to have a slightly lower nodes per second than the original Glaurung 2.1
) ?After looking in wiki at http://en.wikipedia.org/wiki/Sigmoid_function (the ignorance is all on my side!) I have to say that Sigmoid is the proper name...yes it defenitly is, although my is a linearized version, the sigmoid gives exactly the rationale of this modification.Gerd Isenberg wrote:Why do you call it super linear, but not sigmoid?
Sorry for my ignorance,
Gerd