Author's dialogue. Alexander Smirnov. - page 40

 
lna01:
Yurixx:

I, on the other hand, have used dividing the sum by N. In this case all the cross sums go away and the formulas are very compact.

This may be justified. The estimate is biased, but if you don't work with very short LRs, the accuracy is adequate.

Offset in relation to what? To the classical definition? Or to a normal distribution? In my opinion it makes no difference, neither with small N, nor with large N.
 
Lord_Shadows:

Is it only for the loyal participants of this topic or others (I mean myself) can join in ...(get a suit).
Thank you in advance.
Well, how can ANG (-el of the galaxy M31 - "Andromeda Nebula") refuse the Lord. The address is in the PM, as far as I understand?
 
ANG3110:
If interested, here is a linear regression indicator without cycles. Counts the regression from a large number of bars, in a fraction of a second.
Yes, it's very close to MovingLR_2, the cycle by history (with coloring of rises and falls commented out) is 1219 msec, but MovingLR_2 (with A calculation added) is 1078.
 
ANG3110:
Lord_Shadows:

And is it only for the dedicated members of this topic or others (I mean me) can join in ...(get a suit).
Thank you in advance.
Well, how can ANG (-el from the M31 galaxy - "Andromeda Nebula") say no to Lord. The address is in the PM, as far as I understand?

Thank you very much...It's really nice to have that attitude...Already got it and I'm studying it.
Thanks again ANG-el.
 
Yurixx:
lna01:
This may be justified. The estimate is biased, but if you don't work with very short LRs, the accuracy is adequate.

Offset in relation to what? To the classical definition? Or to a normal distribution? In my opinion it makes no difference, neither with small N, nor with large N.
It is biased relative to the true one. Specifically, your RMS is underestimated.

P.S. But with respect to price charts this is irrelevant, which is why I agreed above that such a simplification is justified
 
lna01:
ANG3110:
If interested, here is a linear regression indicator without cycles. Counts the regression from a large number of bars, in a fraction of a second.
Yes, it's very close to MovingLR_2, history cycle (with coloring of rises/descents commented out) gets 1219 msec, but MovingLR_2 (with calculation A added) got 1078.


If you disable coloring, it counts 1.5 times faster. Accessing arrays takes a lot of time. And if you need a speed record type, you could use some other tricks. But I won't get a bonus for that.

By the way, I've looked briefly into MovingLR_2 code, and didn't see any interesting function to measure trend's speed - it's possible to build angle function in this case. In contrast, at_LR0 they are calculated on every bar. It means you can calculate RMS on every bar. And MovingLR_2 will not show pure linear regression, but something close to it. When it's just position of the end, it's not very important, but there are cases when you need exact linear regression.

 
ANG3110 писал (а): I did not see the calculation of line coefficients a and b
The k-values a and b can be calculated directly using the formula LR = (3*LW - 2*S) MA. Then provided that bar number i is the "current" bar, i.e. the last bar in the current regression line:

LR(Bar i) = a*i + b
LR(Bar i-1) = a*(i-1) + b

From where

a = LR(Bar i) - LR(Bar i-1)
b = LR(Bar i) - a*i

Or did I do something wrong? Of course, a and b depend on i, as they should.
 
Mathemat:

Or did I do something wrong?

Are you still awake...?
Listen Alexey, is there any practical use of your polemics on 40 !!! pages.
P.S. It's been a while since we've spoken...how's it going at all ?
 
Mathemat:

Or did I do something wrong? Of course, a and b depend on i, as they should.

Of course you did. You can't think of it that way. a and b are a function of the minimum squared deviation along the entire period. a is the angle of slope of the line along the whole period. And the increment in the LR end position, will not give the angle of the whole regression, but only the change in the b coefficient, which incidentally is the coordinate of the line end position.
 
ANG3110:


If you disable colouring, it counts 1.5 times faster. It takes a long time to access the arrays.

That's why I disabled it for the test - the figures are for the disabled colouring.


And if you need speed record type of calculations, you could use some other tricks.

In fact the algorithms are very close. In at_LR0 you can handle the indexes a bit more sparingly. Additionally I've used looped pointer, actually the main motivation for speed comparison was estimation of its efficiency.

By the way, I've had a quick look at MovingLR_2 code and didn't see any calculations of a and b line coefficients,

...

And MovingLR_2 doesn't do pure linear regression. When you're just drawing the position of the end, it's not a big deal, but there are cases when you need a totally accurate linear regression.

The line coefficients a and b are calculated in these lines.
A = (SumXY - N3*SumY)*N4;
B = (N1*SumY - SumXY)*N2;
For illustration, I attach MovingLR_2 version, which just draws current linear regression. Especially, because there was a mistake in previous one, when calculating N4 :)

MovingLR_2 gives pure linear regression and it's pretty easy to make sure of that. In at_LR0 there is inaccuracy of change from period in hours to period in bars. If we replace Close with (High+Low)/2 and take a period of 1 in at_LR0 and specify period not 60 but 61 in MovingLR_2 and apply it to the minute chart, the results will be absolutely coincident.

P.S. By the way, Mathemat, at_LR0 is a good example of how to calculate a zero bar in this kind of algorithm
Files: