Arimaa Forum (http://arimaa.com/arimaa/forum/cgi/YaBB.cgi)
Arimaa >> Bot Development >> Haizhi's Arimaa Project
(Message started by: 99of9 on May 23rd, 2005, 6:03pm)

Title: Haizhi's Arimaa Project
Post by 99of9 on May 23rd, 2005, 6:03pm
Hey Haizhi,

Weren't you at one time working on an Arimaa bot as a project for your university degree?  How did that go?  Is your thesis available online?  I'm sure many of us would be interested to read it.

Thanks
Toby

Title: Re: Haizhi's Arimaa Project
Post by omar on May 30th, 2005, 6:13pm
You might want to ask this as a comment to one of his games. He might see it sooner.

Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 6th, 2005, 1:39am
Thank you for remembering me and my bot, 99 and omar.

I am still working on building the bot ( in fact rebuilding it). A lot of stuff happend, I haven't graduated from UA, not yet, but got a very busy job a year ago, struglling in 2 frontiers ( in fact there were 3, I also got a familly to take care of). I couldn't give up my arimaa project, I selected it as my gruaduate thesis topic.  Couldn't make out a showable bot ( and a MSc. thesis) in 3 years, I am the worst student of Jonathan's.

Thanks Fotland, I read his paper, it makes me rebuild my program. I found I made some fatal mistakes at the very biginning, for example, my search was move-based, not step-based! It hundreds times slower.

His evaluation function is really impressive. How can he do a 6-step local trap search, or a 8-step goal search? that is totally unthinkable to me.  I spent a month but could not make out a 4-step one.

I spend a lot of time to adjust feature weights as well, didn't work. Jonathan suggest that I should try TD(lamda), let the machine do it for me.

Jonathan said searching deeper would beat a better evaluation function, so that  was what I have been trying to do. Unfotunately it is very hard for arimaa, what make it worse is that I do have some ideas, but  each one takes a lot of time to test.

Still a lot of stuff to do. But this  years tounament I am sure my bot will show up.


Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Jun 6th, 2005, 4:42am

on 06/06/05 at 01:39:21, haizhi wrote:
Thank you for remembering me and my bot, 99 and omar.


How could we forget the 48-hour Arimaa marathon man?

I'll look forward to seeing your bot in action later this year.  By the way, I made the same mistake of using move-based search when I first started (that's what Gnobot_2004 was).

Congratulations on your family and your job.  Some things are more important than arimaa :-).

Title: Re: Haizhi's Arimaa Project
Post by PMertens on Jun 6th, 2005, 9:26am

Quote:
Jonathan said searching deeper would beat a better evaluation function


I sincerely doubt that

Title: Re: Haizhi's Arimaa Project
Post by jdb on Jun 6th, 2005, 3:52pm
I must agree with PMertens. There are several common features in games that require evaluation. Hostage pieces, elephant blockades and rabbit formation to name a few.

Clueless uses the move based approach in several places. The more I work on clueless, the more move based stuff seems to get added. Whether it will work out in the end is another story.


Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 6th, 2005, 11:17pm
Well, my english is not good enough, maybe I wasn't make it very clear.

About the "knowledge vs search", Jonathan got that idea in his early years experince in building chess program.  Being a strong chess player himself, he once tried putting a lot of knowledge into the program, and found it doesn't work well. Another version that could search a little deeper tend to be much stronger.

He always emphasize the huge difference that  search one ply deeper will create, and suggested me not putting a lot into the evaluation.  But for Arimaa, searching deep is really difficult, I guess so far 12 step per min is the best we can hope. And we have to put much more stuff into the eva, otherwise the bot won't attack. The situation is like in GO.


I think Jonathan as a AI researcher has a tendency of loving those "brute-force" stuff, like history-heuristic, pattern database...for their high adapabilty.  He doesn't show much interest in GO research,  the reason I belive is same.

