The prt STD formula is not the appropriate one

Forums › ProRealTime English forum › ProBuilder support › The prt STD formula is not the appropriate one

  • This topic has 21 replies, 6 voices, and was last updated 5 years ago by avatarBard.
Viewing 15 posts - 1 through 15 (of 22 total)
1 2
  • 09/28/2017 at 6:42 AM #47583
    Jim Moto

    Hi, I’m new, I’m writing, greeting and thanking everyone in advance.

    As I wrote in the commentary in this link: https://www.prorealcode.com/documentation/std/

    “The default function STD in Prorealtime it is in truth like =STDEV.P in Excel: this formula is not suitable for financial analysis because assumes that its arguments are the entire population. We need the code to replicate =STDEV.S because financial data represent a sample of the population. I tried to change the formula you gave to get STDEV.S, but Prorealtime does not even accept what you wrote, figure the rest…”

    09/28/2017 at 7:52 AM #47588
    Nicolas

    The difference between these 2 Excel formulas is the sample size you take to calculate the standard deviation. A ‘sample’ or the entire population is the same in our case, because the data array is populated within the last N periods. I also notice that Office support say : “For large sample sizes, STDEV.S and STDEV.P return approximately equal values”, which make sense since the population taken in their formulas is the same unlike 1 unit.

    09/28/2017 at 8:00 AM #47590
    Jim Moto

    This is fine if the data set is large, for small data sets the question is a bit more delicate … Is it possible to have the code for PRT of = STDEV.S? Or is there some limitation for that calculation? Just know it.

    Thank you very much Nicolas

    09/28/2017 at 8:06 AM #47592
    Jim Moto

    To be precise: “A ‘sample’ or the entire population is the same in our case, because the data array is populated within the last N periods”

    It is not the same: I have verified the result of PRT standard deviation with Excel = STDEV.S of the same data set, and of course the result is different, but is identical to =STDEV.P, just as obviously.

    Thank you two twice Nicolas

    09/28/2017 at 8:14 AM #47593
    Nicolas

    Ok, I’ll try to get the precise formula of the software to calcule the STD so we should be able to make another version to get the same as the STDEV.S of Excel.

    09/28/2017 at 8:17 AM #47594
    Jim Moto

    You are an Angel 😉 Thanks a lot 🙂

    09/28/2017 at 8:31 AM #47596
    Nicolas

    A quick code snippet:

    This code is a code I took from another trading platform to get the Standard Deviation value. We can spot a difference if we take or not the last data of the array (for which I introduce a variable named “decay” you can play with).

    First picture with the decay (other platform), second one without it and the curves are similar, so I’m wondering now what is the correct one .. 🙂

    09/28/2017 at 8:38 AM #47602
    Jim Moto

    Now is the right one 😉 Perfect Nicolas, thank you three times 🙂

    09/28/2017 at 11:40 AM #47643
    Despair

    @Nicolas: I had problems following your calculation for the sample standard deviation. I tried to code it myself but I got the same result.

    Here is how I calculated the sample standard deviation:

    You introduced the decay variable but I think it is unnecessary because it is always decay=1 for calculating the std.s.

    And I agree with Jim that for our use the sample standard deviation might be more appropriate.

    09/28/2017 at 12:21 PM #47655
    Nicolas

    I made the decay variable to quickly find how and why there was a difference between the STD instruction and the one from Excel.

    So the problem is that PRT internal calculation of the Standard Deviation is done with 1 more bar than the set period, do you agree?

    0 to 20-1 is still 20 periods while 0 to 20-0 is 21 periods.

    09/28/2017 at 2:20 PM #47683
    Despair

    Yes, correct. PRT uses the formula for the population standard deviation like Jim pointed out. The difference in the two formulas is basically only the “-1” in the denominator for the sample variance (you have 20-1=19 in the denominator instead of 20 for the population variance).

    It’s only a very subtle difference. I remember that I also thought it is strange when I learned this back in university but well that’s how it is.

    You can read about it and check the formulas here:

    https://statistics.laerd.com/statistical-guides/measures-of-spread-standard-deviation.php

    09/29/2017 at 7:49 AM #47745
    Jim Moto

    Hello Despair, thanks for the new code. Yes, the correct standard deviation requires only 1 degree of freedom. STD.P is considered a distorted/biased calculation when the sample we are analyzing is not the entire population of the phenomenon (like financial data). Try to build new Bollinger Bands with the correct standard deviation and compare two identical ts, one with the default BBs, one with the correct BBs: change everything, better, worse? This is not the point: it changes correctly, everything here. So my humble advice to the company is this: to change the PRT’s default STD function directly, so that all indicators using standard deviation (and in PRT are so many) become automatically corrected. PRT is a great technical analysis platform, really complete, beautiful to see, easy to plan (although I’m not capable of something) and I always seemed strange to have this error (I activated my first subscription about 10 years ago and after a while I left it for this little absurdity which, however, fails the results when you analyze a bit more in depth). I still find this stupid mistake today, while everything else is wonderful (some tips on how to improve TS reports I would have, but it does not matter right now): anyway, a stupendous platform. Resolve that crap please 😀

    09/29/2017 at 8:09 AM #47752
    Nicolas

    I just compared the bollinger bands between MT4 and PRT on EURUSD Daily timeframe, seems that the BB from MT4 is pretty much closer with the default PRT BBands (violet one), than the different other one we calculated together (the blue one).. I did not compare with other platforms though..

    09/29/2017 at 8:15 AM #47755
    juanj

    I personally prefer this to the standard BB:

    https://www.prorealcode.com/prorealtime-indicators/exponential-volatility-bands/

    09/29/2017 at 8:17 AM #47756
    Jim Moto

    Hi Nicolas, the static rules are clear and unique, I do not know if other platforms use them correctly or not, I just know that if I’m considering sapping one, I choose what at least in basic calculations behaves as it should. And you’ve been very helpful, and I still thank you, because now I can also program a non-biased Value At Risk on PRT, and it is not a small possibility 😉

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 22 total)
1 2

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
6 jan 24 prt not available – too long to respond
bb trading one long one short on dax 9-17,30
default prt vwap bands (daily) not selectable for trading system
futures: your orders are not connected by condition “one cancels the other”
help >> function close not working (it does not check price levels properly)
mlutiple ut – does not take the large one
prt lagging and not executing
prt not refreshing end of day candles.
prt now not working
prt screener code automatic change or not saved

Create your free account now and post your request to benefit from the help of the community
Register or Login