Storing computed values in an array In several places I need to compute the next value, given a N:

double size = 1.0 / Math.Pow(2, N);


Since I won't be computing this value for N > 15 I have thought of the following performance optimization:

    public static readonly double[] RegionSizes =
{
    1, 0.5, 0.25, 0.125, 0.0625, 0.03125, 0.015625, 0.0078125,
    0.00390625, 0.001953125, 0.000976563, 0.000488281, 0.000244141, 0.00012207, 0.00006103515625, 0.000030517578125
};


//Usage
    double size = RegionSizes[N];


Is this a good solution? Why / why not?
It isn't a good solution and there are several reasons.

1.: Your values are less precise than what the double data type allows for. For example, 

1.0 / Math.Pow(2, 12)


computes to 0.000244140625, while your lookup value is just 0.000244141. Depending on the following calculations, this can make quite a big difference. 

2.: Your array is public and mutable. While the array reference is readonly (so you can't assign a new array to the reference), the array itself is not. For example

RegionSizes[2] = 5;


compiles and runs without any problems. You (or every other dev) can override values in the array as he desires. Better use an immutable collection, like ReadOnlyCollection&lt;double&gt;, to prevent your cached values from manipulation during runtime. (If this is a little fun-project with you as the only dev this might not become a problem; in bigger projects with >1 dev this type of oversight can lead to hard-to-track bugs.)

3.: Experience tells that assumptions like 


  I won't be computing this value for N > 15


do not always hold true. To be sure, a more flexible approach (like calculating every value once it's first needed, then store it and use it when needed again) would allow for more flexibility. Of course, without any information about what you intend to do in your program it's hard to tell if this is relevant.

4.: I strongly suspect you are doing premature optimizations (because you mention neither actual performance problems, nor any measurements indicating that floting-point operations are the cause for such problems). Donald Knuth said 


  The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.


and I have nothing to add. From my experience, in >95% of all software projects you don't need to worry about the performance of >95% of your code. So when making an optimization, you should follow these steps:


Set a realistic measurable performance goal. This is important, you can optimize code forever, so you have to have some definition of 'good enough' and stop once your code is good enough.
Measure if there is an actual performance problem (by comparing actual performance to your definition of 'good enough').
Identify the parts of your code that cause the performance problem; that involves measuring again. For example measure how much time the program spends in each method, then measure how much time the operations in the slow methods take. Do this until you know for sure what makes your program run slow.
Optimize the code that you found out to be slow in step 3 and measure again, to make sure your optimizations are making your code run faster (it's suprising how many 'optimizations' actually make things worse).
Go back to 2.


Yes, I know, optimizing code is fun - but you can quickly get lost and spend hundreds of hours optimizing code that never needed any optimization.