In his book he said he didn't trust marchine feature weight tuning much, I guess he already changed this opinion. He instructed one of his PhD student applied TD(lamda) on his chinook program, the result was very promising, they even published a paper on that.

Jonathan is alway very good to me, so I really want do somthing (academically) to repay him.

Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Jun 7th, 2005, 1:48am

on 06/06/05 at 01:39:21, haizhi wrote:
I am the worst student of Jonathan's.


Even if this is true, there's no shame in being the worst of a fantastic bunch.  I've read a number of papers from Jonathan's group, and they were all impressive.

Regarding machine feature-weight tuning.  I tried a very primitive version of this, but I found that I got much greater improvements by simply adding more features that I knew about.  I agree that it's important to tune your weights, but I found that I could do that quite effectively by hand after watching a few games my bot played.

Title: Re: Haizhi's Arimaa Project
Post by Fritzlein on Jun 7th, 2005, 6:09pm

on 06/06/05 at 15:52:44, jdb wrote:
I must agree with PMertens. There are several common features in games that require evaluation. Hostage pieces, elephant blockades and rabbit formation to name a few.

Clueless uses the move based approach in several places. The more I work on clueless, the more move based stuff seems to get added. Whether it will work out in the end is another story.


My intuition is very strong that move-based approach is better than a step-based approach.  But why do I think this? I have neither practical experience nor any convincing theory.

Also I have a similarly strong intuition that bots need to get smarter more desperately than they need to get faster, and in particular that bots are too stupid at present to do much helpful pruning.  Again, I have neither practical experience nor any convincing theory to support this position.

Probably both of my biases are based on nothing more than an assumption that computers need to think more like I think in order to play Arimaa better.  :-)

Title: Re: Haizhi's Arimaa Project
Post by omar on Jun 7th, 2005, 9:55pm

on 06/07/05 at 18:09:15, Fritzlein wrote:
Also I have a similarly strong intuition that bots need to get smarter more desperately than they need to get faster, and in particular that bots are too stupid at present to do much helpful pruning.  Again, I have neither practical experience nor any convincing theory to support this position.


I think Bomb's participation in the postal tournament was a good experiment in this regard. Since the humans were thinking for a few minutes about their move and Bomb was thinking for a few hours about it's move, the situation was as if Bomb was running on much faster hardware. I remember seeing a comment that David Fotland made after seeing some of Bombs loses in the postal games that having Bomb run faster to search deeper would not be of much use and that the place to focus for future improvements was in the evaluation.

Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 8th, 2005, 12:27am
[I remember seeing a comment that David Fotland made after seeing some of Bombs loses in the postal games that having Bomb run faster to search deeper would not be of much use and that the place to focus for future improvements was in the evaluation]

I don't agree with you guys on that. The problem in Arimaa is that the branching fator is so huge that even give a computer days it still searches very shallow. I guess in a postal game Bomb still cannot search more than 16 steps (4 moves). Deep blue and Chinook can easily search 16-18 moves every minute, that is a huge difference.

I doubt the potential of improvements in the evaluation, you put more stuff in it, the program will become slowerand slower, and there are too many exceptions.


Title: Re: Haizhi's Arimaa Project
Post by Fritzlein on Jun 8th, 2005, 1:04am

on 06/08/05 at 00:27:35, haizhi wrote:
Deep blue and Chinook can easily search 16-18 moves every minute, that is a huge difference.


Well, certainly, if you could make a computer that would search 16 moves (eight moves for each side) in Arimaa, it could be a very, very strong opponent even if its evaluation function were very stupid (for example only goal and material, nothing positional).  I don't dispute that (16-move search + dumb evaluation) would overwhelm a bot with (4 move search + smart evaluation), as well as overwhelming all human players.

But how can you possibly get a computer to search that deep?  No computer on Earth is fast enough to look at that many positions even just for goal.  The only way to get deep search is to prune away bad moves, and right now Arimaa bots are too stupid to prune away bad moves.

