Hi Sébastian,

Welcome to the Abalone world :)

>Engines
Aba-pro is a powerful engine, I think Tino has done a very impressive work. I
took me ages to beat this engine with MLA. I'm sure abapro is faster in node
evaluation than MLA.

> I am able to reach higher search depths than current Abalone progs (10
> ply I was told in case of Aba-Pro).
Exploring the game, and paticulary the tree cutting issues, legal moves
generation, position evaluation will lead you to the max depth you'll be able
to reach lol (for example, ProbCut doesnt seem to work and Aba-pro's heuristic
has been proven wrong in its expansion strategy by MLA is some cases, other
example : bitboards seem to lead nowhere).

> field, pursued without the required professional approach.
Lol, do not underestimate Peer, Tino and others :) Particularly their knowledge
of game programming (for both search and evaluation lol).

> I also want to provide a GUI that'll include a lot more powerful tools
> for analysis and game/database management.
There is a game file format in MLA, and some tools (like a Macromedia Flash game
player for your web pages), feel free to contact me for further info. It's the
same concerning API/engine communication, Peer is also using the AbNet
protocol.

> What i noted most about Abalone (in contrast to chess) is the lack of
> information even regarding such simple things as rules/notation.
Rules and notation are around, MLA allows both notations. To me, theoretical
knowledge of the game is an important issue. From the opening book automatic
generation work i've done so far (no yet embedded in my engine) this is a
tricky issue. But knowledge generation still looks possible to me.

Note that my MLA work is in standby for the time being, these days, i'm more
focused on my girlfriend, my job and vacations (i'm back from mexico today and
will run to kenya in july).

Good luck, build competition to Nacre, Abapro and MLA :) Feel free to share your
ideas, ask for any info / litterature that could help you.

Promise : If you beat MLA i'll put my hands in the engine again lol. 2.5 is the
current version, if you beat it. 1.8 is the one to beat, it's the won that won
against abapro.

David.







Selon icyclemort <Sebastian.Mort@...>:

> Hello all!
>
>
> A quick introduction:
>
> I am new to the field of Abalone programming.
>
> Nevertheless, my goal is clear, I want to create an Abalone engine
> superior to Aba-Pro (mid-term) and possibly (hard to judge how
> difficult it is) make it equal or even superior to the cream of human
> players(long term).
>
> I also want to provide a GUI that'll include a lot more powerful tools
> for analysis and game/database management.
>
> To be honest, Abalone programming as of now seems to be a rather loose
> field, pursued without the required professional approach.
> I've got a lot of chess programming experience, and I am very
> confident that I'll be able to deliver a GUI/engine package that is
> superior to what is currently available.
>
> I am able to reach higher search depths than current Abalone progs (10
> ply I was told in case of Aba-Pro).
>
> Positionally, I've got a lof of ideas that I'll try and see if they
> work as well as I hope to.
>
> So, now you're informed about my lofty goals. ;
>
>
> --- GUI/engine/interface ---
>
>
> My engine is now up and running fine, although it is still lacking a
> lot of basic search algorithm enhancements and Abalone knowledge, but
> both will come...
>
> I am still working on the GUI, it'll include a lot more stuff than
> current Ablone GUI's. It'll include a lot of stuff that should be
> interesting for Abalone players and programmers alike. Analysis Modes,
> game/database management, engine matches/tournaments, patzer/reduced
> strength computer modes and a lot of interesting stuff that has not
> yet made into a single abalone GUI (think chess and chessbase).
>
> Engine and GUI are seperated programs and communicate through an
> interface that is shamelessly based upon the Universal Chess Interface
> (UCI). I'll publish the sepecification along with the GUI, so if
> anybody is interested they can then program only an engine and rely
> upon an existing and powerful GUI. That will also help to make better
> comparisons between engines (automatic and easy to organize engine
> matches and tournaments). It should increase the competitve side of
> Abalone programming and hopefully fuel the field with more enthusiasm
> and creativity...
>
>
> --- questions ---
>
> What i noted most about Abalone (in contrast to chess) is the lack of
> information even regarding such simple things as rules/notation.
>
> I am currently a bit baffled by Abalone notation and some rules, and
> I'd like to clarify those before I move on.
>
> --- rules ---
>
> Rules about movement and win conditions are simple and clear. Perfect.
>
>
> But I am not so sure about repetition rules. Is the repetition of a
> position allowed to happen or is there some rule forbidding it or
> deciding in favor of a draw/or one of the players?
> If there is no such rule, how are infinite repetitions (nobody willing
> to deviate from a position; or even positions where everything but the
> a repetition would wreck one side's position) dealt with??
>
>
> What about the length of a game, is there some kind of established
> maximum number of moves (e.g. without a single lost stone) after which
> a game is aborted in some kind of way?
>
>
> --- notation ---
>
> Regarding the board/fields, I follow the Aba-Pro way of doing it.
> (That is, the interface specification will; the GUI is customizable
> and supports Netablone board noatition)
>
> a1 is bottom/left
> i9 is top/right
>
>
> inline moves and pushes are recorded as following:
>
> a1b2c3>b2c3d4 = a1b2
>
>
> broadside moves are a bit troubling, because very different notations
> seem to be in use:
>
> a1b2c3>b1c2d3
>
> is recorded as:
> (1) = a1c3b1 (makes sense to me)
> (2) = c3a1d3 (the same but other direction)
> (3) = a1c3d3 (less intuitive, IMO)
> (4) = c3a1b1 (same as above the other way round)
>
> (1) and (2) are FromFirst/FromLast/ToFirst
> (3) and (4) are FromFirst/FromLast/ToLast
>
> I am strongly leaning towards (1) and (2) but would like to hear
> recommendations.
>
> Regarding the difference between (1)/(3) and (2)/(4), it is the
> question of from where to start counting the stones.
> I've read suggestions that the first stone should be the one most
> closely to the bottom or the top of the field (both seem to be in use).
>
> Never have I read a suggestion of how to record a move like
> (c3c4c5>d3d4d5) where the issue would have to be decided upon a
> left/right criteria.
>
> Is there a style that is more commonly used?
>
> BTW, I despise an ambigious style. The interface specification will
> certainly not allow more than one way to handle it.
>
> (The GUI will though, there you should and will be able to choose any
> kind of notation you wish to, I might even enable custom-build notations.)
>
> So that is the notation issue, thx for reading my rant.
>
>
> --- Aba-Pro ---
>
> A completely different issue. I have tried to get my hands on Aba-Pro.
> But the website given seems to be dead. I am close to calling the
> faculty in Graz directly.
> Is there currently any way to buy/order Aba-Pro?
>
>
> --- finishing ---
>
>
> So, I hope somebody will answer my questions regarding rules and notation.
> Don't expect GUI/engine to appear before the end of july/august.
>
> Happy abalone programming!
>
>
> BTW, if somebody is interested in the engine/GUI concept and might
> want to program such an engine, I'd advise to contact me by e-mail
> (Sebastian.Leibnitz{a} googlemail . com)
>
>
> Regards, and bye.
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

--- In abalone_prog@yahoogroups.com, "peer_sommerlund"
<peer.d.sommerlund@...> wrote:

> Well, my first Abalone implementation back in 1997 was in Delphi 3,
> and judging from the replies to
> http://groups.yahoo.com/group/abalone_prog/surveys?id=12181117 several
> of the members here are old enough to know Pascal.
>
> Personally, I switched to C++ using the GUI library
> http://www.wxwidgets.org and the http://www.codeblocks.org IDE to make
> my program crossplatform (it should work on Windows, Linux, Mac).
> Converting the code is a manuel process, but it is not that hard.

I probably won't convert my GUI to C++.
I am far too efficient using Delphi. I could probably build a text
editor blindfolded (well, maybe not...)

I'll look into the license issues. I don't yet know if i am even able
to release my Delphi code. (it's a personal editon license...)
Ah, the hassles of proprietary licenses.


> > What happens in the Abalone Comuter Olympiads if two
> > engines repeat over and over again?
> > Which result is awarded?
>
> The games are played with a 30 minute time limit for the entire game,
> so one of the players will loose. See
> http://www.cs.unimaas.nl/Olympiad2003/rules.html#Default%20Conditions

:0

Quite an arbitrary solution, no?


> > I am not sure what your simpler notation is, but if it was the
> > FromFirst>ToLast, then I have to dissappoint you.
> > That is ambigious and can refer to two distinct broadside move
> > (2stones and 3 stones in 60� rotated directions).
> >
> > An example from the standard starting position:
> >
> > "c3d5" could encode two broadside moves:
> > "c3c4c5>d3d4d5" and "c3c4>d4d5"
> >
> > It would only be unambigious if you add the information wheather it is
> > a two- or three-stone move.
>
> It is unique: c3d5 only refers to c3c4>d4d5. To encode the broadside
> move c3c4c5>d3d4d5 you would have to write c5d3. This is because the
> number of marbles moved must correspond to the manhattan distance
> between FromFirst and ToLast. Quoting the link above: "For inline
> moves this is obvious how to interpret the move. For broadside moves
> it is not obvious that this notation defines a move. The notation is
> made unique by requiring that the number of steps between FromFist and
> ToLast must equal number of marbles moved."

Yes, I see it.

Quite ingenious.

It's not that easy to parse, though. (not too complicated either, but
the other solutions are more simple)
But for engine-GUI communication, this looks quite interesting.


One would still need a definiton about choosing FromFirst, though.
c3c4>d4d5 could be both: c3d5 and c4d3.

I am not so sure about confronting humans with it. It's very easy to
have a move in mind and figure out the notation, but the other way
round it's not immediately obvious (in the sense of figuring out the
move almost instantly).
I think it would take some time until it gets intuitive.


Still, I'll probably follow your lead there. I'll include it in my
GUI/engine interface spec...

Do you plan on using it for your game format?



Regards,
Sebastian Leibnitz.

--- In abalone_prog@yahoogroups.com, "icyclemort" <Sebastian.Mort@...>
wrote:
>
> It will not be open source. And you'd probably not be very pleased if
> it were, because the GUI is written in Delphi/Object Pascal. Delphi is
> well suited for RAD, but i suspect that I'd find few volunteers to
> help with coding...
> If there are Delphi programmers out there, who'd like to help me, I'd
> perhaps reappraise my decision.

Well, my first Abalone implementation back in 1997 was in Delphi 3,
and judging from the replies to
http://groups.yahoo.com/group/abalone_prog/surveys?id=12181117 several
of the members here are old enough to know Pascal.

