How to know output from indicator when programming?
- This topic has 51 replies, 7 voices, and was last updated 2 months ago by
.
-
This all came about when v12 was made available and the platform had become almost unusable at one point. Quite a bit has changed since then and maybe, just maybe, the process will run ok in 1s but because it’s run on server-side
Correct – No 1s system will be an issue because all runs server side indeed. No need to give that another try – it will just work (it always did).
Inv, I hope you don’t feel thrown back and forth, but I’m afraid you will. 🙁
A 1 second system just can not be backtested, certainly not when you have 2.4 days of Extended Trading Hours only (12 / 5 for Complete). Such systems could only put to live when you don’t need any optimization, unless over pure technical matter. And since your approach shows all of the opposite (the 10K preload thing), please forget about this.You could make that system 2s to begin with, or 3, or 4 or 5. But say again, why do that ?
Maybe I forgot to keep the goal in focus ? 🙂For your own focus – and hopefully I can bring this across – with a 5s system and assuming Pending Orders for the trailing, it kind of starts to work for the trailing. Thus, when made yourself (say something like JS proposes) it can be tuned such that it will do “something” which might be more beneficial than doing nothing (just exit on the preset target). And to remember, I explicitly talk(ed) about Pending Orders hence let the broker catch that price you want.
Now think Market orders …
With Market Orders you can do what you want, also with 1s systems. Internally you do the trailing (this is again something JS proposes – or any means you can think of yourself) and when the time (price) is right, you put that Market Order and be done. … And of course accept the Slippage in any direction.So that’s the thing; (almost) everything can be done, but with a boat load of prerequisites. This starts with “no backtesting possible” and all the hoopla you will run into in Live if you did not carefully test it for years before (which still can only be done on Live). I don’t think that’s your thang – but it’s only well meant advice.
…
A key takeaway of all what was said in between the lines by me :
You don’t need 1s systems to perform well. Just use 1 minute as the fastest timeframe and put some nice trailing on that yourself, or the Automated Trailing provided by PRT (can work with IG only). You can still choose for Market Orders which would be a necessity for IB (1 minute Pending Orders may survive 48 hours at IB before they go wrong because of communication error). But AFIAK you’re on IG anyway, so pick your choice (Marker or Pending orders).
Last thing on this : 1s systems won’t work on IG anyway, because of their own movements. This literally comes down to : what moves up too much the one second, moves too much down (double) the next second. Just try it and compare with a real feed (like PRT-IB could be that). I would go no less than 1 minute on PRT-IG (and I do – nothing I tell about is theory only). The 1s systems I show here and there (always from Live – below a version of it) are from PRT-IB and are always Market orders only (the “Bes” below is from “Bestens”, a slang word for Market).
One more thing : it may be justified to use the #ofbars math for Regular trading Hours because in Aus you may not have access to anything with Extended Trading Hours to begin with. I vaguely recall that. So if JS provided that data by this implication – then fine of course. It would be your truth. 🙂
1 user thanked author for this post.
Just to finish my rant on what a bar is,
A timeframe, has a bar period, and a ‘bar’ is a period with at least 1 tick.
And program only runs once at the end of a each ‘bar’.
This creates two parallel paths, one the ‘bar’ action, and the other of time periods.
Plotting BARINDEX shows it only increments when a tick is present in the time period.
Using the ruler tool over a chart, when there are gaps with no candles, the value of bars measured is the number of bar periods, not bars.
So PRELOADBARS, though I haven’t proved it could be either, but I’m leaning to bars, not periods.
If a condition requires the y-axis Price to trigger it, then at least 1 tick has to be present in the period to create the ‘bar’.
The ‘bar’ trigger the program to run through at end of the bar. And a tick and other ticks in the period would have to change price to fore fill the condition.
Now looking at the x-axis Time, and a condition using a specific time, 080000. If there is no market tick at the specific time, then condition is not triggered.
This because, no ‘bar’, program not triggered. So if there is a tick, then there is a ‘bar’, program run, and condition gets triggered at the time.
This theme appears to echo, through indicators, backtest and proOrder.
So it appears the underlining action of at least 1 tick , in the time period, is required to trigger the program code to be executed, regardless if the condition is price or time.
Before I realised all this, I couldn’t under stand why sometimes, something I was expecting to happen didn’t, or I would get random results, especially around time.
1 user thanked author for this post.
A timeframe, has a bar period, and a ‘bar’ is a period with at least 1 tick. And program only runs once at the end of a each ‘bar’.
Instead :
The program only runs at the end of each time interval, regardless of whether ticks (read : trades) have been there.
The program only runs on elapsed time intervals, set by the TimeFrame (you set).
If the units are ticks instead of time intervals, the program never runs because PRT was not designed to do so. In its simplest form for grasping it : the simpler program (like PRT) let elapse a timer at your set intervals (e.g. each 1 second, each 3 seconds, each 1 minute, each 27 minutes, each 4 hours) and when the timer elapses, the program is called. You could make that too.
Now ticks, be that trades or changed bids (new bids) or changed asks (new asks) :
Tools like PRT must now trigger on the events of these changes. This means it must continuously monitor the data in in order to fire a trigger to your program (to be called). This is just not in ProOrder. It is in ProBuilder (with which we build Indicators) and at each tick new drawings can be made to the screen (by you).You can see it so that the ticks for the drawings via the Indicator are generated by your PC (each of our PCs)** which makes it possible to happen in the first place. This with the notice that in quiet times a dozen or so ticks occur per second (or less, depending on the instrument) while in more volatile times (e.g. opening of the US at our 15:30) 10thousands of ticks occur per second. Make that 50K+ per second when Mr Powell speaks at 20:00 our time.
I tried to visualize this for very quiet times at night via picture #1 where you seea first timed bar at (Amsterdam) 00:10 and can count each minute (5 bars) up to 0:015 and a few beyond,
compared to picture #2 right before and after the Europe opening at 09:00 Amterdam where you can see the difference in ticks right before 09:00 and after that, by means of the changed spacing. I could zoom in to the individual ticks here, to see what all happens for individual bids etc. (your Pending Order). But point remains : PRT can only trigger your program per vertical white bar you see here, by me set at the “per one minute”.
Your perception of what a bar is, is correct, but PRT can only call your Strategy program code at timed bars.
**): The important concept of PRT is that it runs your code server side (their server(s)) with the even more important conceptual matter that it can not call everybody’s program per tick occurring in the world (which are many millions per second for all instruments) – if not billions. You, however, could do that per your own PC per filtered instrument, so that a few dozen are left per second, up to 50K+ per second at volatile times. Would you try that for 10 instruments, your PC might choke. And if not then, then at 20 instruments (etc.).I hope this helps somewhat ?
Find exclusive trading pro-tools on 
