I agree,
this is a position where 2ply is expected to do much better, even
cubeless, since it understands the variation tree much better.
It sounds like a good idea though, to make a collection of
moves/evals/cubes where 0ply is way of compared to 2ply or rollouts.
Christian.
On Wed, Jun 25,
Christian Anthon schrieb:
Hi Achim,
I'm not exactly sure what your point is, but since the correct 2ply
move falls outside the 0.160 limit of the normal move filter used at
0ply, it is never evaluated at 2ply.
The point is not a technical bug but the fact that gnubg totally
misevaluates a
Am 24.06.2008 um 01:16 schrieb Christian Anthon:
Hi Achim,
I'm not exactly sure what your point is, but since the correct 2ply
move falls outside the 0.160 limit of the normal move filter used at
0ply, it is never evaluated at 2ply.
The point is not a technical bug but the fact that gnubg
On Tue, Jun 24, 2008 at 11:32 AM, Achim Mueller [EMAIL PROTECTED] wrote:
The point is not a technical bug but the fact that gnubg totally
misevaluates a position at 0ply that actually should be handled easily.
I put some more positions at http://www.acepoint.de/index.php?id=37. This
section
Hi Achim,
I'm not exactly sure what your point is, but since the correct 2ply
move falls outside the 0.160 limit of the normal move filter used at
0ply, it is never evaluated at 2ply.
Christian.
On Mon, Jun 23, 2008 at 3:29 AM, Mueller Achim [EMAIL PROTECTED] wrote:
Hi folks,
GNU
Hi folks,
GNU Backgammon Position ID: 7WyCAQO23B4ABA
Match ID : cAn6ABAAGAAA
+24-23-22-21-20-19--18-17-16-15-14-13-+ O: gnubg
| O O O X O O | |O | 1 point
|O O O O | | |
| O | |