Personally, I switched to C++ using the GUI library
http://www.wxwidgets.org and the http://www.codeblocks.org IDE to make
my program crossplatform (it should work on Windows, Linux, Mac).
Converting the code is a manuel process, but it is not that hard.



> What happens in the Abalone Comuter Olympiads if two
> engines repeat over and over again?
> Which result is awarded?

The games are played with a 30 minute time limit for the entire game,
so one of the players will loose. See
http://www.cs.unimaas.nl/Olympiad2003/rules.html#Default%20Conditions



> > > --- notation ---
> >
> > http://90214.aceboard.net/90214-2318-15375-0-Move-notation.htm
>
> I am not sure what your simpler notation is, but if it was the
> FromFirst>ToLast, then I have to dissappoint you.
> That is ambigious and can refer to two distinct broadside move
> (2stones and 3 stones in 60° rotated directions).
>
> An example from the standard starting position:
>
> "c3d5" could encode two broadside moves:
> "c3c4c5>d3d4d5" and "c3c4>d4d5"
>
> It would only be unambigious if you add the information wheather it is
> a two- or three-stone move.

It is unique: c3d5 only refers to c3c4>d4d5. To encode the broadside
move c3c4c5>d3d4d5 you would have to write c5d3. This is because the
number of marbles moved must correspond to the manhattan distance
between FromFirst and ToLast. Quoting the link above: "For inline
moves this is obvious how to interpret the move. For broadside moves
it is not obvious that this notation defines a move. The notation is
made unique by requiring that the number of steps between FromFist and
ToLast must equal number of marbles moved."



> > > BTW, if somebody is interested in the engine/GUI concept and might
> > > want to program such an engine, I'd advise to contact me by e-mail
> > > (Sebastian.Leibnitz{a} googlemail . com)
> >
> > No problem, but since the discussion might interest others why not do
> > it here?
>
> I didn't expect the interest, I'll make it public.
> How best to upload a *.txt file here?

In the files section at http://groups.yahoo.com/group/abalone_prog/files/

--- In abalone_prog@yahoogroups.com, "icyclemort" <Sebastian.Mort@...>
wrote:
>
> Why are messages moderated? It doesnt seem to be group suffering under
> high traffic and it slows down communication...

Only the first message you post is moderated. This is to prevent
spam-bots from creating a new member and posting spam, which have
previously been a problem.

Your second, third, etc. messages are not moderated.

--- In abalone_prog@yahoogroups.com, "peer_sommerlund"
<peer.d.sommerlund@...> wrote:
>
> Hi Sebastian, and welcome.
>
> Good to hear about your ambitions, we will do what we can to help you
> so don't hestiate to use this list.

I will not, though it seems to be rather small at the moment... ;)


> Although Aba-Pro is the official computer champion, the program "My
> Lovely Abalone" by David Malek are probably stronger. A windows binary
> can be downloaded for free from http://www.mogwai.lunarpages.com/lovely/

I already found it after posting my message (too impatient, i am).
Haven't got it running yet, as the automatic setup is not able to
handle proxy servers to access the internet.
I'll get the necessary packages by hand and look very closely.

And, btw, good for Abalone that the field is moving. :)


> > I also want to provide a GUI that'll include a lot more powerful tools
> > for analysis and game/database management.
>
> Great! Could you give us some hints as to how we can access your work?
> Will it be open source? Free download w/o source? Will it be possible
> to buy the program?

It will not be open source. And you'd probably not be very pleased if
it were, because the GUI is written in Delphi/Object Pascal. Delphi is
well suited for RAD, but i suspect that I'd find few volunteers to
help with coding...
If there are Delphi programmers out there, who'd like to help me, I'd
perhaps reappraise my decision.
I've not yet decided upon the free-/shareware issue. Perhaps there
will be two versions. It will probably depend upon the work I'll put
into it and the progress that I make.
All versions under all circumstances will be open and accessible for
engines by other people. There will never be any kind of bias or
exclusive feature only  for my engine.


> > Positionally, I've got a lof of ideas that I'll try and see if they
> > work as well as I hope to.
>
> If you are not afraid of competition, you could try to share the ideas
> here. At least during your entry to the field of Abalone, we may be
> able to save you from the mistakes we have made.

I will do so.
Regarding positional evaluation, many ideas might not be easily used
by other engines, though.
Especially positionaltly algorithms are heavily dependent on the
engine framework, especially the chosen methods of board representation.
Bitboard engines can do eval-stuff that other engines will never be
able to do without a major slowdown.
Engines with a one-dimensonal-array and pregenerated data-tables will
also have different do's and dont's for static eval than engines with
a tri-dimensional board representation, which should be able to
correctly access hexagon field relations...

> > --- GUI/engine/interface ---
> >
> > Engine and GUI are seperated programs and communicate through an
> > interface that is shamelessly based upon the Universal Chess Interface
> > (UCI). I'll publish the sepecification along with the GUI, so if
> > anybody is interested they can then program only an engine and rely
> > upon an existing and powerful GUI. That will also help to make better
> > comparisons between engines (automatic and easy to organize engine
> > matches and tournaments). It should increase the competitve side of
> > Abalone programming and hopefully fuel the field with more enthusiasm
> > and creativity...
>
> This is an excellent idea. I have myself worked on a specification
> that is a mix of UCI and WinBoard, but as you have working code, your
> specification are probably more mature. It would be great if we could
> have one (not two) well documented protocol for this purpose. David
> has also worked on this, but his protocol requires COM and thus is
> Windows only. I have not seen a specification of his protocol, but
> given that we work on a unified protocol it would be nice to mix his
> and your work in the specification. (i.e. does David's protocol
> contain stuff that your protocol lacks or vice versa)

Ughh, COM? :0  Sorry David for my lack of subtetly. I've once done
inter process communication with COM. Even leaving aside the
portability issue it is not your most easy to code IPC. It would
probably scare off a lot of people interested in using an open interface.
I very much prefer the UCI/winboard way of doing it. It is very easy
to use for engine programmers (everbody can deal with standard in- and
output in console applications, no?)

Regarding our sharing of protocolls and subsequent discussion, I am
all for it. :)
I'll probably whip up an alpha version of my Universal Abalone
Interface (UAI) ;p very soon. I'll post it here for discussion within
the week.

> > --- rules ---
> >
> > But I am not so sure about repetition rules. Is the repetition of a
> > position allowed to happen or is there some rule forbidding it or
> > deciding in favor of a draw/or one of the players?
>
> Alas, Abalone desperately needs the 50-move rule from chess. When
> beginning from the classic strarting position games are often drawish,
> and the solution has been to have a referee that penalises players for
> playing too passive!! A most unsatisfying solution.
>
> I would urge the entire Abalone community to implement the 50-move
> rule, and I suggest that any abalone program implements it (but makes
> it possible to disable it). In chess the rule states 50 moves without
> a piece taken or a pawn moved results in a draw. For Abalone it should
> be 50 moves without a piece taken (pushed out) results in a draw.

> The 1993 Waterloo computer competition disallowed repetition. This is
> also a solution, but too hard to verify in human-human games.

The 50-move rule is rather an issue for my next question (dealing with
  not ending games).
With repetion I was solely refering to a (probably) infinite
repetition of moves, where the same board position is reached over and
over again. What happens in the Abalone Comuter Olympiads if two
engines repeat over and over again?
Which result is awarded?


> > What about the length of a game, is there some kind of established
> > maximum number of moves (e.g. without a single lost stone) after which
> > a game is aborted in some kind of way?
>
> no, but a 50-move rule would effective limit it to 11*50 moves.

Yes, I think a 50-move rule would be an effective means of
establishing an upper bound to boredom. And if you are referring to 50
moves=100 ply, I'd also think that is not too short a frame.
I'll probably do so. (and make it switchable and a featured option of
the interface)


> > --- notation ---
>
> Have you read
>
http://148009.aceboard.net/148009-512-179-0-Some-Elements-Programming.htm
>
> I have proposed a simpler notation at
> http://90214.aceboard.net/90214-2318-15375-0-Move-notation.htm

The first didn't contain information about broadside-move-notation,
which is the problem.
The second one did, though.
I am not sure what your simpler notation is, but if it was the
FromFirst>ToLast, then I have to dissappoint you.
That is ambigious and can refer to two distinct broadside move
(2stones and 3 stones in 60° rotated directions).

An example from the standard starting position:

"c3d5" could encode two broadside moves:
"c3c4c5>d3d4d5" and "c3c4>d4d5"

It would only be unambigious if you add the information wheather it is
a two- or three-stone move.


I still consider the broadside-move-notation issue problematic and as
it is fundamental for a common (if we want to) interface, we should
try to find a solution that is both human-readable and unambigious
(preferably both ways; notation> 1 move is a must, but move>1 notation
is also preferable)


> > --- Aba-Pro ---
> >
> > A completely different issue. I have tried to get my hands on Aba-Pro.
> > But the website given seems to be dead. I am close to calling the
> > faculty in Graz directly.
> > Is there currently any way to buy/order Aba-Pro?
>
> The website is down and Tino has left the university. Try mailing Tino
> directly. He is on this list. Tino, can you hear us? :-)


I will, thank you.


> > BTW, if somebody is interested in the engine/GUI concept and might
> > want to program such an engine, I'd advise to contact me by e-mail
> > (Sebastian.Leibnitz{a} googlemail . com)
>
> No problem, but since the discussion might interest others why not do
> it here?


I didn't expect the interest, I'll make it public.
How best to upload a *.txt file here?


Regards,
Sebastian Leibnitz.


PS:
Why are messages moderated? It doesnt seem to be group suffering under
high traffic and it slows down communication...

Hi Sebastian, and welcome.

Good to hear about your ambitions, we will do what we can to help you
so don't hestiate to use this list.


--- In abalone_prog@yahoogroups.com, "icyclemort" <Sebastian.Mort@...>
wrote:
>
>
> Nevertheless, my goal is clear, I want to create an Abalone engine
> superior to Aba-Pro (mid-term) and possibly (hard to judge how
> difficult it is) make it equal or even superior to the cream of human
> players(long term).

Although Aba-Pro is the official computer champion, the program "My
Lovely Abalone" by David Malek are probably stronger. A windows binary
can be downloaded for free from http://www.mogwai.lunarpages.com/lovely/

> I also want to provide a GUI that'll include a lot more powerful tools
> for analysis and game/database management.

Great! Could you give us some hints as to how we can access your work?
Will it be open source? Free download w/o source? Will it be possible
to buy the program?

