I will now see if we run into a similar problem using ResponseTimeEstimator for pDNF (epDNFGivenNotSearchFailed).
And indeed we do. To see why, let's assume that we are repeatedly reporting the same key (or very close to the same key) to ResponseTimeEstimator for different instances of DNF:s or non-DNF:s. Let's also assume that the key we are reporting on has a point very close to it in the estimator graph. AFAICS, here's how it works. On each iteration, the estimator adjusts the point's "TimeEstimate" (which is really a probability, pDNF, in this case):
epDNF := epDNF + (value-epDNF) / (sensitivity + 1) * 3/4
where epDNF is the estimator's estimate of pDNF, value is the report (1 for DNF, 0 for no DNF), sensitivity starts out low but rises to a max of 10 the more reports we make. So if we assume we've made a bunch of reports already, sensitivity=10, and we end up with
epDNF := 0.93*epDNF + 0.07*value
which is equivalent to a DecayingRunningAverage with a decayFactor=0.07. We end up with the same problem as we did with DecayingRunningAverage.
The trouble now is how to fix it? To fix DecayingRunningAverage, it was easy to make a copy of it and create SelfAdjustingDecayingRunningAverage. But perhaps that was bad coding practice, since it involved duplication of code. To do the same thing with ResponseTimeEstimate would duplicate a *huge* amount of code. We should probably refactor (right word?) s.t. DecayingRunningAverage and ResponseTimeEstimate both have the abililty to optionally SelfAdjust.
(While we're at it, we should also add a report() method that allows the user to temporarily reduce the decayFactor. That would be useful in situations where, for example, we receive two consecutive QR's. If they are close in time we want the 2nd one to count for less in the estimation of pQueryReject.)
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
