This has been an issue I have been struggling with for a while. There are many well packaged indicators available, who's code appears to be correct, and yet the values do not seem to match any charting software I use. Here is what I have discovered:

There are two types of indicators:
1) Those who's current value is calculated based on its own previous value.
ex: EMA,RSI,ADX,ATR,etc [ema = (1-expConstant) * ema + expConstant * quote;]
2) Those who's current value is not calculated based on its own previous value.
ex: SMA [sum += quote; sma = sum / divisor;]

The problem arises during the iterations when the number of samples is less than the specified period. At this time the values of the indicator will be incorrect, which is why the "ready" bool is added, so that you can wait until it has enough data. For the type 2 indicators listed above, once it is ready it will be 100% accurate. The type 1 indicators on the other hand, will still be basing their values on the previous incorrect values, and so the resultant values will still have some error built in. This bias will be worst at the ready signal, and will approach 0 at infinite sample size.

One solution:

Never re-initialize these indicators at the start of each day, but instead have the values carry over from previous days, and test using a large enough number of days to avoid this bias (based on the largest indicator/timescale you are using).

An example:

Let's assume after 25 periods there would be no bias. (I'm not sure how many periods it would take to reach our .01 accuracy, it would need to be experimentally determined.)
EMA(20) + 1 min scale = 1.3 days until accurate
EMA(20) + 5 min scale = 6.4 days until accurate
EMA(20) + 15 min scale = 19.2 days until accurate
EMA(20) + daily scale = 500 days until accurate
EMA(200) + daily scale = 5000 days until accurate <-- Basically, large indicators cannot be used because of this.

A potential workaround:

If we could input a pre-calculated value when initializing the indicator, it would always be 100% accurate with no need for a "ready" signal delay, at the cost of being more annoying to setup. So potentially this should be an optional field, for those of us who want accuracy and/or no delay. It would go something like this:

ExponentialMovingAverage ema = new ExponentialMovingAverage(200,123.45m);