BUG with incorrect ExponentialAverage Syntax Acceptance

• 03/11/2021 at 4:50 PM #163855
  HappyBunny

  I would like to highlight a bug with the acceptance of incorrect syntax of the “ExponentialAverage” function used in indicators in ProBuilder and ProOrder.

   

  I was getting some strange results when back testing a system.

  I went through it by hand and meticulously created indicators for each condition variable that was being checked. Copy and pasting from the strategy code.

  The issue ended up being with the Syntax of the “ExponentialAverage” function.

  The online documentation gives the syntax as:   ExponentialAverage[N](price)

  Where “N” is the period of the average and “price” is the data you want to average.

   

  Now either I had just cut and pasted old code or code from another platform and then adjusted it. This is my mistake.

   

  What I had in my code was “oscillator = exponentialaverage(close)[Avg3]”.

  This syntax should NOT be accepted. This is why I now post here so it can be amended and other users can be wary of it.

   

  As an example of what goes wrong I include a test file “EMATest.itf” with the code so it can be applied to chart and a screenshot of chart with indicator on it.

  Specifically I have shown a test with “ exponentialaverage(close)[23]”.

  This results in what looks like a 23 period EMA shifted 23 periods into the future with slightly higher values. But you should not get anything except and ERROR.

   

  This post though is to show that the acceptance of this syntax and the odd values it creates is a bug as an error should be given so that the code can be corrected.

  This is an error in the parsing of ProBuilder code and may affect other functions using the “(data)[period]” syntax. I have not checked other functions thoroughly myself (yet).

   

  

  HappyBunny

  Participant

  Topics: 1

  Replies: 2

  Been thanked: 0 times
  03/11/2021 at 5:43 PM #163870
  robertogozzi

  Why on earth  “This syntax should NOT be accepted“?

  It’s an important feature of the PRT language! We couldn’t do without it!

  If you don’t like it, just don’t use it.

  This is what your 3 lines mean:

  EMATest = exponentialaverage[period](close) //default (Periods + data source) ExpAvg3 = exponentialaverage[period](close[Period2]) //average CLOSE for PERIOD bars, starting not from the current CLOSE, but from that of the PERIOD2th bar prior to the current one ExpAvg = exponentialaverage(close)[period] //you want to average CLOSE for the default 20 periods (since they are missing), but want to know its value referred to the PERIODth bar prior to the corrent one

  1 2 3

  EMATest = exponentialaverage[period](close)          //default (Periods + data source) ExpAvg3 = exponentialaverage[period](close[Period2]) //average CLOSE for PERIOD bars, starting not from the current CLOSE, but from that of the PERIOD2th bar prior to the current one ExpAvg  = exponentialaverage(close)[period]          //you want to average CLOSE for the default 20 periods (since they are missing), but want to know its value referred to the PERIODth bar prior to the corrent one

   

  

  robertogozzi

  Moderator

  Topics: 69

  Replies: 16469

  Been thanked: 3643 times
  03/11/2021 at 6:01 PM #163871
  Vonasi

  It would appear that it defaults to EXPONENTIALAVERAGE[20](close[23])

  So if no period is declared then it defaults to 20 and then you have asked for an average of the close 23 bars before this one.

  Use this indicator to confirm this:

  a = exponentialaverage(close)[23] b = exponentialaverage[20](close)[23] return a, b

  1 2 3

  a = exponentialaverage(close)[23] b = exponentialaverage[20](close)[23] return a, b

   

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1810 times
  03/11/2021 at 7:51 PM #163877
  HappyBunny

  Thanks for your explanations.

   

  Putting the [20] in front certainly clarified the default value issue.

  The online documentation needs to be brought up to date, as it does not document the default behaviour or specify that the period parameter is optional neither does it document the again optional shifting factor to move the indicator to the future.

   

  While looking at this I checked the MACD documentation online…mmmm. Needs fixing too. S L SI or x y z. And no mention of defaults at all (but similar issue remains).

   

  The other issue I have is that the syntax as is, is ambiguous.

  For example:

  exponentialaverage[period](close[Period2])

  1	exponentialaverage[period](close[Period2])

  is the same as:

  exponentialaverage[period](close)[Period2]

  1	exponentialaverage[period](close)[Period2]

   

  It is the first form that needs to be documented for use so as to allow:

  exponentialaverage[period](close[Period2])[Period3]

  1	exponentialaverage[period](close[Period2])[Period3]

  This cannot be done with the second form.

   

  Professional code is easy to read and easy to maintain.

  I can understand defaults for people who just want to slap an indicator on a chart but for coding indicators and trading strategies all values should be readily available to be discerned from the code. There should be no hidden magic numbers.

   

  If I don’t like the unprofessional code, you are right there are other platforms and languages like eSignal and MQL4/5 etc.

  

  HappyBunny

  Participant

  Topics: 1

  Replies: 2

  Been thanked: 0 times
  03/11/2021 at 8:34 PM #163878
  Vonasi

  If you don’t like the (in your opinion) unprofessional code then you are in the wrong place to complain about it. These forums are independent of PRT and simply a place for PRT users to meet and discuss things about PRT. They are not run or owned by PRT. PRT do offer some limited customer support in the platform support forums.

  If no value is entered in an indicator then it is assumed that the coder is aware that it will default to a value. This is handy when coding as it can save some typing. For example close[0] is defaulted so we can simply type:

  average[20] > average[50]

  1	average[20] > average[50]

  instead of the long winded:

  average[20](close[0]) > average[50](close[0])

  1	average[20](close[0]) > average[50](close[0])

   

  The norm when coding is usually not to rely on default values but to ensure that you actually specify a value in the right place in your code so that you can know that the result is what you are coding to achieve… but sometimes the defaults can save a lot of finger work.

   

  (close[Period2])

  1	(close[Period2])

  and

  (close)[Period2]

  1	(close)[Period2]

  are quite obviously the same thing… the value of close or (close) period2 bars back. There is nothing ambiguous about a a pair of ( ).

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1810 times
• Author
  Posts