🚀 go-pugleaf

I must object to the following formula in SelectMove() that computes the
time estimate for the next depth:
 1)	(int) ((double)1.93913099l * (pow ((double) et, (double)1.12446928l)))
The numeric parameters were probably derived from an analysis of search 
times for various depths on the authors machine.  However, formula 1
is non-linear with respect to processor speed.

The formula should have a form of:
 2)	et * f(et/bt, depth)
where et is the elapsed time for the current depth and
bt is a constant base time for the processor used.

A simple form of this is:
 3)	et * f(depth)

This doesn't involve deriving bt for the processor and f(depth) can be
represented by a table of constants.

An even simpler form is:
 4)	et * m / n
where m and n are integer constants.

Of course formulas 3 and 4 may be to simple to give a reasonable estimate
and other parameters such as start_stage may be found more important
in computing the time estimate.

I don't have the data or analysis tools needed to conjure up the parameters
for a new estimator.  Perhaps there is someone just looking for a small project
that could work on this.

	-- Dan Oetting <oetting@gldfs.cr.usgs.gov>

PS: Unless you have analyzed a Billion searches the parameters in formula 1
    are over stating the known precision.