Since you can't look at all moves deeply, how can you tell an Arimaa bot which moves to look at deeply?  For chess it is pretty easy to prune based on material only.  Also one can do search extensions based on forcing moves likes captures and checks only.   A simple (i.e. stupid) idea can do lots of useful pruning for chess.  But in Arimaa there are rarely credible goal threats in the opening, and often no captures for ten or twenty moves.  The computer might have a totally losing position before it gets tactical enough to prune away bad moves by any simple idea.

In short, it seems to me that a smarter evaluation is needed, not so much at the end of the search tree as in the middle to tell which moves are worth examining.  If you could generate a list of only, say, 100 moves in every position which are worth looking at, that would be a huge accomplishment.  But how can one do that by any simple means?

To put my argument another way, the dichotomy of deep search vs. smart evaluation seems false in the case of Arimaa, because it seems to me that you can't even get deep search unless you first have smart evaluation.  Please enlighten me if I am missing the point.  :-)

Title: Re: Haizhi's Arimaa Project
Post by jdb on Jun 8th, 2005, 8:32am
There are a few other types of moves that can be called second rate, even in the opening. Moves likes captures and freezing an enemy piece are usually worth investigating.

Here is a list of types of moves one could prune/sort moves on:  (in no particular order)

a) does it capture a piece?
b) does it suicide a piece?
c)  is it a goal threat?
d) does it allow an enemy goal threat?
e) does it advance a rabbit?
f)  does it advance an enemy rabbit?
g) how does the move effect elephant mobility?
h) does it place a major piece in a risky location?
i) does it threaten an enemy major piece?
j) does it threaten to capture an enemy piece?
k) does it allow the enemy to threaten an enemy piece?
l) does it send a minor piece off the back three ranks?
m) reversible moves

This list is by no means exhaustive. All of these items can be approximated relatively quickly and would help to focus the search on moves that are more likely to be reasonable.


For example, in the opening sending a piece (other than the elephant) down the board on its own, could be flagged as highly questionable and given only brief consideration.


Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 9th, 2005, 1:10pm

on 06/08/05 at 01:04:51, Fritzlein wrote:
In short, it seems to me that a smarter evaluation is needed, not so much at the end of the search tree as in the middle to tell which moves are worth examining.  If you could generate a list of only, say, 100 moves in every position which are worth looking at, that would be a huge accomplishment.  But how can one do that by any simple means?


Fritzlein , the way you descript is so-called "forward pruning", it seems natual as it is the way that human play games, but unfortunately it doesn't work well in game building. The problem is: even you are 95% confidence that the best move is in your 100 selected moves, if the search goes 10 ply deep, the chance that you finally miss that move is about 40%. The normal "after search" evaluation function can be rough, but this "before search" evaluation must be almost 100% accurate to really work, which is impossible, otherwise we don't need any search). That is the reason that usually people don't do it in the game building.

The biggest problem in letting the program have heavy knowledge is that the exceptions. A move that lost your elephant is bad, but in the case of supporting a rabbit to reach the goal it is not. You will end up putting more and more context into the program, that cannot last forever.

My point is, beside improving the evaluation function, I belive we still have a big potential in the search itself. We know that changing the search from move-based to Step-based alone makes it hundreds time faster, Transportation table, null move, move ordering ( iterative deepenning, killer moves, history heuristic)...all these methods enable us to search 12-step, but they are not the end of the story, what we need is to discover more methods to reach deeper.

Title: Re: Haizhi's Arimaa Project
Post by jdb on Jun 9th, 2005, 3:09pm
Haizi, your comments regarding forward pruning are correct, when applied to games such as chess.

However, in arimaa, forward pruning may have a better chance. The search depth is, say, about 4 full moves. There are about 5000 moves in a standard position. (That is 5000 different reachable board positions). That leaves an ~81% chance of the PV having all best possible moves.

I also agree with you, that there are certain situations where search is required.

