one seemingly overlooked aspect of the whole "speed vs. devel. time"
argument is that in order to actually *test* to see how strong your code
is, you need to compete with it. once you do so, you will immediately
see how cycles matter.
i only know this because i've done some testing of various go engines,
of different flavors, and having to calculate how to compensate for the
cpu speed differences is nontrivial. compilation differences, cpu differences,
cpu clock differences, etc. can all add up to actual, readily measurable
differences in playing strength.
i don't think that anyone is suggesting that they want to write some code
that loses all of its games but is written in the uber-coolest way known
to man. so let's imagine that you want to beat, say, a very weak opponent.
you play against it and note that you're only winning 50% of
your games. and it's an opponent that plays random moves. you note
that given the time constraints, the problem is simply that you aren't
able to evaluate enough positions quickly enough, so you make it 10%
faster and it starts winning 75% of its games. voila!
in my experience, this is actually what actually happens.
eventually speed increases don't help as much and you need to come up
with some other cool trick. but regardless of how you implement it,
at some point you're going to want to test it against other players. and
because it's a new trick that will make your code better, it'll eventually
benefit from more cycles as well.
unless, of course, you have an algorithm that is strong and somehow
*independent of the clock available to the algorithm*. that sounds more
like a proof than an algorithm to me, and i think that'd be very interesting.
s.
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
