Inconsistency (bug?) between ProBuilder and Proorder. Please advise.

• 04/11/2020 at 3:12 AM #125658
  ESCapedTestSubject

  Hi,

  I’m writing regarding an irregularity between ProBuilder and Proorder which is quite visible when comparing indicators with a Proorder strategy in backtesting. I believe this to be a bug or at least something that needs to be clarified. This affects some indicators more than others and results in inconsistent results. Please note, I have used DEFPARAM PRELOADBARS = 0 (zero) so no bars are loaded by the ProOrder backtest.

  1  The ProBuilder’s first BarIndex starts with bar 0 (zero). The ProOrder starts with BarIndex 1. This is rather peculiar. I understand that Barindex[0] is the lastbar, but this problem causes an issue. This means that if I want to find out the  first BarIndex value (lets say I have 101 bars) and I have a variable counting the bars, I need to call the value by BarIndex[101] for Probuilder. For ProOrder the call would be BarIndex[100] . This can be seen in the picture Barindex inconsistency with the applicable code where ProOrder and ProBuilder are shown with their respective BarIndex value.

  

  The code is ProBuilder is:

  RETURN BarIndex AS "BarIndex"

  1	RETURN BarIndex AS "BarIndex"

  The code to visualize in ProOrder is including fake trades not taken:

  DEFPARAM PRELOADBARS = 0 GRAPH(BarIndex) //FAKE TRADING CONDITIONS BELOW // Conditions to enter long positions IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF // Conditions to exit long positions If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF // Conditions to enter short positions IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF // Conditions to exit short positions IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF // Stops and targets : Enter your protection stops and profit targets here

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

  DEFPARAM PRELOADBARS = 0 GRAPH(BarIndex)     //FAKE TRADING CONDITIONS BELOW   // Conditions to enter long positions IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF   // Conditions to exit long positions If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF   // Conditions to enter short positions IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF   // Conditions to exit short positions IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF // Stops and targets : Enter your protection stops and profit targets here

  2  If I ask for a SMA to be calculated, this also creates an inconsistency between the ProOrder and Probuilder (Indicator). The Proorder shows a value on the first bar (Bar=1). However, ProBuilder only shows a value on the third bar (Bar= 2  : which means Bar 0 and 1 have no value which they should). This may not be a big problem as the actual value of ProOrder (Bar=2) and ProBuilder (Bar=1) is the same and they are synced on the bar. However, this is an inconsistency. See picture: SMA inconsistency.

  

  The code is for ProBuilder:

  SMA = Average[14](close) RETURN SMA AS "SMA"

  1 2	SMA = Average[14](close) RETURN SMA AS "SMA"

  The code for ProOrder is:

  DEFPARAM PRELOADBARS = 0 SMA = Average[14](close) GRAPH(SMA) //FAKE TRADING CONDITIONS BELOW // Conditions to enter long positions IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF // Conditions to exit long positions If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF // Conditions to enter short positions IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF // Conditions to exit short positions IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF // Stops and targets : Enter your protection stops and profit targets here

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

  DEFPARAM PRELOADBARS = 0 SMA = Average[14](close) GRAPH(SMA)   //FAKE TRADING CONDITIONS BELOW     // Conditions to enter long positions IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF   // Conditions to exit long positions If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF   // Conditions to enter short positions IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF   // Conditions to exit short positions IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF   // Stops and targets : Enter your protection stops and profit targets here

  3   The most probleamtic point comes when having specific functions that picks data from the first bar such as ATR. This not only causes an inconsistency in the first bar displayed, but it also gives totally different values with an affect on many bars. This means that the effect from these numbers will take place over some time before they are more “normalised”. Any strategy that looks at the first bars and starts calculating the indicator may have a completely different appearance or effect in the ProOrder. See Picture ATR inconsistency 1 & 2

  
  

  Code in ProBuilder:

  ATR = AverageTrueRange[14](close) RETURN ATR AS "ATR"

  1 2	ATR = AverageTrueRange[14](close) RETURN ATR AS "ATR"

  Code in ProOrder:

  DEFPARAM PRELOADBARS = 0 ATR = AverageTrueRange[14](close) GRAPH(ATR) //FAKE TRADING CONDITIONS BELOW // Conditions to enter long positions IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF // Conditions to exit long positions If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF // Conditions to enter short positions IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF // Conditions to exit short positions IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF // Stops and targets : Enter your protection stops and profit targets here

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

  DEFPARAM PRELOADBARS = 0 ATR = AverageTrueRange[14](close) GRAPH(ATR)   //FAKE TRADING CONDITIONS BELOW   // Conditions to enter long positions IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF   // Conditions to exit long positions If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF   // Conditions to enter short positions IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF   // Conditions to exit short positions IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF   // Stops and targets : Enter your protection stops and profit targets here

   

  The example above shows an ATR of 14 days, but if I were to call an ATR for all the bars (excluding Bar=0) for ProBuilder as this surprisingly gives a value of zero, then I would have completely different values. Especially for any automatic trading system that uses the first bars, such as Renko etc to create a referencing system. Furthermore, any advanced strategy is completely wrong when comparing the Orders executed to the Indicator (not shown here) as they occur at the wrong bar, for the wrong reason due to incorrect values between the indicator and the ProOrder.

  I would appreciate any input on how to solve this issue as it has taken many, many hours to figure out why my strategies were not working consistently when comparing the code for Indicator and ProOrder backtest.

   

  Thanks.

   

  

  ESCapedTestSubject

  Participant

  Topics: 10

  Replies: 17

  Been thanked: 6 times
  04/12/2020 at 1:34 PM #125786
  Nicolas

  Is the problem the same with any instrument and timeframe? Without preloadbars=0, is it also the same?

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20830

  Been thanked: 4744 times
  04/12/2020 at 6:29 PM #125821
  ESCapedTestSubject

  I have tested a few instruments (Futures – DJIA and some major forex). If I change Preloadbars to any other value than zero, the first BarIndex count is still the same for ProOrder (=1) and ProBuilder (=0), however this affects the values for the first bars and any functions relying on this data for ProOrder. The reason I use Preloadbars = 0 is to have an identical starting point for indicators as ProOrder would otherwise calculate functions on data which is not available for the ProBuilder bars.

  I have broken down some functions into code and found some further inconsistencies.

  If I use the TR function (True Range), the first bar (Barindex=0) shows no value for ProBuilder. ProOrder shows the value for the first bar.

  If I code TR manually, using the formula TRManual= HIGH-LOW for the first bar, I do get a value for ProBuilder as well as ProOrder which is the same between the two. However, the value is different for ProOrder than if using the TR function. This is odd! Does ProOrder still pull data from previous bar that I have defined that I do not want loaded by Preloadbars = 0? Is there a “hidden” bar=0 for ProOrder?

  If I want to see an average of the TRManual and use command: AVERAGE[14](TRManual), ProOrder shows me a value on bar 13. Not 14. However, ProBuilder shows me a value on Bar 14! This value is synced for the same bar between ProOrder and Probuilder. The impact may be limited on any functions.

  However, if I use Wilders smoothening, which looks back at previous bars and which I believe is the correct formula for calculating Average True Range, AVERAGE[14,3](TRManual), then the numbers are completely different for all bars and it takes up to a hundred bars before the values are identical.

  The only conclusion I can draw is that there must be a problem or inconsistency in how data is being pulled. Does Preloadbars = 0 mean that data gets pulled from previous day anyway or a Bar = 0 that doesn’t get shown?

  Does the data from the first ProBuilder bar (barindex=0) not get pulled because it is bar=0 and the system is limited to positive integers?

  It is very frustrating as I do not know what is going on and why existing functions do not work properly between indicator and ProOrder when it is exactly the same function or code.

  In some cases where fluctuations are high on the first bars, the difference will be substantial and change the course of the following orders and may have a larger impact on ATS.

  Thanks for your support and for all great posts on this forum.

  I hope you can figure this one out as well.

  

  ESCapedTestSubject

  Participant

  Topics: 10

  Replies: 17

  Been thanked: 6 times
  04/12/2020 at 9:06 PM #125843
  ESCapedTestSubject

  To further support the theory of an issue with BarIndex inconsistency between ProBuilder and ProOrder, I have done some more checks.

  Using the formula for TR instead of the function in PRT as well as code provided by you Nicholas on Wilder smoothening code published in this forum, I can get identical results for most part between ProOrder and ProBuilder. This means there must be some inconsistency in the original function of the program. The only thing one has to take in account is to adapt the code with one bar less or more to represent the period one is looking at.

  However, although hundreds of bars (including the first ones) are identical, I still find errors between some bars – see the marked boxed zone. In this case it is the Dow on the 1 minute chart. Error is on the second decimal, so it’s not the critical, but it is highly peculiar. Math is math. So it shouldn’t. It’s shouldn’t be a rounding error as it should happen on both the ProBuilder and ProOrder.

   

  The code for ProBuilder:

  IF BarIndex = 0 THEN TRM = HIGH-CLOSE ELSIF BarIndex > 0 THEN TRM = MAX((HIGH-CLOSE), MAX(ABS(HIGH-CLOSE[1]), ABS(LOW-CLOSE[1]))) ENDIF N = 14 K = 1/N if barindex>N-1 then wilder = TRM * K + wilder[1] * (1-K) endif RETURN (wilder)

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

  IF BarIndex = 0 THEN TRM = HIGH-CLOSE ELSIF BarIndex > 0 THEN TRM = MAX((HIGH-CLOSE), MAX(ABS(HIGH-CLOSE[1]), ABS(LOW-CLOSE[1]))) ENDIF     N = 14 K = 1/N if barindex>N-1 then wilder = TRM * K + wilder[1] * (1-K) endif     RETURN (wilder)

   

  The code I used for ProOrder based on:

  DEFPARAM PRELOADBARS = 0 IF BarIndex = 1 THEN TRM = HIGH-CLOSE ELSIF BarIndex > 1 THEN TRM = MAX((HIGH-CLOSE), MAX(ABS(HIGH-CLOSE[1]), ABS(LOW-CLOSE[1]))) ENDIF //TRMAV = average[14](TRM) N = 14 K = 1/N if barindex>N then wilder = TRM * K + wilder[1] * (1-K) endif GRAPH(wilder) //FAKE TRADING CONDITIONS BELOW // Conditions to enter long positions IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF // Conditions to exit long positions If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF // Conditions to enter short positions IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF // Conditions to exit short positions IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF // Stops and targets : Enter your protection stops and profit targets here

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

  DEFPARAM PRELOADBARS = 0     IF BarIndex = 1 THEN TRM = HIGH-CLOSE ELSIF BarIndex > 1 THEN TRM = MAX((HIGH-CLOSE), MAX(ABS(HIGH-CLOSE[1]), ABS(LOW-CLOSE[1]))) ENDIF   //TRMAV = average[14](TRM)   N = 14 K = 1/N if barindex>N then wilder = TRM * K + wilder[1] * (1-K) endif     GRAPH(wilder)     //FAKE TRADING CONDITIONS BELOW   // Conditions to enter long positions IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF   // Conditions to exit long positions If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF   // Conditions to enter short positions IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF   // Conditions to exit short positions IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF   // Stops and targets : Enter your protection stops and profit targets here

  For now I feel hesitant in launching real-money ATS as I can not verify what is going on with the code.

  My queries are thus:

  • Does ProOrder DEFPARAM PRELOADBARS = 0 mean no prior data before Bar=1 get loaded? Is there a hidden bar=0? How otherwise does the data pull occur from the previous close?
  • Does ProBuilder reject using the Bar=0 even though it contains data?
  • Why is BarIndex for ProOrder and ProBuilder not synced, one starts with Bar=1 (ProOrder) and one iwth Bar=0 (ProBuilder)
  • Does this kind of inconsistency occur on “just” indicators / functions looking back at previous bars? Such as commands including [x] bar? These are quite a lot of functions (!)
  • Are ProRealTime aware of these issues? I believe it can’t just be me noticing this?

  Many thanks for your assistance.

  

  ESCapedTestSubject

  Participant

  Topics: 10

  Replies: 17

  Been thanked: 6 times
  04/13/2020 at 9:29 AM #125871
  GraHal

  ESCapedTestSubject wrote:

  Does ProOrder DEFPARAM PRELOADBARS = 0 mean no prior data before Bar=1 get loaded? Is there a hidden bar=0? How otherwise does the data pull occur from the previous close?

  Why do you think a data pull occurs from a previous bar?

  If for example, a System is using Average[20](Close) then the System has to wait until bar 21 before the MA gets calculated (with DEFPARAM PRELOADBARS = 0 ).

  If we do not specify DEFPARAM PRELOADBARS = 0 or xxxxxxx then the default is 2000 (max we can use is 10000).

  

  GraHal

  Participant

  Topics: 204

  Replies: 8440

  Been thanked: 2049 times
  04/13/2020 at 10:10 AM #125878
  GraHal

  ESCapedTestSubject wrote:

  Why is BarIndex for ProOrder and ProBuilder not synced, one starts with Bar=1 (ProOrder) and one iwth Bar=0 (ProBuilder)

  If it were me, I would ask PRT two simple question …

  If I use  DEFPARAM PRELOADBARS = 0 …

  1.  What is the number of the first bar in ProOrder?

  2.  What is the number of the first bar in ProBuilder?

  using the Contact Form on the link below. Be sure to let us know the answer please?

  Use the same email address for which you are registered with IG / PRT.

  https://www.prorealtime.com/en/contact

  

  GraHal

  Participant

  Topics: 204

  Replies: 8440

  Been thanked: 2049 times
  04/13/2020 at 10:17 AM #125882
  GraHal

  GraHal wrote:

  System has to wait until bar 21

  Correct myself … that should have read … until 20 bars are showing.

  

  GraHal

  Participant

  Topics: 204

  Replies: 8440

  Been thanked: 2049 times
  04/13/2020 at 11:03 AM #125891
  Nicolas

  In backtests (ProBacktest) and realtime automatic trading (ProOrder), 1 candlestick is always load as a “preloadbar”, which allows to create the tree structure of the code on the server, the variables self-generated by the code optimization system, and further other things..

  Whether it is backtest or automated trading (server side), it acts the same, so you will always have the same result between the two, however the platform only uses the data displayed (client side) so you will have a difference of one candlestick with the indicators.

  1 user thanked author for this post.

  GraHal

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20830

  Been thanked: 4744 times
  04/13/2020 at 1:11 PM #125927
  ESCapedTestSubject

  Hi Nicholas,

  Thanks for your prompt answer. I appreciate it.

  I understand we need this for the server side, but it creates an issue with all functions that require a previous period [1] command as the back-testing won’t be consistent with the actual data displayed. The most obvious is Renko bars…

  I wish I would have known that the system does a preloadbar of 1 even if it is defined as 0 … I have been pulling my hair and not understanding if there is an issue with hundreds of lines of code.

  Do you know of the best code for AverageTrueRange in order to overcome this issue and sync the view of ProOrder and Probuilder? I have used your Wilder code as described above in the post on manually generated TR, however it seems to create incorrect values. They are synced, but I’m not sure they are correct to the real Average True Range. Both the built-in functions AverageTrueRange and the use of Wilder Average (AVERAGE[timeperiod,3](TR) takes in the preload-bar and causes a problem with inconsistent numbers for comparing executions to the actual price.

  

  ESCapedTestSubject

  Participant

  Topics: 10

  Replies: 17

  Been thanked: 6 times
  04/13/2020 at 2:20 PM #125940
  Nicolas

  Why not using a custom code for ATR and start the calculation after X bars, to be sure both the ProBuilder one and ProBacktest are synced together?

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20830

  Been thanked: 4744 times
  04/14/2020 at 12:33 AM #126007
  ESCapedTestSubject

  Nicolas wrote:

  Why not using a custom code for ATR and start the calculation after X bars, to be sure both the ProBuilder one and ProBacktest are synced together?

  That is an excellent idea. You wouldn’t happen to have the code used by PRT? I have found different calculations, and some MT4 even uses a non-standard one, so it is rather confusing.

  The way I understand it in Wilder’s own book is:

  TR for first bar: high-low

  TR for any other bar is MAX of Absolute values: HIGH-LOW, CLOSE[1]-HIGH, CLOSE[1]-LOW.

  If our period is 7 bars, then the first ATR is calculated on Average of the 7 first TR bars.

  The ATR on the 8th and any future bars will be: (6 x ATR[1] +TR) / 7.

  I have tried replicating this, and althoug my numbers are close, they are not the same as for the built-in function. So it would be great to get the formula used in PRT tobetter understand what is going on.

   

  Many thanks,

   

  I would appreciate if you could assist with this as it would solve the problem.

  Thanks.

  

  ESCapedTestSubject

  Participant

  Topics: 10

  Replies: 17

  Been thanked: 6 times
  04/14/2020 at 8:38 AM #126028
  Nicolas

  The PRT description can be found in our online documentation: https://www.prorealcode.com/documentation/averagetruerange/

  While I’m almost sure we have recoded from scratch somewhere in the forums, I can’t find it.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20830

  Been thanked: 4744 times
  04/16/2020 at 3:11 AM #126345
  ESCapedTestSubject

  Thanks. I tried the documentation already, but I get different values with the classic Wilder calculation. I am not sure what the function does differently. Metatrader 4 uses a non-standard Wilder’s as well. I don’t know if this is the case with PRT.

   

  However, more worrisome, I have found that there is an inconsistency in the price between ProOrder Backorder and ProBuilder. This is the reason why I had indicators not working properly.

  This issue that I have seen happens sporadically every now and then and in this exampel the error is a difference between the LOW price in ProOrder and ProBuilder. In this instance it is not a big error, but I have come across others as well.

  Why does this occur? Does ProOrder Backorder not use the same dataset as ProBuilder? Are there any other values it uses from server that are different than the datastream picked up by the price information / indicator?

  The code is extremly simple to display this error. The date is April 9th on 1M chart for DOW at 19:59.

  Please see the picture that shows the issue between ProOrder showing different low value than Price and Indicator.

  ProBuilder code

  RETURN LOW AS "LOW-INDICATOR"

  1	RETURN LOW AS "LOW-INDICATOR"

  ProOrder (with fake trade) code

  GRAPH (LOW) //FAKE TRADING CONDITIONS BELOW IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

  GRAPH (LOW)   //FAKE TRADING CONDITIONS BELOW IF NOT LongOnMarket AND CLOSE>30000 THEN BUY 1 CONTRACTS AT MARKET ENDIF If LongOnMarket AND CLOSE>40000 THEN SELL AT MARKET ENDIF IF NOT ShortOnMarket AND CLOSE < 0.000001 THEN SELLSHORT 1 CONTRACTS AT MARKET ENDIF IF ShortOnMarket AND CLOSE = 0 THEN EXITSHORT AT MARKET ENDIF

  Thanks.

   

   

  

  ESCapedTestSubject

  Participant

  Topics: 10

  Replies: 17

  Been thanked: 6 times
  04/16/2020 at 7:41 AM #126349
  Vonasi

  From a quick check it seems to be some sort of rounding issue on some instruments. On DJI and EURUSD I got exactly the same values but in the attached image for Vodafone it can be seen that the value returned in ProOrder is clearly rounded to one decimal place where it isn’t in ProBuilder.

  2 users thanked author for this post.

  ESCapedTestSubject, Nicolas

  

  Vonasi

  Moderator

  Topics: 192

  Replies: 5088

  Been thanked: 1811 times
  04/16/2020 at 2:41 PM #126408
  ESCapedTestSubject

  Thanks for the input. You are absolutely right in your case. I see that it is a rounding issue to the first decimal based on the second decimal. The effect is not critical as I see it.

  However, in my example, the difference is 0.5 points on the DJIA. 23 887,7 vs 23.888.3. This is definitely not a trivial rounding issue of 0.04. I have seen even bigger differences but it has taken some time to break down what causes this as the last thing I would think was that the price wouldn’t correspond(!) If you use an EMA and other specific indicators, this will be weighed in and affect many following bars.

  This issue doesn’t appear on only a hundred bars, it happens after several hundred or thousand of bars on a bar for no obvious reason. If you use Wilders MA, ATR or Renko, it will cause trades to occur that should not have happened.

  The reason I raised this query is that I need to verify that my code executes the trades as intended. The back-test showed inconsistencies, and it has taken several days to find out that Barindex of the first bar in ProOrder and ProBuilder and the effect of this as ProOrder and ProBuilder is not synced for anything that uses code including previous bar’s datasets on the first bars.  This has created the need for (unecessary) custom manual code. This is not a big issue, but not expected. I thought this would solve any inconsistencies, only to find other inconsistencies.

  Now I find that the prices are not listed correctly – which is worrisome.  Coming from other software with ATS systems, I’m afraid I would still like to know what causes this in order to commit real-money.

  Does ProOrder not use the same data pull as the displayed price and the ProBuilder? If not – what datasets are used and which one is right? How can the price be displayed so different on occasional bars when all others work perfectly?

  1 user thanked author for this post.

  GraHal

  

  ESCapedTestSubject

  Participant

  Topics: 10

  Replies: 17

  Been thanked: 6 times
• Author
  Posts