Time will tell what approach(es) work well. Best of luck with your arimaa program.

Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Jun 10th, 2005, 12:49am

on 06/08/05 at 08:32:18, jdb wrote:
There are a few other types of moves that can be called second rate, even in the opening. Moves likes captures and freezing an enemy piece are usually worth investigating.

Here is a list of types of moves one could prune/sort moves on:  (in no particular order)

a) does it capture a piece?
b) does it suicide a piece?
c)  is it a goal threat?
d) does it allow an enemy goal threat?
e) does it advance a rabbit?
f)  does it advance an enemy rabbit?
g) how does the move effect elephant mobility?
h) does it place a major piece in a risky location?
i) does it threaten an enemy major piece?
j) does it threaten to capture an enemy piece?
k) does it allow the enemy to threaten an enemy piece?
l) does it send a minor piece off the back three ranks?
m) reversible moves

This list is by no means exhaustive. All of these items can be approximated relatively quickly and would help to focus the search on moves that are more likely to be reasonable.

n) does it reduce or increase the number of pieces guarding a home trap?
o) does it reduce or increase the number of pieces attacking an enemy trap?  (0 is normal, 1 non-elephant is usually bad, 2 is usually an interesting idea, 3 is usually good.)



Quote:
For example, in the opening sending a piece (other than the elephant) down the board on its own, could be flagged as highly questionable and given only brief consideration.

How does "brief consideration" work?  I once tried putting something in where those lines were simply searched less deeply.  The problem was, in a position where loss of a camel was forced (at depth 8 ), my bot would suicide rabbits... because given that suiciding a rabbit is a "bad thing", those lines were only searched to depth 6 say, and the evaluation was still better than a lost camel.

I suppose I need some rule to say that when you reach a leaf node of a "bad" line, if the evaluation is not good, it is automatically very bad?

Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Jun 10th, 2005, 3:02am
And even if the evaluation is good at that leaf, you have to expand the leaf to the correct depth to make sure it's still good?

Title: Re: Haizhi's Arimaa Project
Post by jdb on Jun 10th, 2005, 8:34am

Quote:
How does "brief consideration" work?


This is what I am working on in clueless now, so these ideas are still under development.

Take the current position and determine all possible moves. Now apply whatever ranking criteria (for example the list a thru o) Start searching with the best moves. This is implemented as a layer on top of the alpha/beta search. If you get a good move on the shallow search, search it deeper. This way a poor move doesn't get alot of time spent on it. True, it could miss some flashy sacrifice, but those types of moves don't seem to be too common in arimaa.


A possible fix for suiciding rabbits:

       // Check for windmill
       // 1) Black elephant is touching trap
       // 2) >=2 black pieces touching trap
       // 3) =1 white defender touching trap
       // 4) >=1 white frozen 2 steps from trap

If this condition exists, the white defender is probably committing suicide. Clueless penalizes this big time.


Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Jun 10th, 2005, 9:25am

on 06/10/05 at 08:34:38, jdb wrote:
True, it could miss some flashy sacrifice, but those types of moves don't seem to be too common in arimaa.


I think the most important sacrifice bots need to know about is when to leave a framed piece.  (Bots think that is a major material sacrifice... which it kind of is, but it has to be done - you just have to carefully choose when to do it.)

Title: Re: Haizhi's Arimaa Project
Post by Fritzlein on Jun 15th, 2005, 12:54pm
Thanks for the explanation of forward pruning and its drawbacks, Haizhi.  Also thanks for clarifying that your target is more like 16 steps than 16 moves.  I am very interested to see how your fast bot performs relative to the slower bots with more built-in knowledge.

Title: Re: Haizhi's Arimaa Project
Post by RonWeasley on Jun 27th, 2005, 12:19pm
In a separate thread, Arimanator writes about accepting trades when ahead and declining trades when behind.  Muggles know about this, but it's not on jdb's list.  Do any of the bots consider this?