> Positionally, I've got a lof of ideas that I'll try and see if they
> work as well as I hope to.

If you are not afraid of competition, you could try to share the ideas
here. At least during your entry to the field of Abalone, we may be
able to save you from the mistakes we have made.



> --- GUI/engine/interface ---
>
> Engine and GUI are seperated programs and communicate through an
> interface that is shamelessly based upon the Universal Chess Interface
> (UCI). I'll publish the sepecification along with the GUI, so if
> anybody is interested they can then program only an engine and rely
> upon an existing and powerful GUI. That will also help to make better
> comparisons between engines (automatic and easy to organize engine
> matches and tournaments). It should increase the competitve side of
> Abalone programming and hopefully fuel the field with more enthusiasm
> and creativity...

This is an excellent idea. I have myself worked on a specification
that is a mix of UCI and WinBoard, but as you have working code, your
specification are probably more mature. It would be great if we could
have one (not two) well documented protocol for this purpose. David
has also worked on this, but his protocol requires COM and thus is
Windows only. I have not seen a specification of his protocol, but
given that we work on a unified protocol it would be nice to mix his
and your work in the specification. (i.e. does David's protocol
contain stuff that your protocol lacks or vice versa)

> --- rules ---
>
> But I am not so sure about repetition rules. Is the repetition of a
> position allowed to happen or is there some rule forbidding it or
> deciding in favor of a draw/or one of the players?

Alas, Abalone desperately needs the 50-move rule from chess. When
beginning from the classic strarting position games are often drawish,
and the solution has been to have a referee that penalises players for
playing too passive!! A most unsatisfying solution.

I would urge the entire Abalone community to implement the 50-move
rule, and I suggest that any abalone program implements it (but makes
it possible to disable it). In chess the rule states 50 moves without
a piece taken or a pawn moved results in a draw. For Abalone it should
be 50 moves without a piece taken (pushed out) results in a draw.

The 1993 Waterloo computer competition disallowed repetition. This is
also a solution, but too hard to verify in human-human games.

> What about the length of a game, is there some kind of established
> maximum number of moves (e.g. without a single lost stone) after which
> a game is aborted in some kind of way?

no, but a 50-move rule would effective limit it to 11*50 moves.


> --- notation ---

Have you read
http://148009.aceboard.net/148009-512-179-0-Some-Elements-Programming.htm

I have proposed a simpler notation at
http://90214.aceboard.net/90214-2318-15375-0-Move-notation.htm
>
> --- Aba-Pro ---
>
> A completely different issue. I have tried to get my hands on Aba-Pro.
> But the website given seems to be dead. I am close to calling the
> faculty in Graz directly.
> Is there currently any way to buy/order Aba-Pro?

The website is down and Tino has left the university. Try mailing Tino
directly. He is on this list. Tino, can you hear us? :-)


> BTW, if somebody is interested in the engine/GUI concept and might
> want to program such an engine, I'd advise to contact me by e-mail
> (Sebastian.Leibnitz{a} googlemail . com)

No problem, but since the discussion might interest others why not do
it here?



Regards,
Peer Sommerlund

Hello all!


A quick introduction:

I am new to the field of Abalone programming.

Nevertheless, my goal is clear, I want to create an Abalone engine
superior to Aba-Pro (mid-term) and possibly (hard to judge how
difficult it is) make it equal or even superior to the cream of human
players(long term).

I also want to provide a GUI that'll include a lot more powerful tools
for analysis and game/database management.

To be honest, Abalone programming as of now seems to be a rather loose
field, pursued without the required professional approach.
I've got a lot of chess programming experience, and I am very
confident that I'll be able to deliver a GUI/engine package that is
superior to what is currently available.

I am able to reach higher search depths than current Abalone progs (10
ply I was told in case of Aba-Pro).

Positionally, I've got a lof of ideas that I'll try and see if they
work as well as I hope to.

So, now you're informed about my lofty goals. ;


--- GUI/engine/interface ---


My engine is now up and running fine, although it is still lacking a
lot of basic search algorithm enhancements and Abalone knowledge, but
both will come...

I am still working on the GUI, it'll include a lot more stuff than
current Ablone GUI's. It'll include a lot of stuff that should be
interesting for Abalone players and programmers alike. Analysis Modes,
game/database management, engine matches/tournaments, patzer/reduced
strength computer modes and a lot of interesting stuff that has not
yet made into a single abalone GUI (think chess and chessbase).

Engine and GUI are seperated programs and communicate through an
interface that is shamelessly based upon the Universal Chess Interface
(UCI). I'll publish the sepecification along with the GUI, so if
anybody is interested they can then program only an engine and rely
upon an existing and powerful GUI. That will also help to make better
comparisons between engines (automatic and easy to organize engine
matches and tournaments). It should increase the competitve side of
Abalone programming and hopefully fuel the field with more enthusiasm
and creativity...


--- questions ---

What i noted most about Abalone (in contrast to chess) is the lack of
information even regarding such simple things as rules/notation.

I am currently a bit baffled by Abalone notation and some rules, and
I'd like to clarify those before I move on.

--- rules ---

Rules about movement and win conditions are simple and clear. Perfect.


But I am not so sure about repetition rules. Is the repetition of a
position allowed to happen or is there some rule forbidding it or
deciding in favor of a draw/or one of the players?
If there is no such rule, how are infinite repetitions (nobody willing
to deviate from a position; or even positions where everything but the
a repetition would wreck one side's position) dealt with??


What about the length of a game, is there some kind of established
maximum number of moves (e.g. without a single lost stone) after which
a game is aborted in some kind of way?


--- notation ---

Regarding the board/fields, I follow the Aba-Pro way of doing it.
(That is, the interface specification will; the GUI is customizable
and supports Netablone board noatition)

a1 is bottom/left
i9 is top/right


inline moves and pushes are recorded as following:

a1b2c3>b2c3d4 = a1b2


broadside moves are a bit troubling, because very different notations
seem to be in use:

a1b2c3>b1c2d3

is recorded as:
(1) = a1c3b1 (makes sense to me)
(2) = c3a1d3 (the same but other direction)
(3) = a1c3d3 (less intuitive, IMO)
(4) = c3a1b1 (same as above the other way round)

(1) and (2) are FromFirst/FromLast/ToFirst
(3) and (4) are FromFirst/FromLast/ToLast

I am strongly leaning towards (1) and (2) but would like to hear
recommendations.

Regarding the difference between (1)/(3) and (2)/(4), it is the
question of from where to start counting the stones.
I've read suggestions that the first stone should be the one most
closely to the bottom or the top of the field (both seem to be in use).

Never have I read a suggestion of how to record a move like
(c3c4c5>d3d4d5) where the issue would have to be decided upon a
left/right criteria.

Is there a style that is more commonly used?

BTW, I despise an ambigious style. The interface specification will
certainly not allow more than one way to handle it.

(The GUI will though, there you should and will be able to choose any
kind of notation you wish to, I might even enable custom-build notations.)

So that is the notation issue, thx for reading my rant.


--- Aba-Pro ---

A completely different issue. I have tried to get my hands on Aba-Pro.
But the website given seems to be dead. I am close to calling the
faculty in Graz directly.
Is there currently any way to buy/order Aba-Pro?


--- finishing ---


So, I hope somebody will answer my questions regarding rules and notation.
Don't expect GUI/engine to appear before the end of july/august.

Happy abalone programming!


BTW, if somebody is interested in the engine/GUI concept and might
want to program such an engine, I'd advise to contact me by e-mail
(Sebastian.Leibnitz{a} googlemail . com)


Regards, and bye.

The following abalone_prog poll is now closed.  Here are the
final results:


POLL QUESTION: Do you plan to participate in the 2006 Olympics?

CHOICES AND RESULTS
- Yes, 0 votes, 0.00%
- Maybe, 2 votes, 50.00%
- No, 2 votes, 50.00%

INDIVIDUAL VOTES
- Yes
- Maybe
      - peer.d.sommerlund@...
      - tino.werner@...
- No
      - david.malek@...
      - squalydingo@...


For more information about this group, please visit
http://groups.yahoo.com/group/abalone_prog

For help with Yahoo! Groups, please visit
http://help.yahoo.com/help/us/groups/

I think all you say makes a lot of sense.

I'm still planning to generate knowledge, the daisy "attack" is only true with
the most recent versions of MLA (for which i only focus on belgian daisy for
the time being), it's a question of pondering of the newest concepts in the
evaluation function. At the moment, MLA has even problems winning against
abapro 4.8, due to this same pondering.

The problem I have is that an opening book is based on the current evaluation
function :) If i pick moves in the opening (let's say the top ten moves at some
depth), i have to solve this evaluation issue first :)

I dont think i'll get results concerning the opening before 2 or 3 months
minimum :)

David.



Selon peer.d.sommerlund@...:

> Hi David.
>
> I'm not sure I agree that players are not strong yet. It is true that they
> loose many games to computers. It is also true that there are very few strong
> Abalone players, compared to chess. But you never see two humans use the
> anti-computer tactics against each other (attacking one daisy). This leads me
> to think that anti-computer play is really an inferior tactic.
>
> In chess, you often use computers for situations where they are strong:
> Tactical analysis. You never use them to build opening books. The strong
> Chess programs have manually created opening books. For Othello / Checkers it
> is a different story. Here the tactical strength of computers are so much
> better than humans that it makes sense to generate opening books
> automatically.
>
> But, since there is also very few Abalone programmers, the above is based on
> very few real experiments. The more experiments that are made with automatic
> book generation, the easier is it will be to say something convincing. It
> sounds as if you have only little work left before you have an automatic book
> generation - and it would be really interesting to hear about your
> experience.
>
>
>
> It is interesting to compare the age of strong Abalone players with the age
> of strong chess players. You might argue that the younger the world champion,
> the less important is positional knowledge (or book knowledge) when compared
> to tactical capacity. This may also be due to the fact that the game is only
> 16 years old, so a 16 year career could have been had by a person of age 32
> today.
>
>
> I have found anti-computer tactics effective against Nacre in variations
> where many marbles can be trapped early, e.g. Alien Attack. Have you tried
> any of these against MLA?
>
>
> Regards,
> Peer
>
> -----Oprindelig meddelelse-----
> Fra: abalone_prog@yahoogroups.com
> [mailto:abalone_prog@yahoogroups.com]På vegne af david.malek@...
> Sendt: 18. marts 2006 07:59
> Til: abalone_prog@yahoogroups.com
> Emne: Re: [abalone_prog] Opening book
>
>
> Hi Peer,
>
> My own experience shows, also, that an opening book is not a substitute for
> program weaknesses.
>
> My current problem is that humans have shown, recently, that attacking one of
> MLA's daisies can lead to a fast win against the program. Even if asking MLA
> to
> flee the borders (to some extent lol) during the opening (see the currently
> available build) solved part of the problem, i'm still not satisfied by the
> way
> MLA plays openings.
> [...]
> But we might also think the opening knowledge doesnt exist yet and that it
> has
> to be generated. Players arent that strong yet :)
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hi David.

