CrossOver, CrossUp and CrossDown Indicators
ahmadazizi opened this issue · comments
In technical analysis it is very common to detect crossover of some indicator with other indicators or the price.
For example when the shorter-term MA crosses above the longer-term MA, it's a buy signal and can be used to identify trend direction.
As CrossOver, CrossUp and CrossDown are behaving just like other financial indicators, in some frameworks they are categorized under indicators which I believe is a good idea.
In blankly, I noticed there is nothing to assist detecting crossovers and this results a lot of code duplicates. I recommend to have it in the core package.
This could be true, I'm happy to accept a contribution for this. In general its been an architecture decision to leave as much up to the user as possible, there are still a ton of variations on how to detect a cross, if multiple crosses occur how it should be threaded, how to deal with market hours and opening/closing volatility - stuff like that so it's been difficult to know what the best algorithm is for general use.
I think most of the part you have mentioned could be up to the user. Just something as simple as what you have done in GoldenCross example would be enough. Something that takes two parameters and detect crossing.
Since I'm new to the platform, I would love to know what happens to the the indicators on each price event; do they recalculate from scratch on each update?
In this case the user can recalculate on each update, we don't run any indicators in the background.
I don't understand the relationship between indicators and multithreading or background processes. They can be just states within the context of a strategy or price event that update their state by each price update.
I have reviewed some code including SMA indicator and GoldenCross example, It looks like the way you have implemented the indicators and this example, they recalculate on every single price update which is not efficient.
The indicators are just helper functions to avoid finding other 3rd party packages. There is no relationship between these functions and other contexts because they're stateless helpers. If you're using other paradigms, implementing a state good for your use case could be optimal.
For the run frequency of golden cross (1 hour) compared to the runtime of recalculating an indicator (a few microseconds) the recalculation cost is trivial and not worth optimization. Many optimizations can be made to accelerate the examples they are there for clarity and learning.