The other thread is the wrong place for the skill discussion, so I am starting things over here.
First, here is 23.3 results. the R07 version has a new skill change that slows the NPS down proportional to the skill level, to help minimize the Beal effect.
the -n after the R07 versions is the skill setting used, it varied from 1, to 10 and by 10 all the way to 100. R06 is our best 23.3 version so far and will likely be the release version once I get the skill feature into a usable state. It is about +55 over 23.2.
The ratings at the bottom are not accurate, because the weakest opponent in this test is over 2600, but it does show that the Elo can be spread all over the place with this command. I'm not quite so happy with skill 70-90, as that is a pretty minimal change. But this is the first cut. I have an alternative way to reduce the Beal effect that I am testing next. The -80 test is not finished, but it seems to fit in with the others pretty well even with almost 20K games remaining.
bob wrote:The other thread is the wrong place for the skill discussion, so I am starting things over here.
First, here is 23.3 results. the R07 version has a new skill change that slows the NPS down proportional to the skill level, to help minimize the Beal effect.
the -n after the R07 versions is the skill setting used, it varied from 1, to 10 and by 10 all the way to 100. R06 is our best 23.3 version so far and will likely be the release version once I get the skill feature into a usable state. It is about +55 over 23.2.
The ratings at the bottom are not accurate, because the weakest opponent in this test is over 2600, but it does show that the Elo can be spread all over the place with this command. I'm not quite so happy with skill 70-90, as that is a pretty minimal change. But this is the first cut. I have an alternative way to reduce the Beal effect that I am testing next. The -80 test is not finished, but it seems to fit in with the others pretty well even with almost 20K games remaining.
Here were my results (I don't have your mighty cluster so the significance is much lower):
I see the same pattern that you do (and I extended to the negative and the pattern continues). However, I get a strange effect for a setting of zero. Can you run a skill of zero on your mighty cluster to see if you get the same behavior? The only real change I made to the code was to allow any skill number from -100 to +100 instead of from +1 to +100.
bob wrote:The other thread is the wrong place for the skill discussion, so I am starting things over here.
First, here is 23.3 results. the R07 version has a new skill change that slows the NPS down proportional to the skill level, to help minimize the Beal effect.
the -n after the R07 versions is the skill setting used, it varied from 1, to 10 and by 10 all the way to 100. R06 is our best 23.3 version so far and will likely be the release version once I get the skill feature into a usable state. It is about +55 over 23.2.
The ratings at the bottom are not accurate, because the weakest opponent in this test is over 2600, but it does show that the Elo can be spread all over the place with this command. I'm not quite so happy with skill 70-90, as that is a pretty minimal change. But this is the first cut. I have an alternative way to reduce the Beal effect that I am testing next. The -80 test is not finished, but it seems to fit in with the others pretty well even with almost 20K games remaining.
Here were my results (I don't have your mighty cluster so the significance is much lower):
I see the same pattern that you do (and I extended to the negative and the pattern continues). However, I get a strange effect for a setting of zero. Can you run a skill of zero on your mighty cluster to see if you get the same behavior? The only real change I made to the code was to allow any skill number from -100 to +100 instead of from +1 to +100.
I strongly suspect that the effect I am seeing is due to one of these assignments:
I send the cpu to sleep for 1/16 sec. as often as neccessairy to reach the nps. This results in very low cpu usage for low elo values.
IMHO if this formula works for spike it should work for most engines. Sadly I only had some tests by human playes to tune the factors and no artificial test. The random value is not needed but it "smells" more like a weak human player if sometimes simple pawn losses are not seen.
Have you got a comparable formular to reduce strenth?
I send the cpu to sleep for 1/16 sec. as often as neccessairy to reach the nps. This results in very low cpu usage for low elo values.
IMHO if this formula works for spike it should work for most engines. Sadly I only had some tests by human playes to tune the factors and no artificial test. The random value is not needed but it "smells" more like a weak human player if sometimes simple pawn losses are not seen.
Have you got a comparable formular to reduce strenth?
Greetings Volker
No. What I did was to come with an idea, and then test it on the cluster at various settings to see what happens. Problem is, if you want to take an engine like Crafty and get it down into the 800 range from its normal 2800, that is a _huge_ drop and it is difficult to come up with a suite of opponents that bracket ratings from sub-800 to 2800+, which is not so easy to come up with...
I'd like to find something that is hardware platform independent, but that seems even harder.
I think "my" way to reduce nodes searched per second is pretty hardware independent - not dependent of cpu speed - if you find a way to wait 1/16 second on every machine. But as far as I know you have plenty of experience with this kind of stuff. (I learned how to sync threads in linux from your code.)
if you find a way to wait 1/16 second on every machine
Sleep(62); //62.5/1000
Not guaranteed. In fact, sleep(1) is supposed to sleep for _one_ second, according to POSIX. nanosleep() is supposed to sleep for either (a) the indicated number of nanoseconds, or (b) the indicated number of nanoseconds rounded up to the operating system clock resolution, which for most Linux kernels is 100th of a second, but can vary from that.
jhaglund wrote:
Quote:
if you find a way to wait 1/16 second on every machine
Sleep(62); //62.5/1000
Not guaranteed. In fact, sleep(1) is supposed to sleep for _one_ second, according to POSIX. nanosleep() is supposed to sleep for either (a) the indicated number of nanoseconds, or (b) the indicated number of nanoseconds rounded up to the operating system clock resolution, which for most Linux kernels is 100th of a second, but can vary from that.
This was for "windoze"... works for me....
Sleep(1000); // = 1 sec.
Sleep(62); // about 1/16th
Sleep(125); // = 1/8th
etc...