I'm not sure I agree that players are not strong yet. It is true that they loose
many games to computers. It is also true that there are very few strong Abalone
players, compared to chess. But you never see two humans use the anti-computer
tactics against each other (attacking one daisy). This leads me to think that
anti-computer play is really an inferior tactic.

In chess, you often use computers for situations where they are strong: Tactical
analysis. You never use them to build opening books. The strong Chess programs
have manually created opening books. For Othello / Checkers it is a different
story. Here the tactical strength of computers are so much better than humans
that it makes sense to generate opening books automatically.

But, since there is also very few Abalone programmers, the above is based on
very few real experiments. The more experiments that are made with automatic
book generation, the easier is it will be to say something convincing. It sounds
as if you have only little work left before you have an automatic book
generation - and it would be really interesting to hear about your experience.



It is interesting to compare the age of strong Abalone players with the age of
strong chess players. You might argue that the younger the world champion, the
less important is positional knowledge (or book knowledge) when compared to
tactical capacity. This may also be due to the fact that the game is only 16
years old, so a 16 year career could have been had by a person of age 32 today.


I have found anti-computer tactics effective against Nacre in variations where
many marbles can be trapped early, e.g. Alien Attack. Have you tried any of
these against MLA?


Regards,
Peer

-----Oprindelig meddelelse-----
Fra: abalone_prog@yahoogroups.com
[mailto:abalone_prog@yahoogroups.com]På vegne af david.malek@...
Sendt: 18. marts 2006 07:59
Til: abalone_prog@yahoogroups.com
Emne: Re: [abalone_prog] Opening book


Hi Peer,

My own experience shows, also, that an opening book is not a substitute for
program weaknesses.

My current problem is that humans have shown, recently, that attacking one of
MLA's daisies can lead to a fast win against the program. Even if asking MLA to
flee the borders (to some extent lol) during the opening (see the currently
available build) solved part of the problem, i'm still not satisfied by the way
MLA plays openings.
[...]
But we might also think the opening knowledge doesnt exist yet and that it has
to be generated. Players arent that strong yet :)

Thanks a lot Peer for this analysis.

A few words on the work i've done on these evaluation ideas.

1. Non linear center distance evaluation is an interesting idea. I tried it with
Tino's center of mass computation, it looked good for grouping bad for
priorities, because moving a marble at distance 4 is considered much better that
moving in the center :) I'm convinced that the board is at least quadratic, but
i found no evidence so far.

2. What about neighbors? I call it connectivity.  From my work, connectivity is
extremely important, i've tried several solutions. In MLA 1.8 (the first one
stronger than abapro) neighbor counting was there. Since then, i enhanced it to
indicate that having 2 neighbors is clearly different from having 6 :)
I also built part of my move pruning based on connectivity. I'm working on
version 3 of the connectivity evaluation.

3. I'm working on getting rid of abapro's situation evaluation. But I think Tino
gave the evidence that the center is not the ONLY problem, it's the situation of
your marbles in the "middle" of the opponent's marbles that matters ... so
evaluating the distance of your marbles to the center of mass of the opponent's
group makes a lot of sense to me and evaluating your own disorder (distance from
your center of mass) is a very powerful idea. But some belgian daisy positions
generate "noise" in abapro's evaluation i think. For example marbles almost
lost arent "so" interesting.

4. Phase of the game. MLA uses different settings based on the phase of the
game. The phase of the game is determined based on board situation no move
count. I introduced this mainly because MLA plays middle game like evil,
particularly situations where marbles are completely mixed with the opponent's
marbles. My plan is to try to make transitions between game phases continuous.
But it's hard, due to the "standard-like" position settings i have, the program
can think it's standard, then it's middle game, then standard again, then middle
game, then end game. I'm also working on another "phase" (basically it's more
position categories than phases), based on groups of marbles configuration
(i've built the group counting and size calculation of each group).
For me, using board configurations is only a step to continuous evaluation, if
the position is "about to be" standard like, evaluation settings should be
tuned accordingly. "standard-like" means that the position is too stable.
"endgame" means that the programs advantage is so high that it's time to focus
on ejection. "opening" can be reached only once (at the beginning as long as it
doesnt find "standard" or "middle game") and can be considered as the moves
before the center is occupied.

5. line bonus and line counting. It's clearly out of the scope of my studies. It
came to my mind for standard starting position, as i moved to belgian daisy, i
gave it up. Why do we want 3 marbles lines? Because they cant be pushed and can
push opponent's marbles (1 or 2 marbles), so i've clealry preferred working on
sumitos ;) I'm working hard on this, trying to categorize sumitos, and results
will probably be there (i hope) in MLA 3.0

6. In Stephane's work and Peter Tax's work, what i'm really questioning is the
picking of only a few moves at node level. This i think is wrong based on the
criterias used for selection. But i'd love to see a solution where picking 10
moves (for example) leads to better strength, better depth and better speed.
I'm sure that move picking hasnt been explored enough yet (even if Tino's work
is impressive on node expansion) and is the key to better depths.

7. On another subject: human players. MLA's games on netabalone gives me so much
to think about that i'm not using self play much except when i need to prove the
enhancements i make arent very easy to beat by the previous version. But i
promise programs, whatever the strength should be tested, from the start,
against human players. Faults get obvious after a few games.

David.









The funny thing is that, i've tried non linear things for distance,


Selon peer_sommerlund <peer.d.sommerlund@...>:

> --- In abalone_prog@yahoogroups.com, david.malek@... wrote:
> >
> > Do you know, based on the source code reading, if the evaluation
> function looks
> > very continuous to you? I failed with probcut due to the change in
> the value
> > the loss of a stone creates.
> >
> > I dont want to spend too much time on it Peer if you dont think
> there is
> > evidence of something new and strong. i trust your knowledge ;)
> >
>
> .. a little more info about the work of Stéphane. Note, the following
> is based on simply reading the source. I have not done any more tests
> with the program.
>
>
> The 1.5.3 evaluation functions of Tax abalone are:
> "Paul": Every field has a value that increases with distance from
> edge. The function is 2**dist
>
> "Ross": As Paul, but adds bonus for friendly neighbours. Extra bonus
> for a neighbour on the way to the center. The effect is some
> preference for clusters.
>
> "Bill": As Paul, but computed incrementally for more speed.
>
> "Arnold": As Ross, but uses (1+sqrt(2))**dist for field value [Note:
> Tax claims that this function increases faster than exponential. Not
> true, but it IS faster than 2**x]. Bonus for 3-line, extra bonus if
> it points towards the center. Use "bitneighbours" for faster
> computation.
>
> "Frankie": Sum distance between all friendly pieces (an x**2
> operation) + distance to center.
>
>
> The 2.0 evaluation functions are:
> "FrankieSquare": As Frankie, but using dist**2
>
> "Lancelot": As Arnold, but add detection of flowers = marbles
> surrounded by ennemies. Evaluation dependes on how many moves the
> flower has been present (I guess this is to vary play).
>
> "Nabuchodonosor": Similar to Lancelot, but with some variations. Uses
> different weights depending on phase of game. Detects if all 7 center
> fields + 2 more nearby has been captured. Pushout #5 is valued higher
> than pushout #4 which is higher than the rest. Bonus if 3-line can
> move, extra if it can move towards center, extra extra if it can push
> a marble out. This is a micro-1ply-search :-).
>
> "Hannibal": Linear combination. Value = 55% Nabuchodonosor + 45%
> Frankie
>
> "Epaminondas": Combination of Hannibal, Nabuchodonosor, and
> FrankieSquare. Early games is H. Later is linear combinations of N
> and FS.
>
>
> I haven't seen flower detection before, and also not a dedicated test
> for capturing the center. I suspect that the most strength is
> achieved from the time Stéphane spent on finding good weights and
> combinations of features. This is an important thing to do to get a
> strong program. I think that the work on changing the function as the
> play progresses is important as well. The evaluation function used by
> Werner also changes as the board changes, but it is not dependent on
> the number of moves, only on board content.
>
> Nacre has a "bitneighbour" structure too, but it combines friends and
> foes. The 3-line detection has been part of Nacre, but was removed
> because it reduced the strength. Stéphane combines it with direction
> test and a mobility feature which gives a more detailed picture.
> Nacre has a similar mobility feature which does improve strength, but
> it is almost as expensive to compute as a 1-ply search.
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hi Peer,

My own experience shows, also, that an opening book is not a substitute for
program weaknesses.

My current problem is that humans have shown, recently, that attacking one of
MLA's daisies can lead to a fast win against the program. Even if asking MLA to
flee the borders (to some extent lol) during the opening (see the currently
available build) solved part of the problem, i'm still not satisfied by the way
MLA plays openings.

Months ago i generated a database of all possible moves to depth 7. But i
stopped this work to do something else :) I also asked for access to the
netabalone game database with no success (yet, but i understood there is
nothing but a time constraint for the server guys). There is, also, an abapro
format set of games around, but i have no way to "understand" abapro's binary
game format. But opening book probing is already in my source code, and MS
access database use is also there (1 Gb database for depth 7).

Considering that MLA has a tree data entry feature already (the game window), to
make an opening book tool available, i would need to "compile" this type of tree
to an opening book format (like chess engines that take PGN files to build
opening books) and provide a feature to merge trees / add a set of .GAM files
to an opening book. All this is quite straight forward, MLA's game format is
designed for this (line variations), and it's all XML (lol trees again).

If we think about the database needed to build an opening book, we can notice
that, in fact, we mostly need the first moves (wow impressive idea!!!!), the
players' level and the game result to reach the enter the current abalone
knowledge in our programs.

But we might also think the opening knowledge doesnt exist yet and that it has
to be generated. Players arent that strong yet :)

Based on this (and i've also read the articles from M. Buro), i'm still thinking
:)

But, for sure, i can make MLA's game format syntax available, it is not OS
dependent and publish it on MLA's web site, so that we could exchange games.

David.










Selon peer.d.sommerlund@...:

> Hi david and others.
>
>
> My own work with automatic generation of opening book (based on the paper by
> Michael Buro, 1999) indicated that weak spots in the program is not covered
> by a fully automatic generated book.
>
> Thus, a manually edited book by a strong player will have a strong positive
> bennefit. Even a weak player will have a positive influence :-)
>
> However, I'm not aware of any program that supports editing an opening book.
> AbaPro did have something in 2003, but I don't think this GUI was public
> (please correct me Tino if I'm wrong). You could edit game trees, but it was
> not possible to use this when playing against the program.
>
> Are there anybody on the list that would like to work on a free
> book-editing-GUI? I think David's high quality program is the way to go for
> 98% of the Abalone community but since I myself like to work with Linux I
> wish for a crossplatform open source program. And I suspect Stéphane would as
> well ;-)
>
> Nacre contains a small GUI written in wxWidgets. It compiles on Windows and
> Linux. If anybody else wants to participate in a book-GUI I'm willing to open
> source it.
>
>
> Automatic book generation can also mean the merge of played games. This is
> easy to do and works. However, collecting games is time consuming. Is there
> any interest for a public collection of games, and possible problem
> situations for testing?
>
>
>
>
> -----Oprindelig meddelelse-----
> Fra: abalone_prog@yahoogroups.com
> [mailto:abalone_prog@yahoogroups.com]På vegne af mogwaifrance
> Sendt: 11. marts 2006 13:05
> Til: abalone_prog@yahoogroups.com
> Emne: [abalone_prog] MLA 2.5 final is available
>
>
> Hello, you can download MLA 2.5 in its final build (2.5.4).
>
> I have a bug fix release to be published soon, but I'm cooking 3.0,
> and I'm clearly working on an automatically generated opening book ;)
>
> Any other idea?
>
> You can fill in the online form for suggestions at
>
> http://mogwai.lunarpages.com/lovely/changerequest.htm
>
> Enjoy!
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

--- In abalone_prog@yahoogroups.com, david.malek@... wrote:
>
> Do you know, based on the source code reading, if the evaluation
function looks
> very continuous to you? I failed with probcut due to the change in
the value
> the loss of a stone creates.
>
> I dont want to spend too much time on it Peer if you dont think
there is
> evidence of something new and strong. i trust your knowledge ;)
>

.. a little more info about the work of Stéphane. Note, the following
is based on simply reading the source. I have not done any more tests
with the program.


The 1.5.3 evaluation functions of Tax abalone are:
"Paul": Every field has a value that increases with distance from
edge. The function is 2**dist

"Ross": As Paul, but adds bonus for friendly neighbours. Extra bonus
for a neighbour on the way to the center. The effect is some
preference for clusters.

"Bill": As Paul, but computed incrementally for more speed.

"Arnold": As Ross, but uses (1+sqrt(2))**dist for field value [Note:
Tax claims that this function increases faster than exponential. Not
true, but it IS faster than 2**x]. Bonus for 3-line, extra bonus if
it points towards the center. Use "bitneighbours" for faster
computation.

"Frankie": Sum distance between all friendly pieces (an x**2
operation) + distance to center.


The 2.0 evaluation functions are:
"FrankieSquare": As Frankie, but using dist**2

"Lancelot": As Arnold, but add detection of flowers = marbles
surrounded by ennemies. Evaluation dependes on how many moves the
flower has been present (I guess this is to vary play).

"Nabuchodonosor": Similar to Lancelot, but with some variations. Uses
different weights depending on phase of game. Detects if all 7 center
fields + 2 more nearby has been captured. Pushout #5 is valued higher
than pushout #4 which is higher than the rest. Bonus if 3-line can
move, extra if it can move towards center, extra extra if it can push
a marble out. This is a micro-1ply-search :-).

"Hannibal": Linear combination. Value = 55% Nabuchodonosor + 45%
Frankie

"Epaminondas": Combination of Hannibal, Nabuchodonosor, and
FrankieSquare. Early games is H. Later is linear combinations of N
and FS.


I haven't seen flower detection before, and also not a dedicated test
for capturing the center. I suspect that the most strength is
achieved from the time Stéphane spent on finding good weights and
combinations of features. This is an important thing to do to get a
strong program. I think that the work on changing the function as the
play progresses is important as well. The evaluation function used by
Werner also changes as the board changes, but it is not dependent on
the number of moves, only on board content.

Nacre has a "bitneighbour" structure too, but it combines friends and
foes. The 3-line detection has been part of Nacre, but was removed
because it reduced the strength. Stéphane combines it with direction
test and a mobility feature which gives a more detailed picture.
Nacre has a similar mobility feature which does improve strength, but
it is almost as expensive to compute as a 1-ply search.

Hi david and others.


My own work with automatic generation of opening book (based on the paper by
Michael Buro, 1999) indicated that weak spots in the program is not covered by a
fully automatic generated book.

Thus, a manually edited book by a strong player will have a strong positive
bennefit. Even a weak player will have a positive influence :-)

However, I'm not aware of any program that supports editing an opening book.
AbaPro did have something in 2003, but I don't think this GUI was public (please
correct me Tino if I'm wrong). You could edit game trees, but it was not
possible to use this when playing against the program.

Are there anybody on the list that would like to work on a free
book-editing-GUI? I think David's high quality program is the way to go for 98%
of the Abalone community but since I myself like to work with Linux I wish for a
crossplatform open source program. And I suspect Stéphane would as well ;-)

Nacre contains a small GUI written in wxWidgets. It compiles on Windows and
Linux. If anybody else wants to participate in a book-GUI I'm willing to open
source it.


Automatic book generation can also mean the merge of played games. This is easy
to do and works. However, collecting games is time consuming. Is there any
interest for a public collection of games, and possible problem situations for
testing?




-----Oprindelig meddelelse-----
Fra: abalone_prog@yahoogroups.com
[mailto:abalone_prog@yahoogroups.com]På vegne af mogwaifrance
Sendt: 11. marts 2006 13:05
Til: abalone_prog@yahoogroups.com
Emne: [abalone_prog] MLA 2.5 final is available


Hello, you can download MLA 2.5 in its final build (2.5.4).

I have a bug fix release to be published soon, but I'm cooking 3.0,
and I'm clearly working on an automatically generated opening book ;)

Any other idea?

You can fill in the online form for suggestions at

http://mogwai.lunarpages.com/lovely/changerequest.htm

Enjoy!






Yahoo! Groups Links

Hello, you can download MLA 2.5 in its final build (2.5.4).

I have a bug fix release to be published soon, but I'm cooking 3.0,
and I'm clearly working on an automatically generated opening book ;)

Any other idea?

You can fill in the online form for suggestions at

http://mogwai.lunarpages.com/lovely/changerequest.htm

Enjoy!

Hi David,

Thanks a lot for your email and sharing your ideas!
Unfortunately I haven't programmed for more than a month and haven't even
started to implement hashing.
I have a lot of work at my job at the moment and my girlfriend migrated to my
flat and there was also much to do.

Tino :-)
--------------------------------------------
Dipl.-Ing. Tino Werner
Forschungszentrum Karlsruhe
Inst. f. Angewandte Informatik
Hermann-von Helmholtzplatz 1
D-76344 Eggenstein-Leopoldshafen
tino.werner@...
Tel. +49-7247-825707
Fax. +49-7247-825786
-------------------------------------------



> -----Ursprüngliche Nachricht-----
> Von: abalone_prog@yahoogroups.com
> [mailto:abalone_prog@yahoogroups.com] Im Auftrag von mogwaifrance
> Gesendet: Dienstag, 21. Februar 2006 16:14
> An: abalone_prog@yahoogroups.com
> Betreff: [abalone_prog] Re: Transposition table
>
> Hi Tino,
>
> I'm coming back to you on the hash issue.
>
> I noticed that, before putting my new MLA 2.5 on the web I
> had deleted one hash table feature in MLA (i dont know why
> lol). So i've put it back recently, and compared to the
> behaviour without it => avoiding old entries is important ...
>
> It's called something like a "stale" flag, it indicates if
> the hash entry you are probing is "too old" to be used or not.
>
> This doesnt answer your collision issue but avoids having the
> engine use old entries as good evaluations.
>
> From what i remember, maybe the source code of the crafty
> chess engine can help you also, i think it uses the move
> number in the game (from the start) to "age stamp" entries.
>
> Replacement schemes for hash tables seem to be important for
> MLA (but you know my search algorithm has a very special way
> of exploring node) eg chosing to replace the existing entry
> in all cases or based on conditions.
>
> For the abalone dependent hash function, maybe picking the
> side to move and the contents of "chosen" board fields is
> part of the solution (first idea coming to my mind). For
> chess, side to move, being in check or not, number of
> repetitions, "en passant" possible or not, pawn promotions
> are often used as dedicated bits in the hash function result.
>
> Maybe you're already using this ;) Just trying to share ideas ;)
>
> David.
>
>
>
>
> --- In abalone_prog@yahoogroups.com, "Werner, Tino"
> <tino.werner@...> wrote:
> >
> >
> > Thanks Peer and David for your suggestions!
> >
> > I'm trying to find a more Abalone-specific (kind of sorted) hash-
> function, to prevent hash collisions. Maybe I'll fail.
> >
> > 2 000 000 entries doesn't sounds much. The same for 20 - 30%. But
> the increase in searching speed is more than 20-30%, isn't it?
> >
> > Regards,
> > Tino
> >
> >
> > --------------------------------------------
> > Dipl.-Ing. Tino Werner
> > Forschungszentrum Karlsruhe
> > Inst. f. Angewandte Informatik
> > Hermann-von Helmholtzplatz 1
> > D-76344 Eggenstein-Leopoldshafen
> > tino.werner@...
> > Tel. +49-7247-825707
> > Fax. +49-7247-825786
> > -------------------------------------------
> >
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: abalone_prog@yahoogroups.com
> > > [mailto:abalone_prog@yahoogroups.com] Im Auftrag von
> > > peer.d.sommerlund@...
> > > Gesendet: Mittwoch, 18. Januar 2006 12:20
> > > An: abalone_prog@yahoogroups.com
> > > Betreff: [abalone_prog] Transposition table
> > >
> > > Hi Tino.
> > >
> > > I know the question was directed at David, but let me throw in my
> > > experience:
> > >
> > > Yes, transposition tables are definitly worth the effort. It does
> > > cost some time, but you are rewarded with a significant
> improvement
> > > in search depth.
> > >
> > > For hash function, let me suggest Zorbist hashing. It is fast to
> > > compute and easy to implement.
> > > http://en.wikipedia.org/wiki/Zobrist_hashing
> > >
> > > Regards,
> > > Peer
> > >
> > >
> > > PS. When you addded the 2-ply move ordering by Tax, did you also
> > > search only the 6 best moves to full depth?
> > >
> > >
> > >
> > > -----Oprindelig meddelelse-----
> > > Fra: abalone_prog@yahoogroups.com
> > > [mailto:abalone_prog@yahoogroups.com]På vegne af Werner, Tino
> > > Sendt: 18. januar 2006 11:41
> > > Til: abalone_prog@yahoogroups.com
> > > Emne: AW: [abalone_prog]
> > >
> > >
> > > Hi Peer, David and Stéphane,
> > >
> > > Here a sign of life of me:
> > >
> > > In November I also restarted working on ABA-PRO. Till
> Xmas I spent
> > > much time in finding a better evaluation function. My new
> function
> > > now wins 95% of the games against the old one.
> > > (I've promised David to tell him, when I've implemented one with
> > > 100% ):
> > > Maybe 95% sounds much, but if you also know that the new function
> > > looses always, if it plays with ply i-1, you can see that
> searching
> > > depth is more important:
> > >
> > > Later I changed some things at my data structure which led to a
> > > speed up of only 20%.
> > > I also tried out using old "values of turns". But for using them
> > > without recalculating they are not valid enough. So I
> only used them
> > > to order the evaluations. It gave only a very little speed up.
> > >
> > > Recently I tried out move ordering based on a 2-ply search.
> > > (As it is used in Tax) But the search effort was much higher.
> > > I'm still searching a bug...
> > >
> > > One big thing I want to implement is hashing. I'm expecting much
> > > speed up now, if doing well. David, would you tell me the
> > > time-effect of hashing at MLA?
> > > I'm yet having problems finding a proper hash function.
> > >
> > > Iterative deepening with time limit is another thing I have to do
> > > soon.
> > >
> > > Regards,
> > > Tino
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

I only see advantages to this :)

Abnet become the communication protocol with MLA, and MLA gets the abalone
arena.

I see one issue nevertheless, the requirements I have for the exposed functions
to take full advantage of the GUI.

Like the following functions :

- IsThinking() returns if the engine is still thinking.
- PlayNow() asks the engine to finish thinking immediately (or at least go up
the tree immediately)
- ReturnBesLine() : return the best analysis line
- Reset()
- PlayAMove(colour, max depth, level) : level being beginner, expert of
champion.

I also need the engines to return more info about the move found, allow position
setting.

And so on, what i'm going to do is to list the functions i think could be
exported (some can obviously be ignored by the abnet engine but provided by the
abnet COM thing).

Today, MLA includes a "hub" to my engine, with a very limited number of
functions. This hub calls MLA. I only need the COM class to expose the same
functions as MLA.

lol

David.




Selon peer.d.sommerlund@...:

> Hi David.
>
> I would like to voulenteer a COM component that adapts abnet to your
> interface. This way you would be able to play not only windows engines, but
> also linux and mac engines :-)
>
> Regards,
> Peer
>
> -----Oprindelig meddelelse-----
> Fra: abalone_prog@yahoogroups.com
> [mailto:abalone_prog@yahoogroups.com]På vegne af mogwaifrance
> Sendt: 21. februar 2006 15:56
> Til: abalone_prog@yahoogroups.com
> Emne: [abalone_prog] MLA 2.5 preview 1 is available for download
>
>
> Now, theres is a new version of my engine released last sunday.
>
> You can download it for free at :
>
> http://www.mogwai.lunarpages.com/lovely/
>
> Be sure you pick the right download (depends on the CPU u have).
>
> On the MLA web site you can also report bugs and submit change
> requests. Please USE IT (can also be called from the help menu).
>
> Enjoy !
>
> David.
>
> for all : I'm currently building an abalone arena (ie allow to use
> another engine than mine in the GUI i have to match engines). For
> this i need a volonteer that would like to build a Win32 Visual C++
> COM class with HIS engine embedded in it (with a spec and template
> source code i would give) with a standardized interface to discuss.
> Anyone interested?
>
> for Peer : What's funny is that the "nacre" notation i wanted to
> offer as an option in this version is full of bugs in this
> release :) lol
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hi Tino,

I'm coming back to you on the hash issue.

I noticed that, before putting my new MLA 2.5 on the web I had
deleted one hash table feature in MLA (i dont know why lol). So i've
put it back recently, and compared to the behaviour without it =>
avoiding old entries is important ...

It's called something like a "stale" flag, it indicates if the hash
entry you are probing is "too old" to be used or not.

This doesnt answer your collision issue but avoids having the engine
use old entries as good evaluations.

From what i remember, maybe the source code of the crafty chess
engine can help you also, i think it uses the move number in the
game (from the start) to "age stamp" entries.

Replacement schemes for hash tables seem to be important for MLA
(but you know my search algorithm has a very special way of
exploring node) eg chosing to replace the existing entry in all
cases or based on conditions.

For the abalone dependent hash function, maybe picking the side to
move and the contents of "chosen" board fields is part of the
solution (first idea coming to my mind). For chess, side to move,
being in check or not, number of repetitions, "en passant" possible
or not, pawn promotions are often used as dedicated bits in the hash
function result.

Maybe you're already using this ;) Just trying to share ideas ;)

David.




--- In abalone_prog@yahoogroups.com, "Werner, Tino"
<tino.werner@...> wrote:
>
>
> Thanks Peer and David for your suggestions!
>
> I'm trying to find a more Abalone-specific (kind of sorted) hash-
function, to prevent hash collisions. Maybe I'll fail.
>
> 2 000 000 entries doesn't sounds much. The same for 20 - 30%. But
the increase in searching speed is more than 20-30%, isn't it?
>
> Regards,
> Tino
>
>
> --------------------------------------------
> Dipl.-Ing. Tino Werner
> Forschungszentrum Karlsruhe
> Inst. f. Angewandte Informatik
> Hermann-von Helmholtzplatz 1
> D-76344 Eggenstein-Leopoldshafen
> tino.werner@...
> Tel. +49-7247-825707
> Fax. +49-7247-825786
> -------------------------------------------
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: abalone_prog@yahoogroups.com
> > [mailto:abalone_prog@yahoogroups.com] Im Auftrag von
> > peer.d.sommerlund@...
> > Gesendet: Mittwoch, 18. Januar 2006 12:20
> > An: abalone_prog@yahoogroups.com
> > Betreff: [abalone_prog] Transposition table
> >
> > Hi Tino.
> >
> > I know the question was directed at David, but let me throw
> > in my experience:
> >
> > Yes, transposition tables are definitly worth the effort. It
> > does cost some time, but you are rewarded with a significant
> > improvement in search depth.
> >
> > For hash function, let me suggest Zorbist hashing. It is fast
> > to compute and easy to implement.
> > http://en.wikipedia.org/wiki/Zobrist_hashing
> >
> > Regards,
> > Peer
> >
> >
> > PS. When you addded the 2-ply move ordering by Tax, did you
> > also search only the 6 best moves to full depth?
> >
> >
> >
> > -----Oprindelig meddelelse-----
> > Fra: abalone_prog@yahoogroups.com
> > [mailto:abalone_prog@yahoogroups.com]På vegne af Werner, Tino
> > Sendt: 18. januar 2006 11:41
> > Til: abalone_prog@yahoogroups.com
> > Emne: AW: [abalone_prog]
> >
> >
> > Hi Peer, David and Stéphane,
> >
> > Here a sign of life of me:
> >
> > In November I also restarted working on ABA-PRO. Till Xmas I
> > spent much time in finding a better evaluation function. My
> > new function now wins 95% of the games against the old one.
> > (I've promised David to tell him, when I've implemented one
> > with 100% ):
> > Maybe 95% sounds much, but if you also know that the new
> > function looses always, if it plays with ply i-1, you can see
> > that searching depth is more important:
> >
> > Later I changed some things at my data structure which led to
> > a speed up of only 20%.
> > I also tried out using old "values of turns". But for using
> > them without recalculating they are not valid enough. So I
> > only used them to order the evaluations. It gave only a very
> > little speed up.
> >
> > Recently I tried out move ordering based on a 2-ply search.
> > (As it is used in Tax) But the search effort was much higher.
> > I'm still searching a bug...
> >
> > One big thing I want to implement is hashing. I'm expecting
> > much speed up now, if doing well. David, would you tell me
> > the time-effect of hashing at MLA?
> > I'm yet having problems finding a proper hash function.
> >
> > Iterative deepening with time limit is another thing I have
> > to do soon.
> >
> > Regards,
> > Tino
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

Hi David.

I would like to voulenteer a COM component that adapts abnet to your interface.
This way you would be able to play not only windows engines, but also linux and
mac engines :-)

Regards,
Peer

-----Oprindelig meddelelse-----
Fra: abalone_prog@yahoogroups.com
[mailto:abalone_prog@yahoogroups.com]På vegne af mogwaifrance
Sendt: 21. februar 2006 15:56
Til: abalone_prog@yahoogroups.com
Emne: [abalone_prog] MLA 2.5 preview 1 is available for download


Now, theres is a new version of my engine released last sunday.

You can download it for free at :

http://www.mogwai.lunarpages.com/lovely/

Be sure you pick the right download (depends on the CPU u have).

On the MLA web site you can also report bugs and submit change
requests. Please USE IT (can also be called from the help menu).

Enjoy !

David.

for all : I'm currently building an abalone arena (ie allow to use
another engine than mine in the GUI i have to match engines). For
this i need a volonteer that would like to build a Win32 Visual C++
COM class with HIS engine embedded in it (with a spec and template
source code i would give) with a standardized interface to discuss.
Anyone interested?

for Peer : What's funny is that the "nacre" notation i wanted to
offer as an option in this version is full of bugs in this
release :) lol






Yahoo! Groups Links

Now, theres is a new version of my engine released last sunday.

You can download it for free at :

http://www.mogwai.lunarpages.com/lovely/

Be sure you pick the right download (depends on the CPU u have).

On the MLA web site you can also report bugs and submit change
requests. Please USE IT (can also be called from the help menu).

Enjoy !

David.

for all : I'm currently building an abalone arena (ie allow to use
another engine than mine in the GUI i have to match engines). For
this i need a volonteer that would like to build a Win32 Visual C++
COM class with HIS engine embedded in it (with a spec and template
source code i would give) with a standardized interface to discuss.
Anyone interested?

for Peer : What's funny is that the "nacre" notation i wanted to
offer as an option in this version is full of bugs in this
release :) lol

