Hello,
Is there currently an extension of some kind for rules based systems that would allow the use of indicators to be used in play of static numbers?
If I have an indicator such as ADX with 12 days back can I replace that with formula containing other indicators and formulas? I need to make the argument in the code including indicators and arithmetic formulae. All arguments that are variable or constant need to be able to be replaced other indicators combined with arithmetic formulae.
Thank you.
Size:
Color:
Size:
Color:
At first I thought it might be something to consider for a future release of Community.Rules i.e. expose a group of popular conditions e.g. "Adaptive indicator does this and that". The $64K question is: how to make
any given indicator adaptive? Even the adaptive lookback is not a silver bullet for all types of indicators or time frames.
QUOTE:
All arguments that are variable or constant need to be able to be replaced other indicators combined with arithmetic formulae.
No need to reinvent the wheel: it's known as the (WealthScript Strategy) Editor :) Seriously, that gives you control over indicators and arithmetic formulae. An "Indicator Builder" that requires no programming may be an interesting concept but only in theory. If one is able to create
new, adaptive indicators by defining their formulae then coding it in intuitive and easy C# should certainly not be a big effort to him either.
Size:
Color:
QUOTE:
The $64K question is: how to make any given indicator adaptive?
One solution is to make the "targeting threshold" for these indicators adaptive instead. Currently, the only adaptive thresholding paradigm WL has doing this is VK_SH_Band, VK_WH_Band, VK_SL_Band, and VK_WL_Band, which are presented as WL "indicators" (although they aren't really) in the Community.Indicators library.
Sometimes these said indicators behave oddly, perhaps because of either an implementation or design problem, but that's another discussion. But employing such an adaptive triggering threshold methodology is a good idea in principle. We need more options like this in WL.
Size:
Color:
Can't say that I'm thrilled with applying the targeting threshold of VK/VKW bands to a
non-price DataSeries like RSI. But maybe I'm doing something wrong. Could you please clarify your idea?
CODE:
Please log in to see this code.
Size:
Color:
The code you have in Port# 5 isn't going to work as a trading strategy because there isn't any trading FOR loop buying and selling positions. As a result, there's nothing to perform thresholding (for buying or selling triggering) on in the first place.
What you do is let the RSI reach a threshold, which triggers a Buy or Sell order. And you let that threshold be dynamic with VK/VKW bands. RSI needs to cross those bands to trigger a trade action. Does that make sense?
This approach should work with any indicator. When that indicator crosses the VK/VKW bands, it triggers a trade action. In practice, you would want several criteria (each with a different indicator and threshold) triggering at once before a trade action in performed.
---
If you really want to get fancy, you can add norms into the "trade action" triggering evaluation process. But that's a whole another topic. Math.NET supports norm evaluation for criteria testing. So does MathLab.
Size:
Color:
QUOTE:
The code you have in Port# 5 isn't going to work as a trading strategy because there isn't any trading FOR loop buying and selling positions.
How having a trading loop is going to help the idea of making any given indicator adaptive? The way I understood OP's request (re: ADX 12-period), it's about dynamically setting the indicator's
period from a Rule-based Strategy's interface. (This isn't going to happen for reasons in post #3).
QUOTE:
RSI needs to cross those bands to trigger a trade action. Does that make sense?
Yes (code below does that). But if I understand correctly, what you're proposing isn't much different from a concept cited in post #2 ("
Adaptive Stochastic indicator") which uses Bollinger Bands to set the oscillator's thresholds dynamically. It applies to oscillators but isn't focused on solving the problem of making the
period adaptive. Not all indicators have thresholds but most indicators have a period, and this is where the Adaptive Lookback indicator may help.
CODE:
Please log in to see this code.
Size:
Color:
QUOTE:
if I understand correctly, what you're proposing isn't much different from a concept I cited in post #2 ("Adaptive Stochastic indicator") which used Bollinger Bands.
No, the adaptive part there is changing things temporally (i.e. the period). But the VK/VKW bands are adaptive on the ordinate (vertical), not the abscissa (time) direction. We have our axes mixed up.
And it doesn't matter whether the ordinate is about price or some other index. The math is the same. Is this making sense?
Add a trading loop to Post# 7's code and I'll fill in the details. Perhaps an example it what we need.
---
In practice, you might want to have
both the ordinate and abscissa adaptive.
Size:
Color:
Unfortunately, it doesn't ring a bell to me. Care to show an example?
Size:
Color:
Well, I can't seem to make the VK bands work the way I thought they did, so let me retract what I said about them (above); their behavior is different than what I remembered. (Although I originally employed VK bands years ago, today I use my own adaptive thresholding code that's based on robust statistics, which works predictively.)
But let me give you the code a wrote in the last hour. It illustrates what I "thought" the VK bands could do adaptively--for what that's worth. :(
Perhaps you can get the VK bands to adapt to the indicator (I'm employing the TII indicator here.) better than I can. I cannot get them to track this indicator as expected--unfortunately.
CODE:
Please log in to see this code.
Size:
Color:
Right, the VK Bands don't seem to be as reactive as long-period Bollinger Bands in setting an indicator's thresholds dynamically. Your code seconds mine from post #7.
Size:
Color:
The robust statistical way to do this is with a
streaming Percentile Approximation, PercentileApx() indicator, which WL doesn't have. I've been meaning to write one for WL, but I haven't had the time. There's a
Dr Dobb's Journal article about approximating percentiles (It has been a popular research topic.), but I don't recall the issue. Some approximation algorithms are cited here,
https://stackoverflow.com/questions/1248815/percentiles-of-live-data-captureI know you're thinking you could use the SortedSet .NET datatype (which keeps a running sort) to solve for streaming percentiles exactly where IndexOf() would return the rank of any position. And that's true, but it would be a
big waste of cpu power to compute it exactly for a fuzzy system problem. Employing an approximation makes much more sense for a WL indicator.
Math.NET does have some percentile functions, but they aren't streaming. So they are inappropriate for a WL indicator.
Size:
Color:
I believe that to gain mass adoption, adaptive indicators should be more intuitive and less challenging than what you're proposing.
Size:
Color:
QUOTE:
... adaptive indicators should be more intuitive ...
Although robust statistics is challenging (It's a graduate study.), I don't think the PercentileApx() indicator would be hard to use. In contrast, my own robust statistical thresholding routine is hard to use, and that's partly why I haven't released it. One needs to create a "beacon" DataSeries to pass into it, which steers it. That's a time series of
merit over time for trading opportunities. There are many ways to craft the beacon, which makes it confusing to build. But the thing is a beast; it can make an otherwise wimpy stock profitable. And it can dynamically track thresholding for any indicator.
I honestly think there's something wrong with the VK bands indicator. I cannot say if it's the algorithm (I haven't read the article.) or the code implementation, but it's behavior is wrong. It's doesn't track as expected and it can occasionally have spurious behavior. That just isn't right. I think the principle behind it is a good idea, though.
Size:
Color: