RSquared-indicator-value-different-from-WL6

Oh, and it would be nice to have a .Value member function for RSquared as well in WL7. WL6 has one.

Moreover, WL7 has a .Value member function for LRSlope, so it stands to reason an accompany .Value member function would exist for RSquared as well. (And my DLL library can use it as it does in WL6.)

QUOTE:
The difference comes from using population method to calculate standard deviation in WL6 and sample method in WL7.

It would have been nice if that was documented somewhere in the QuickRef. Since my N is fairly small, N=4, this calculation difference will be significant. And it makes me wonder what kind of R-squared Math.Net is returning?

I also have an R-squared returned by Math.Net for a polynomial fit, but N=10 there, so the calculation difference isn't that big a deal. I would like to use a larger N for the 1st-degree linear fit, but stocks trailing upward don't stay linear for that long. And yes, I know about the regularized EMA indicator WL has, RegEMA, and taking an R-squared of that fit (which would probably be the best compromise). I'll need to think more about this more. In theory, the regularized EMA fit should be more reliable than the polynomial fit, but it's not easy to justify that to the casual observer.

Thanks for adding a .Value method to RSquared.

QUOTE:
It would have been nice if that was documented somewhere in the QuickRef.

Good point, added a note to StdDev's description that it uses sample standard deviation.

QUOTE:
added a note to StdDev's description that it uses sample standard deviation.

Well, add that calculation note to the RSquared indicators description too. I'm just wondering if both indicators, StdDev and RSquared, should offer a choice of either the sample or population calculation. The sample approach can be the default approach.

For my purposes, I would prefer the population approach here because I want to compare the 1st-degree fit (N=4) to the polynomial fit (N=10). With the sample calculation for the 1st-degree fit, I can no longer do that.

QUOTE:
I'm just wondering if both indicators, StdDev and RSquared, should offer a choice of either the sample or population calculation. The sample approach can be the default approach.

Yes it's possible - look for it in Build 15.

It's the strangest thing, but both statements below return exactly the same value in Build 15.

CODE:
using WealthLab.Core;
using WealthLab.Backtest;
using WealthLab.Indicators;

namespace WealthScript2
{
    public class MyStrategy : UserStrategyBase
    {      
      public override void Initialize(BarHistory bars)
        {
         WriteToDebugLog(RSquared.Value(bars.Count-1, bars.Close, 4, StdDevCalculation.Sample));
         WriteToDebugLog(RSquared.Value(bars.Count-1, bars.Close, 4, StdDevCalculation.Population));
      }

      public override void Execute(BarHistory bars, int idx) { }
    }
}

Interesting indeed. But I don't see any error there.

QUOTE:
But I don't see any error there.

Ha, ha. Well, since the population calculation is dividing by N and the sample calculation is dividing by N-1, their numbers should be different in all cases.

I think you're getting the sample calculation 100% of the time since none of the number agree with WL6, which employs the population calculation.

Use the RSquared.Series method

CODE:
         int bar = bars.Count - 1; 
         WriteToDebugLog(RSquared.Series(bars.Close, 4, StdDevCalculation.Sample)[bar]);
         WriteToDebugLog(RSquared.Series(bars.Close, 4, StdDevCalculation.Population)[bar]);

There's an error in the Value method, which I think we should remove (or change completely) for RSquared because the Value method is calculating multiple series to return the single RSquared value.

Let's remove it.

As we dig in to the RSquared calculation, we're not liking what we're seeing. We'll follow up with more later after we get this nailed down.

I think the .Value method for RSquared is correct in WL6. Just copy that code into WL7. And yes, I would like to retain WL6's .Value method for WL7. I can give you some code if you need it.

We want to make WL7 at least as good as WL6.

We do not have the code of WL6.

I wrote a simple RegressStream.cs class, which computes streaming, 1st-degree linear regression. I was going to share it in Community.Components once you established a repository for that. Since it's streaming (moving window), you can use it for your Alpha, Beta, LRSlope indicators.

Hmm. RegressStream.cs doesn't seem to have R-squared. Well, I can easily add the correlation coefficient, small r, to it. R-squared is typically reserved for multi-variant models. I think for simple linear regression, the correlation coefficient, r, is typically used instead.

For my polynomial regression routine (three terms), I use Math.Net's GoodnessOfFit method, which is a generalized R-squared method.

Cone already has a good handle on this revision.

After recreating the RSquared calculation 3 different ways, we determined that the Series method matches WL6.

WL7's RSquared.Value method has problems and is fixed for Build 16.

If you're using Wealth-Data to compare to WL6, then:
1. Refresh Wealth-Data for WL7. WL7 does not automatically update for corrections.
2. Use RSquared.Series method until Build 16 is out.
3. WL6 uses StdDev of a Population (which probably isn't the right method for this indicator) so you need to Pass StdDevCalculation.Population to WL7's RSquared to match.

Yes, apparently the RSquared.Series() for StdDevCalculation.Population (shown below) does produce the same results as WL6. Interesting.

CODE:
double rSqdLine = RSquared.Series(decorrelated, 4, StdDevCalculation.Population)[bar]

Thanks in advance for fixing the RSquared.Value method for Build 16.