As you work with Abalone programming you often have to examine
properties of the game, such as how many bits are needed to represent
a move or what is the largest number of moves you have to choose between.

As for encoding of a move I use the following:
6 bits for position on board, 6 bits for direction+movetype:
There are 61 positions on the board, this fits in 6 bits.
There are 6 directions * 10 move types = 60, which also fits in 6 bits

move types:
move 1, 2, 3
push 2-1, 3-1, 3-2
broadside left 2, 3
broadside right 2, 3
Total: 10

12 bits is 4096. If you count moves you see that some 51% or so of
this is used - it is sparse, but you cannot save another bit.

If you encode it as (pos << 6) | ( movetype*6 + direction) you can
compute this with only additions: The movetype is either found
algorithmically when you generate moves, or by look-up. In both cases
you can use a constant which includes the *6 factor. You can change
the order if you use look-up and want to get different cache properties.

One thing that is interesting is to generate push-out moves separately
from the rest of the moves. This allows you to do a quiescence search
easily.



Now, I have a question: What is the largest number of moves you have
to choose between when it is your turn? Of course it must be more than
100 and less than 2000, but how tight can you get? A low value is
useful if you want to allocate a static structure for moves generated
in a position.

No, acctually I was talking about speed skating ;-)

http://www.cs.unimaas.nl/olympiad2006/

Peer

-----Oprindelig meddelelse-----
Fra: abalone_prog@yahoogroups.com
[mailto:abalone_prog@yahoogroups.com]På vegne af david.malek@...
Sendt: 1. februar 2006 09:23
Til: abalone_prog@yahoogroups.com
Emne: skiing? [abalone_prog] New poll for abalone_prog


You mean in Italy this winter? Yeah i'll do bobsleigh ;)

Moggie.

Selon abalone_prog@yahoogroups.com:

>
> Enter your vote today!  A new poll has been created for the
> abalone_prog group:
>
> Do you plan to participate in the 2006 Olympics?
>
>   o Yes
>   o Maybe
>   o No
>
>
> To vote, please visit the following web page:
> http://groups.yahoo.com/group/abalone_prog/surveys?id=12248517
>
> Note: Please do not reply to this message. Poll votes are
> not collected via email. To vote, you must go to the Yahoo! Groups
> web site listed above.
>
> Thanks!
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>





Yahoo! Groups Links

You mean in Italy this winter? Yeah i'll do bobsleigh ;)

Moggie.

Selon abalone_prog@yahoogroups.com:

>
> Enter your vote today!  A new poll has been created for the
> abalone_prog group:
>
> Do you plan to participate in the 2006 Olympics?
>
>   o Yes
>   o Maybe
>   o No
>
>
> To vote, please visit the following web page:
> http://groups.yahoo.com/group/abalone_prog/surveys?id=12248517
>
> Note: Please do not reply to this message. Poll votes are
> not collected via email. To vote, you must go to the Yahoo! Groups
> web site listed above.
>
> Thanks!
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Enter your vote today!  A new poll has been created for the
abalone_prog group:

Do you plan to participate in the 2006 Olympics?

   o Yes
   o Maybe
   o No


To vote, please visit the following web page:
http://groups.yahoo.com/group/abalone_prog/surveys?id=12248517

Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.

Thanks!

Thanks Peer and David for your suggestions!

I'm trying to find a more Abalone-specific (kind of sorted) hash-function, to
prevent hash collisions. Maybe I'll fail.

2 000 000 entries doesn't sounds much. The same for 20 - 30%. But the increase
in searching speed is more than 20-30%, isn't it?

Regards,
Tino


--------------------------------------------
Dipl.-Ing. Tino Werner
Forschungszentrum Karlsruhe
Inst. f. Angewandte Informatik
Hermann-von Helmholtzplatz 1
D-76344 Eggenstein-Leopoldshafen
tino.werner@...
Tel. +49-7247-825707
Fax. +49-7247-825786
-------------------------------------------



> -----Ursprüngliche Nachricht-----
> Von: abalone_prog@yahoogroups.com
> [mailto:abalone_prog@yahoogroups.com] Im Auftrag von
> peer.d.sommerlund@...
> Gesendet: Mittwoch, 18. Januar 2006 12:20
> An: abalone_prog@yahoogroups.com
> Betreff: [abalone_prog] Transposition table
>
> Hi Tino.
>
> I know the question was directed at David, but let me throw
> in my experience:
>
> Yes, transposition tables are definitly worth the effort. It
> does cost some time, but you are rewarded with a significant
> improvement in search depth.
>
> For hash function, let me suggest Zorbist hashing. It is fast
> to compute and easy to implement.
> http://en.wikipedia.org/wiki/Zobrist_hashing
>
> Regards,
> Peer
>
>
> PS. When you addded the 2-ply move ordering by Tax, did you
> also search only the 6 best moves to full depth?
>
>
>
> -----Oprindelig meddelelse-----
> Fra: abalone_prog@yahoogroups.com
> [mailto:abalone_prog@yahoogroups.com]På vegne af Werner, Tino
> Sendt: 18. januar 2006 11:41
> Til: abalone_prog@yahoogroups.com
> Emne: AW: [abalone_prog]
>
>
> Hi Peer, David and Stéphane,
>
> Here a sign of life of me:
>
> In November I also restarted working on ABA-PRO. Till Xmas I
> spent much time in finding a better evaluation function. My
> new function now wins 95% of the games against the old one.
> (I've promised David to tell him, when I've implemented one
> with 100% ):
> Maybe 95% sounds much, but if you also know that the new
> function looses always, if it plays with ply i-1, you can see
> that searching depth is more important:
>
> Later I changed some things at my data structure which led to
> a speed up of only 20%.
> I also tried out using old "values of turns". But for using
> them without recalculating they are not valid enough. So I
> only used them to order the evaluations. It gave only a very
> little speed up.
>
> Recently I tried out move ordering based on a 2-ply search.
> (As it is used in Tax) But the search effort was much higher.
> I'm still searching a bug...
>
> One big thing I want to implement is hashing. I'm expecting
> much speed up now, if doing well. David, would you tell me
> the time-effect of hashing at MLA?
> I'm yet having problems finding a proper hash function.
>
> Iterative deepening with time limit is another thing I have
> to do soon.
>
> Regards,
> Tino
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

MLA uses hash tables with zobrist keys (random not fixed), and one additional
hash lock in each hash entry.

usually, MLA runs with 2 000 000 hash entries.

amongst all positions examined about 20% to 30% are directly found in the hash
table with no further calculations. each hash entry stores only one nr for
alpha,beta, value, depth => the type of entry (lower or higher bound or exact)
and either alpha, beta or the value and the depth . these figures are with my
"own" version of the MTD(f) search. so not a clear indicator.

the current storing scheme for MLA's hash is "NEW" (any deep enough figure
replaces the current entry)

i can give you more precise figures if you wish for iterative search if you
wish.

hash tables are more than worth a try. but i've been fixing bug for months to
get the hash table work properly, i dont know why, but this was the most
unstable part of MLA.

david




Selon peer.d.sommerlund@...:

> Hi Tino.
>
> I know the question was directed at David, but let me throw in my experience:
>
> Yes, transposition tables are definitly worth the effort. It does cost some
> time, but you are rewarded with a significant improvement in search depth.
>
> For hash function, let me suggest Zorbist hashing. It is fast to compute and
> easy to implement.
> http://en.wikipedia.org/wiki/Zobrist_hashing
>
> Regards,
> Peer
>
>
> PS. When you addded the 2-ply move ordering by Tax, did you also search only
> the 6 best moves to full depth?
>
>
>
> -----Oprindelig meddelelse-----
> Fra: abalone_prog@yahoogroups.com
> [mailto:abalone_prog@yahoogroups.com]På vegne af Werner, Tino
> Sendt: 18. januar 2006 11:41
> Til: abalone_prog@yahoogroups.com
> Emne: AW: [abalone_prog]
>
>
> Hi Peer, David and Stéphane,
>
> Here a sign of life of me:
>
> In November I also restarted working on ABA-PRO. Till Xmas I spent much time
> in finding a better evaluation function. My new function now wins 95% of the
> games against the old one. (I've promised David to tell him, when I've
> implemented one with 100% ):
> Maybe 95% sounds much, but if you also know that the new function looses
> always, if it plays with ply i-1, you can see that searching depth is more
> important:
>
> Later I changed some things at my data structure which led to a speed up of
> only 20%.
> I also tried out using old "values of turns". But for using them without
> recalculating they are not valid enough. So I only used them to order the
> evaluations. It gave only a very little speed up.
>
> Recently I tried out move ordering based on a 2-ply search. (As it is used in
> Tax) But the search effort was much higher. I'm still searching a bug...
>
> One big thing I want to implement is hashing. I'm expecting much speed up
> now, if doing well. David, would you tell me the time-effect of hashing at
> MLA?
> I'm yet having problems finding a proper hash function.
>
> Iterative deepening with time limit is another thing I have to do soon.
>
> Regards,
> Tino
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Hi Tino.

I know the question was directed at David, but let me throw in my experience:

Yes, transposition tables are definitly worth the effort. It does cost some
time, but you are rewarded with a significant improvement in search depth.

For hash function, let me suggest Zorbist hashing. It is fast to compute and
easy to implement.
http://en.wikipedia.org/wiki/Zobrist_hashing

Regards,
Peer


PS. When you addded the 2-ply move ordering by Tax, did you also search only the
6 best moves to full depth?



-----Oprindelig meddelelse-----
Fra: abalone_prog@yahoogroups.com
[mailto:abalone_prog@yahoogroups.com]På vegne af Werner, Tino
Sendt: 18. januar 2006 11:41
Til: abalone_prog@yahoogroups.com
Emne: AW: [abalone_prog]


Hi Peer, David and Stéphane,

Here a sign of life of me:

In November I also restarted working on ABA-PRO. Till Xmas I spent much time in
finding a better evaluation function. My new function now wins 95% of the games
against the old one. (I've promised David to tell him, when I've implemented one
with 100% ):
Maybe 95% sounds much, but if you also know that the new function looses always,
if it plays with ply i-1, you can see that searching depth is more important:

Later I changed some things at my data structure which led to a speed up of only
20%.
I also tried out using old "values of turns". But for using them without
recalculating they are not valid enough. So I only used them to order the
evaluations. It gave only a very little speed up.

Recently I tried out move ordering based on a 2-ply search. (As it is used in
Tax) But the search effort was much higher. I'm still searching a bug...

