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
I think that's somewhat contrived as well. I don't have that good idea
about all the populat computer go algorithsm, do you have example of
reasonably performing algorithm with these properties?
A standard alpha-beta driven search takes exponentially more time
with search depth, so an
Dave Dyer wrote:
I think that's somewhat contrived as well. I don't have that good idea
about all the populat computer go algorithsm, do you have example of
reasonably performing algorithm with these properties?
A standard alpha-beta driven search takes exponentially more time
with
A standard alpha-beta driven search takes exponentially more time
with search depth, so an exponential increase in speed results in
a very small incremental improvement in seeing'. Improvements
in the quality of the evaluation at anything less than exponential
cost more effective at
Dave Dyer wrote:
A standard alpha-beta driven search takes exponentially more time
with search depth, so an exponential increase in speed results in
a very small incremental improvement in seeing'. Improvements
in the quality of the evaluation at anything less than exponential
cost more
Don Dailey wrote:
Dave Dyer wrote:
A standard alpha-beta driven search takes exponentially more time
with search depth, so an exponential increase in speed results in
a very small incremental improvement in seeing'. Improvements
in the quality of the evaluation at anything less than
