As I want a workable solution to my problem and want to use AB for my
project (I would be trading this already using my AB system if I had a
solution), I will state the fundamental problems I face clearly together
here (instead of disjointed posts like before) and then perhaps
a solution might occur to you or somebody else. Please forgive
the length and complexity of this post.
Background:
My trading system is very simple in principle. AFL calculates
a complex indicator, I draw manual trend lines, and I place manual trades on a
single stock or ETF at a time. It is day trading, so I only have a few
seconds to trigger my trade when the conditions are right. My AFL allows
rapid manual selection of different timeframes via a parameter, and
selects the proper volume bar settings dynamically for different ETFs or
stocks. The program automatically runs through many timeframes to select
trade trigger possibilities for me to consider.
1. There is a heavy compute environment --several seconds of
AFL.
2. The environment is highly interactive --drawing trend
lines.
3. Seconds count for placing trades.
First
Problem set:
Under heavy compute loads (when AFL time is greater than refresh rate),
AB stops responding to the UI.
Workarounds:
The only way I can get some UI functionality back is to set the refresh
rate to one second longer than the AFL compute time. Then I can get UI
functionality back, but with many delays.
I also have a ParamToggle() to turn off most indicator processing so that
I can interact with the UI better at times (but I lose my indicator plot
references).
This is a partially effective workaround that I could limp along
with.
Requested solution:
Realizing that the root problem is that the UI functions only run (or
initiate) in between AFL passes, I looked for a way to do less processing on
each pass. The AFL load could be much less most of the time because I
only need to calculate everything when a new bar is added.
I thought of two possibilities:
1. Ask for an AFL function that is essentially DoUserInterface().
Then put AFL into an infinite loop and put these commands at appropriate
places. Since this is backwards from the way the AFL appears to work, I
did not make this suggestion.
2. Ask for arrays that keep their data between AFL passes. I
tried using ATC for this. It functioned like it was supposed to, but was
too slow to be a practical solution. I understand the reason they are so
slow, and that is because they are a true static permanent array.
However, what I wanted was only for a normal array to be saved between
passes. They only need to be identified by which pane they are
associated with (could be part of the internal name). They are only
valid between new bars (same array size). Changes to symbol, timeframe,
parameters, etc., can be detected in the AFL and the array updated. I
know this can be done, because I did it for the ATC version I wrote and
everything worked perfectly (just not faster). Because AFL is so fast
working with arrays, It seems that it should be possible to just save an array
in memory in a high speed way, then recall it to repopulate the array instead
of recalculate the array if the AFL determines that the data would not have
changed since the last pass.
There may be another possible solution that I have not thought of and I
would love to hear it.
Second
Problem set:
Because this is a realtime trading system, decisions have to be made from
raw data which contains bad ticks that may fool the system.
Volume bars are used in the system, and must be able to change volume per
bar on different AFL passes.
Built-in timeframe or volume settings do not allow the flexibility to
address these
Workarounds:
A tick database is too large to have enough history for the indicators.
Running a database of 5 seconds for a basic 1 minute bar
(or equivalent for volume bars) allows for reasonably effective bad
tick removal and volume bar generation. History can be just 60K bars.
Bad ticks are removed and volume bar settings are determined using the 5
second bars. Arrays are built up using TimeFrameSet() to get the actual
bars used for indicator calculations and graph plots. This approach
works really well, however, there is one big problem with it.
Even though I can display all my price and indicators in the timeframe I
desire, I can not draw studies that align to that timeframe. All studies
are drawn in the pane relative to 5 second bars. This workaround is not
acceptable for trading.