Title: Re: Haizhi's Arimaa Project
Post by jdb on Jun 27th, 2005, 1:20pm

Quote:
...accepting trades when ahead and declining trades when behind...


I think there is more to it than that. Once the board clears, the number of pieces becomes more important and their actual rank less so. Trading down too many pieces could give the weaker side a chance to slip a rabbit through.

I would be interested to hear what others think is the correct strategy for a material advantage.

Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 27th, 2005, 8:51pm
That is the "dynamic piece value" idea. I think Clauchau brought this idea long time ago, but so far nobody try much on it.

I doubt even Deepblue had that feature, it is much harder than looks like to implement and tune.

Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Jun 27th, 2005, 9:24pm

on 06/27/05 at 20:51:29, haizhi wrote:
That is the "dynamic piece value" idea. I think Clauchau brought this idea long time ago, but so far nobody try much on it.

I doubt even Deepblue had that feature, it is much harder than looks like to implement and tune.

From memory dynamic piece value was about the fact that when MH is traded with MH, horses now take on the role of camel in all evaulation.  Similarly, if your opponent has lost HHDD, your D's are worth exactly the same as your H's.  That kind of stuff - anything based on the fact that an arimaa piece's power is only relative to the power of the other pieces on the board.

I agree that is difficult to implement.

However if I understand right, Jeff is talking about something different, which is much easier to implement:

Consider the trade: get an M, lose CC.  Should you do it?
The answer is: Sometimes.

At the start of the game, getting a camel is definitely a good thing.  A camel is thus nominally "worth" more than C+C.

BUT

Just say these were the only pieces left on the board, apart from the elephants, and say 2 rabbits each.  Now the exchange is much more dubious, and I'd say usually the wrong thing to do.  The reason is that C+C has the advantage that it is 2 pieces not one, and can play a role in 2 different regions of the board.

To put this term into an evaluation function is easy.  To get it exactly right may be a little harder ;-).  Basically you just add a term f(N) which is a function of the number of pieces this player has on the board.  As long as the gradient of this term is positive, and decreasing with increasing N - I think you'll be in the right ballpark.

For example:
f(N) = -A/N
where A is a positive constant and N is the number of pieces you have on the board.

positive gradient = better to have more pieces
decreasing gradient = this matters less when lots of pieces are on the board, and more when less pieces are on it

Given that you will use TD(lamda), an extra parameter won't hurt you, so perhaps raise N to the power of P in that equation, and let us know what the best values of A and P turn out to be ;-).

Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 27th, 2005, 10:56pm
Good idea.  "-A/N" is ok for TD, but I am afraid we cannot get the best "P" value, because it is not a feature weight at all.  If we have to set it down, what is your best guess, 99?

I need to think more about your equation, it is just seems too simple to work well.

Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Jun 28th, 2005, 12:26am

on 06/27/05 at 22:56:01, haizhi wrote:
"-A/N" is ok for TD, but I am afraid we cannot get the best "P" value, because it is not a feature weight at all.  If we have to set it down, what is your best guess, 99?

Ohh... so weights aren't just parameters, they literally have to be a linear prefactor in TD(l)??
My best guess is P=1.0, but I don't really have a strong sense - it could be anywhere from 0.1 to 4.0 that works best.


Quote:
I need to think more about your equation, it is just seems too simple to work well.

Haha, don't be scared of simplicity!
Another simple function you could consider is
f(N) = A log_b(N)
which also obeys the increasing with decreasing gradient rule.  This one returns (-infinity) at N=0... so naturally knows that the game is over ;-).  Use b~2.

Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 28th, 2005, 2:11am

on 06/28/05 at 00:26:17, 99of9 wrote:
Ohh... so weights aren't just parameters, they literally have to be a linear prefactor in TD(l)??
My best guess is P=1.0, but I don't really have a strong sense - it could be anywhere from 0.1 to 4.0 that works best.


Yap. The "P" value is not something can be meatured in diffrent positions, so TD() cannot update its value based on evaluation score.

I think I have a  problem of a strong tendency to make every design "complete".  To me, the above idea "natually" leads to a 16*16 matrix, which is a little too big...

That is why I have 400 feature weights and the number is increasing. Comparately Jonathan's Chinook only has 23 features.

I got to study thinking simply....


Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 28th, 2005, 2:26am
Maybe I did not make the TD() clear, I don't what mislead you.  

To use TD, a feature must can be meatured in any given board positions, for example: in position (A) there is a rabbit at rank 7,  if there is a fearture called "rabbit at rank 7", the number of that featured will be marked one, and the TD() will adjust the weight of this feature based on the eva score of the postion (A).

Of couse we can have features much more complicate. Clearly the "N" value is also a legal feature.

About the "P" value, it doesn't has anything to do with the board positions, so in TD() it will be treated as a constant.

Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Jun 28th, 2005, 2:49am
I think I'll just have to take your word for it.  

In my thinking P is like a weight, I'm not claiming it's like a feature.  Weights are multiplied by the number of times a feature occurs to get a score.  P, instead of multiplying, is simply the power to which the number of features is raised.  Both are constants for a given evaluation.

My question comes down to whether TD() is a linear model only, or allows fitting of a non-linear model such as a power.

For that matter -A/N is already nonlinear in N, because it is inverse.  Are you sure you can deal with this, even when P is set to be a constant?

In this case the feature is simply "white piece".  N is the number of white pieces.  Usually a linear model would then say that the eval for these features is:
E = wN
where w is the weight of this feature.

I understand that you could turn it into a linear model by making 16*16 features.  The first called "one white piece and 16 black pieces", where the number of occurrences of this feature is always either 0 or 1.  But as you say, that overcomplicates things by adding hundreds of tuneable constants.

If non-linear TD has not yet been invented, I suggest that this should be the centrepiece of your arimaa-beating bot :-).  I'm sure that would win you a masters degree.

Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 28th, 2005, 3:28am
You are right, I was wrong, the number "A" is also not a feature and doesn't suit TD().

The probelm is not linear or not, is can this "feature" be measured in a given position.

Give my any board position I can tell you how many rabbits in rank 7, but I cannot tell how many "P" or "A" occured in this position, they don't change based on the postions.

The only thing here can be use as a feature is "N", and we can directly set 16 or 16*16(consider both side) weights accordingly, and use TD() to tune these weights.

Title: Re: Haizhi's Arimaa Project
Post by haizhi on Jun 28th, 2005, 3:43am
After I carefuly read what you wrote again, I will say, since you described it that way, then in my understanding TD() is a linear system, non-linear is not supported here.

Sorry for reply too fast.

There is a big name in our department knows those stuff very well, Machael Buro, his world champion program has over 1 million weights that auto tuned.

I don't like these "run a month to get a result" methods.

Title: Re: Haizhi's Arimaa Project
Post by jdb on Jun 28th, 2005, 6:12am

Quote:
I understand that you could turn it into a linear model by making 16*16 features.


Its interesting the difference in approaches.

My initial thought was to make a 16*16 lookup table, as you suggest, and fill in the values by hand. This way it is easy to see what each parameter is. If the bot overvalues 12 pieces vs 10, one can just change that parameter. Tweaking an equation, for me, would be much harder on my brain.


Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Oct 10th, 2005, 7:59pm
I just finished reading Haizhi's thesis.  I think one of his most important contributions is this:

He noticed that very rarely is a move played (in a human game) where all 4 steps are unconnected.  Usually there is a push, a pull, a double, triple or quadruple single-piece move, or an unfreeze-then-move combination.  However, his computer calculates that a large proportion of the possible moves actually do have all 4 steps unconnected.

He believes that humans are objectively correct to basically ignore these possibilities.  The rationale he gives is that it's rare for single steps (often in unconnected regions of the board) to all be vital all at once.

Because of the vast potential savings in the number of moves he must consider, he totally cuts such moves out of his move generator.

I hope that summary does justice to his important contribution.  Now, here are my questions to you all:

1) Do humans ignore these possibilities because they are nearly always objectively worse than moves including a "step-combo"?  Or do they just ignore them because they're focussed on acheiving a particular goal at a particular time, and cannot keep 4 different plans in their mind at once?

2) Do you think bomb plays 4-unconnected's with the same frequency that an 1800 rated human does?

3) Can you think of some simple examples where a 4-unconnected is undoubtedly the best move?

4) Can you find some "normal" game positions where a 4-unconnected is undoubtedly the best move?

I must say, that although I had a previous hazy understanding of this phenomenon, I had never even considered making use of it within a bot.  Even if Haizhi is a bit optimistic to completely cut these moves out, he's definitely onto something, and at the very least, they should be demoted in search importance.

Title: Re: Haizhi's Arimaa Project
Post by nbarriga on Oct 10th, 2005, 9:38pm

on 10/10/05 at 19:59:11, 99of9 wrote:
I just finished reading Haizhi's thesis. .


Is it available online somewhere?

Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Oct 10th, 2005, 9:50pm

on 10/10/05 at 21:38:53, nbarriga wrote:
Is it available online somewhere?

www.cs.ualberta.ca/~haizhi/zzz.doc

Title: Re: Haizhi's Arimaa Project
Post by Fritzlein on Oct 11th, 2005, 12:58am

on 10/10/05 at 19:59:11, 99of9 wrote:
3) Can you think of some simple examples where a 4-unconnected is undoubtedly the best move?


How about this one?

Gold (to move) Rc1 Rf1 Hc4 Mf4 Ec8 Cf8
Silver mb4 eg4 rb7 re7

With four single steps Gold can guard all four traps and freeze both of Silver's rabbits.  But this position is very contrived.  I think it quite likely that the search speedup is worth completely ignoring the four-independent-step moves in practice.  I concur that it's a very original and important idea.

Title: Re: Haizhi's Arimaa Project
Post by Fritzlein on Oct 11th, 2005, 1:04am
Oh, that reminds me of a potentially important improvement to bot_haizhi that is potentially easy to implement.  He gives a horse hostage a value of zero, which is roughly correct when the horse is held hostage by an elephant, but when a camel holds a horse hostage it is a significant positive.  Not all horse hostages are created equal.

I'd even consider noting that a camel holding a dog hostage isn't as good as a horse holding a dog hostage, but that doesn't have nearly the same significance in an age of frequent elephant/horse attacks.

Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Oct 11th, 2005, 3:04am
Yes, I am also interested in whether Haizhi plans to continue developing his bot now that he's got his degree.

Title: Re: Haizhi's Arimaa Project
Post by 99of9 on Oct 13th, 2005, 12:12am

on 10/11/05 at 00:58:56, Fritzlein wrote:
How about this one?

Gold (to move) Rc1 Rf1 Hc4 Mf4 Ec8 Cf8
Silver mb4 eg4 rb7 re7

Yep, that seems pretty clear :-).  I suppose if you scatter a few extra pieces around the board, a position like that even looks vaguely normal.

Title: Re: Haizhi's Arimaa Project
Post by omar on Oct 14th, 2005, 5:48pm
I don't think humans discount unconnected moves. If the situation requires it, they will consider them. I think such moves become critical in situations where both players have advanced rabbits and there are goal threats. You use some steps for defense and some for offense. The offensive steps are typically unconnected from the defensive steps. However, I think Haizhi is correct in that most of the time the moves are connected. This is a great contribution and should make the bots stronger. It will be interesting to see how bot_Haizhi will do in this years computer tournament.





Arimaa Forum » Powered by YaBB 1 Gold - SP 1.3.1!
YaBB © 2000-2003. All Rights Reserved.