That got me wondering: what if you find yourself programming something for which being fast is more important than being exactly right?
This is not an entirely unfamiliar trade-off: everytime you use a double instead of a decimal you decide that fast calculations are more important than exact decimal representation of your numbers. And the UDP protocol foregoes transmission verification for speed.
In the past we would write asynchonous function calls somewhat like this:
(Now with async/await, things are different again. Well, they look different.)
// Start reading from that slow file system var fileStream = new System.IO.FileStream(@"C:\blablah", System.IO.FileMode.Open, System.IO.FileAccess.Read); var asyncResult = fileStream.BeginRead(blahblah ...); // Do lots of stuff in between to maximize your efficiency // And now you just need your data, so for the rest of the // time you're synchronously waiting for it to arrive fileStream.EndRead(asyncResult);
That's fine and dandy if you're just reading data. But what if you're calculating something on another thread, and you've already found your result, but the caller hasn't asked for it yet? Maybe you could spend your time improving your result rather than twiddling your thumbs.
So we need a method that iteratively improves on its previous results, and returns each so that we have something to return. Obviously I chose pi (using Microsoft.SolverFoundation.Common):
(using BBP formula)
static IEnumerable<Rational> GetPi()
{
Rational bigPi = new Rational();
Rational bigMinusOne = -1;
Rational bigOne = 1;
Rational bigTwo = 2;
Rational bigFour = 4;
Rational bigFive = 5;
Rational bigSix = 6;
Rational bigEight = 8;
Rational bigSixteen = 16;
for (int i = 0; i < 10000; i++)
{
Rational bigI = i;
Rational powI;
Rational.Power(16, i, out powI);
var bigS = (bigOne / powI) * (bigFour / ((bigEight * bigI) + bigOne) - (bigTwo / ((bigEight * bigI) + bigFour)) - (bigOne / ((bigEight * bigI) + bigFive)) - (bigOne / ((bigEight * bigI) + bigSix)));
bigPi += bigS;
// We don't want to return anything less than 7 hexadecimal digits
if (i > 7)
yield return bigPi;
}
}
Sooo, up to ten thousand hexadecimal digits (hexits?) of pi generated as a decimal fraction. Now to write a wrapper class that runs this in a loop in another thread:public sealed class IncreasinglyAccurate<T>
{
private Func<IEnumerable<T>> _generator;
private Thread _generatorThread;
private bool _hasValue = false;
private T _currentValue;
public IncreasinglyAccurate(Func<IEnumerable<T>> generator)
{
if (generator == null)
throw new ArgumentNullException("generator");
_generator = generator;
// returns as soon as the generator thread is started
GetValues();
}
private void GetValues()
{
// Spinning up a new thread is wasteful, but I can't set priority
// on work items added to the threadpool
_generatorThread = new Thread(delegate()
{
foreach(T value in _generator()){
_currentValue = value;
_hasValue = true;
}
});
_generatorThread.Priority = ThreadPriority.BelowNormal;
_generatorThread.Start();
}
public T GetValue()
{
// wait for a value
while (!_hasValue)
{
Thread.Sleep(1);
}
// delegates will need to expect a ThreadAbortException
_generatorThread.Abort();
_generatorThread.Join();
return _currentValue;
}
}
/// <summary>
/// Little wrapper to get generic type inference
/// </summary>
public static class IncreasingAccuracy
{
public static IncreasinglyAccurate<S> FromDelegate<S>(Func<IEnumerable<S>> generator)
{
return new IncreasinglyAccurate<S>(generator);
}
}
That looks about right. Now we should be able to use this as follows:
var piGenerator = IncreasingAccuracy.FromDelegate(GetPi); // Do some work! System.Threading.Thread.Sleep(50); Console.Write(piGenerator.GetValue().ToString());
On my slow old computer that shows a very big number divided by another big number (probably a power of 16!). Increasing the sleep time increases the size of the number, so that looks right.
I'll grant you that pi digits are not that useful; I'm not sure when you would ever need more than, oh, 10 digits max. But I can think of some situations where it's useful to have a sufficient answer fast, but to keep thinking about a better one: AI, voice recognition, anything that will not be 100% perfect in a hurry.
