[ View Thread ] [ Post Response ] [ Return to Index ] [ Read Prev Msg ] [ Read Next Msg ]

BGonline.org Forums

Improved Cube Handling in Races

Posted By: Axel Reichert
Date: Tuesday, 17 June 2014, at 9:37 p.m.

In Response To: Improved Cube Handling in Races (Taper_Mike)

Hi Mike,

thanks for an awful lot of compliments.

I do not claim that the method is "optimal", which I consider to be an over-used term. Isight sampled the design space (i. e. it tried a method with particular parameter values) and proceeded depending on the total error of the tried method. The design space was huge, 27 billion possible methods, so it was infeasible to try all methods. But the optimization algorithm managed to find "hot spots", i.e. promising regions in the design space. These hot spots were sampled completely, hence if the global optimum is in one of the promising regions, Isight has found it. I cannot guarantee that the global optimum is somewhere else, but my backgammon gut feeling considers this to be unlikely.

And please keep in mind, even if Isight found the global optimum, it is the optimum for THIS design space, i.e. of methods fitting into the general framework as defined in my article. Perhaps methods working completely different would allow for even smaller total errors.

You are right in stating that Isight "fitted" the parameters of the method to the database of position. Of course, that is what it should do. I am not sure about the quality of the database. It contains non-contact positions only, and I believe that long races (> 100) without contact are rare not only in the database, but also in live play, since I think that games played on FIBS (years back, when many competent players were playing there) will give a reasonable cross-section of relevant racing positions.

I definitely did not want to use a created database (e.g. containing all positions with at most 15 checkers distributed of 10 points or so), since I feared that such a database would REALLY be slanted by containing tons of positions that are highly unlikely to occur in live play. That would have resulted in Isight fitting the parameters to irrelevant data.

Personally, I do not this formula as long as there is contact. In these cases, I do not even do an exact pip count, but rather rely only on the half-crossover pip count.

There is no need to worry about Isight missing a more accurate method in favor of another with less effort. I did a multi-objective optimization, which means that all methods with the best accuracy for a given effort would have been found, even "expensive" ones. Search for "Pareto" in my article.

Best regards

Axel

Messages In This Thread

 

Post Response
Your Name:
Your E-Mail Address:
Subject:
Message:

If necessary, enter your password below:

Password:
 

 

[ View Thread ] [ Post Response ] [ Return to Index ] [ Read Prev Msg ] [ Read Next Msg ]

BGonline.org Forums is maintained by Stick with WebBBS 5.12.