One big thing I want to implement is hashing. I'm expecting much speed up now,
if doing well. David, would you tell me the time-effect of hashing at MLA?
I'm yet having problems finding a proper hash function.

Iterative deepening with time limit is another thing I have to do soon.

Regards,
Tino



Yahoo! Groups Links

Hi Peer, David and Stéphane,

Here a sign of life of me:

In November I also restarted working on ABA-PRO. Till Xmas I spent much time in
finding a better evaluation function. My new function now wins 95% of the games
against the old one. (I've promised David to tell him, when I've implemented one
with 100% ):
Maybe 95% sounds much, but if you also know that the new function looses always,
if it plays with ply i-1, you can see that searching depth is more important:

Later I changed some things at my data structure which led to a speed up of only
20%.
I also tried out using old "values of turns". But for using them without
recalculating they are not valid enough. So I only used them to order the
evaluations. It gave only a very little speed up.

Recently I tried out move ordering based on a 2-ply search. (As it is used in
Tax) But the search effort was much higher. I'm still searching a bug...

One big thing I want to implement is hashing. I'm expecting much speed up now,
if doing well. David, would you tell me the time-effect of hashing at MLA?
I'm yet having problems finding a proper hash function.

Iterative deepening with time limit is another thing I have to do soon.

Regards,
Tino

Yes, I agree that the statistics I provided it not sufficient to warrant a firm
conclusion. On the other hand, I had so many problems with Tax looping (refusing
to play a move) so I would not give any more significance to my results than the
vague formulation I used.

I have been very sceptic about the search algorithm: 1 or 2 ply search for
ordering, follwed by full search of 6 first moves. My initial thought was that
it introduces too much tactical weakness. It DOES seem that 4 ply extra is
enough to compensate for this, though, but I still expect a match between 8 ply
MLA vs 8 ply Tax to be at least 60% win for MLA. Primarily because of the
tactical weakness of the search.

Earlier I built an evaluation function that could beat AbaPro 4.8 if the search
depth was the same. It was much slower, so in real games it would neve win. I
did some experiments with different ply settings: 1 extra ply gave app 60% win,
2 extra ply gave >90% win.

For a fair comparison between two programs we should always use time limited
search, as this is what we use in tournaments. It is not interesting to know
that Nacre 9 ply vs MLA 9 ply is a 99.99% win to Nacre, if Nacre takes 1000
times as long as MLA to do 9 ply.

Stéphane, it is possible for you to implement a timed search? I expect that the
gInterrupted variable almost does this, but you probably need to add an
iterative deepening.

I will send you some patches when the time permits, and also give you a note
about the reasons behind the changes. I'm using CodeBlocks with the gcc and MSVC
compilers. My primary compiler is gcc. The patches builds a commandline version
of Tax with abnet. This allows me to do automated games.

I have not dived deper into the evaluations functions. As far as I recall most
are variations of known themes. When I have the time I will write a short note.

David, I think that you can probably gain the most by reading the code. The real
strength comes from a combination of search and evaluation. For example, Nacre
has a relatively strong evaluation, but the time it uses is better spent on
deeper search.

Regards,
Peer

-----Oprindelig meddelelse-----
Fra: abalone_prog@yahoogroups.com
[mailto:abalone_prog@yahoogroups.com]På vegne af david.malek@...
Sendt: 18. januar 2006 01:39
Til: abalone_prog@yahoogroups.com; Stéphane Nicolet
Emne: Re: [abalone_prog] Strength of Tax 2.0


Peer,

What concerns me is the most of the time and the imprecise time measure. And
i've tried probcut with no interesting result :) with very detailed stats.

Do you know, based on the source code reading, if the evaluation function looks
very continuous to you? I failed with probcut due to the change in the value
the loss of a stone creates.

What development tool are u using, is this is a Microsoft C++ kind of tool? If
yes, can you send me a copy of the source code or do you recommend me to build
it in MLA for the purpose of testing based on the possible strength you have
seen in Tax? in your humble opinion?

Is there a way you can give test stephane's stuff against a nacre level i could
understand as well? ("about four plies"). Or a MLA 2.0a (latest build on the
web) 2 secs level for example and save the game with MLA ?

or stéphane, can you send me the latest C++ source code(.tar) for me to try to
compile it in my .NET environement? or even simply i could rewrite the
evaluation function (please point which one to me) based on my data structures
and amend my node selection to include it in my search framework with hash and
stuff (iterative, aspiration, MTD(f) etc) ? and tell u about the results ?

I dont want to spend too much time on it Peer if you dont think there is
evidence of something new and strong. i trust your knowledge ;)

to stéphane: if you brought something new, congratulations in advance. i'm dying
to claim the "MLA loses against Steph's Abalone", because this would mean we are
all going somewhere :) i have problems finding interesting ideas for MLA (except
the depth 10 statistical cut, ie the funnel with a completely different criteria
thing i'm working on).

david

PS : stéphane : buy yourself a PC lol ;)




Quoting Stéphane Nicolet <cassio@...>:

>
> Le 16 janv. 06 à 22:39, peer_sommerlund a écrit :
>
> > I have run some test of Tax 2.0 against Nacre, and the results
> > seem to be that Tax wins most of the time. I have not run
> > enough games to be certain of the result.
>
> Thank you very much for the pain you've spend on it, Peer.
> It's nice both for me, because I'm happy to learn that the
> new evaluation functions in Tax's Abalone seem to be competitive,
> and for you, because you have another beast to test against.
> By the way, don't hesitate to borrow ideas or implementation
> details in the evaluation, if adequate.
>
>
> > I tried all the new strategies. However, many of the games
> > were not completed because Tax looped. I don't know if this
> > is a known bug or one that I have introduced.
>
> Tax is not allowed to generate a move that would repeat the
> position (a sort of "super-Ko" rule, as they would say in Go).
> The function it is supposed to call are "MoveIsKo" and "BoardIsKo"
> in board.c.
>
> On the other hand, sometimes Tax gets the center and *apparently*
> doesn't do much for a fair couple of moves (but without repeating
> the position in a strict sense). The more advanced strategies,
> however, then very slowly increase the ejection threat coefficient,
> so Tax should eventually get nervous and eject a ball.
>
>
> > (For those that does not know Tax abalone: It defines a
> > "strategy" as a combination of search function, evaluation,
> > and a few other things). The configuration was a 1 sec/move
> > blitz game. Tax does not have time limited play, so I just
> > picked a search depth that used about the right amount of
> > time. The depth for Tax was 6-8 ply, depending on strategy.
> > The depth of Nacre was about 4 ply.
>
>
> Of course, since last week, I changed some stuff in the search
> functions (better ordering, and ProbCut, essentially) and the
> search speed is now ~ 3 times faster :-) Maybe you could send
> me your patch, so that I incorporate it in Tax Abalone source
> code ? That way we could share improvements more easily, in
> both directions.
>
> Anyway, thanks again for the tests :-)
>
> Sincerely yours,
> Stéphane
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ... /// ... \\\ ...
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>





Yahoo! Groups Links

Peer,

What concerns me is the most of the time and the imprecise time measure. And
i've tried probcut with no interesting result :) with very detailed stats.

Do you know, based on the source code reading, if the evaluation function looks
very continuous to you? I failed with probcut due to the change in the value
the loss of a stone creates.

What development tool are u using, is this is a Microsoft C++ kind of tool? If
yes, can you send me a copy of the source code or do you recommend me to build
it in MLA for the purpose of testing based on the possible strength you have
seen in Tax? in your humble opinion?

Is there a way you can give test stephane's stuff against a nacre level i could
understand as well? ("about four plies"). Or a MLA 2.0a (latest build on the
web) 2 secs level for example and save the game with MLA ?

or stéphane, can you send me the latest C++ source code(.tar) for me to try to
compile it in my .NET environement? or even simply i could rewrite the
evaluation function (please point which one to me) based on my data structures
and amend my node selection to include it in my search framework with hash and
stuff (iterative, aspiration, MTD(f) etc) ? and tell u about the results ?

I dont want to spend too much time on it Peer if you dont think there is
evidence of something new and strong. i trust your knowledge ;)

to stéphane: if you brought something new, congratulations in advance. i'm dying
to claim the "MLA loses against Steph's Abalone", because this would mean we are
all going somewhere :) i have problems finding interesting ideas for MLA (except
the depth 10 statistical cut, ie the funnel with a completely different criteria
thing i'm working on).

david

PS : stéphane : buy yourself a PC lol ;)




Quoting Stéphane Nicolet <cassio@...>:

>
> Le 16 janv. 06 à 22:39, peer_sommerlund a écrit :
>
> > I have run some test of Tax 2.0 against Nacre, and the results
> > seem to be that Tax wins most of the time. I have not run
> > enough games to be certain of the result.
>
> Thank you very much for the pain you've spend on it, Peer.
> It's nice both for me, because I'm happy to learn that the
> new evaluation functions in Tax's Abalone seem to be competitive,
> and for you, because you have another beast to test against.
> By the way, don't hesitate to borrow ideas or implementation
> details in the evaluation, if adequate.
>
>
> > I tried all the new strategies. However, many of the games
> > were not completed because Tax looped. I don't know if this
> > is a known bug or one that I have introduced.
>
> Tax is not allowed to generate a move that would repeat the
> position (a sort of "super-Ko" rule, as they would say in Go).
> The function it is supposed to call are "MoveIsKo" and "BoardIsKo"
> in board.c.
>
> On the other hand, sometimes Tax gets the center and *apparently*
> doesn't do much for a fair couple of moves (but without repeating
> the position in a strict sense). The more advanced strategies,
> however, then very slowly increase the ejection threat coefficient,
> so Tax should eventually get nervous and eject a ball.
>
>
> > (For those that does not know Tax abalone: It defines a
> > "strategy" as a combination of search function, evaluation,
> > and a few other things). The configuration was a 1 sec/move
> > blitz game. Tax does not have time limited play, so I just
> > picked a search depth that used about the right amount of
> > time. The depth for Tax was 6-8 ply, depending on strategy.
> > The depth of Nacre was about 4 ply.
>
>
> Of course, since last week, I changed some stuff in the search
> functions (better ordering, and ProbCut, essentially) and the
> search speed is now ~ 3 times faster :-) Maybe you could send
> me your patch, so that I incorporate it in Tax Abalone source
> code ? That way we could share improvements more easily, in
> both directions.
>
> Anyway, thanks again for the tests :-)
>
> Sincerely yours,
> Stéphane
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ... /// ... \\\ ...
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>