The functions as defined by your initial algorithm used the sum notation,
which means we needed to maintain a list of samples for the resource. I.e.
the cost functions identified were a function of the resource and time of
request. The more samples maintained, the less efficient the cache evaluation
became.
yes, I see your point. I think it's entirely possible to use a windowed version of the sum without degrading much the results (but this is, again, a wild guess, this should have to be tested). that means, just sum the last n terms, not more.
Which comes to the conclusion I came up with last night. In the wonderful world of audio, average loudness is measured by a meter that reports the RMS of a particular period. RMS (Root Mean Square) is used because dB is a logarithmic function of sound intensity--it matches the problem space better. The set of samples used depends on how quickly we want the meter to adjust to the signal. For example, a 100ms window will always evaluate the last 4,410 samples with CD quality audio. This seems to provide a nice balance for seeing the immediate intensity of the audio, and still not being thrown off by the peaks. However when you are level matching, you want your meters to adjust more slowly, so extending the window to 3s provides a much slower changing average which allows you to more accurately match the levels.
Taking this further, it is important to know the peaks so that we can make sure that we are not overloading the system, so modern professional digital meters have a peak hold function as well as an overload indicator. It is important to note that the overload detection can be adjusted. For example, one sample reaching maximum amplitude does not necessarily indicate an overload. Even two samples are not an authoritative measure. Three or more samples at maximum amplitude are a certain metric that we are overloading our A/D converters. You will never hear the clipping of three samples, but audio engineers interested in the best quality music they can produce will set the overload indicator function so that they know when they absolutely have to do a retake.
Considering that overloading is important, the raw measure of the amplitude (i.e. peak metering) is far less useful. Trying to match the audio intensity using peak meters will give you a false sense of the match. You might be able to get the peaks to match, but your ears will tell you that one is still louder than the other.
The concept translates over to the adaptive cache approach at almost 1:1. The actual individual cost sample is not important. It is the windowed average that is important. For our cache a simple mean would best suit our problem space. The size of the window for our samples will control how responsive our cache control algorithm is. This would affect your cache prediction algorithm as the value k is no longer needed to control responsiveness. The value k can be set at 0, 1, or 0.5 depending on how you want to affect the slope. IMO, the window size should be the determining factor at how the average cost for a resource will converge toward the optimal point. Large window sizes provide slower response, while a smaller window provides faster response.
I'm thinking about implementing the cache separately from cocoon to see if the math behind it works or not. If you have code to share, that would be wonderful (you can place it in the scratchpad if you want)
Ok. Let me package this later today. I have a meeting for the next 3 hours.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin