Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I am attempting to code Strategy which will call several other indicators. I am wondering if there is any overhead associated with the Plot logic that would not be used by my Strategy.
IOW, I am wondering if I should have Indicators that just perform necessary calculations and establish the necessary "get" Properties to retrieve the needed values.
I am guessing the answer is "no" as I don't see this mentioned anywhere.
@tornadoatc: This depends on the way you code your strategy. If you add an indicator via the Add() method, then you will effectively add a plot to your strategy, and that plot will be visible, when the strategy is activated on your chart or in the strategy analyzer. In that case there is an overhead associated as the plot is running.
Example:
adds an indicator to your strategy for the purpose of plotting it!
If you just call an indicator from OnBarUpdate(), then ChartControl has the value "null" when the indicator calculations are performed, and there should be no overhead associated with calling the indicator.
If you calling an external indicator in OnBarUpdate, you should call a previously declared and instantiated, reusableinstance of the external indicator.
Just as in an indicator, that instance of an external class can be created in OnStartUp, or in OnBarUpdate with a null test condition to ensure that the instance is not RE-created if it already has been created, ie is not null.
"If we don't loosen up some money, this sucker is going down." -GW Bush, 2008
“Lack of proof that something is true does not prove that it is not true - when you want to believe.” -Humpty Dumpty, 2014
“The greatest shortcoming of the human race is our inability to understand the exponential function.” Prof. Albert Bartlett
So following some of your previous postings that I believe you both may have contributed to I am creating an Indy that has the following
So does this method of instantiating the above ibdDM indicator eliminate the overhead of associated Plots?
Also, other Indys I am working with have required inputs for Plot Colors. I tried to pass in "null but it did not like "null" in those instances so I just passed in Color.FromKnownColor(KnownColor.GhostWhite).
While I am still learning C# (and probably will be for a long time) I am wondering if the use of a Partial Class might be of use for what I am trying to describe.
So I want to call other indicators / classes for use in more complex Indys or Strats. There are two issues currently wondering:
1) I do not want any overhead associated with Plot functionality
2) I sometimes only need most recent value of an Indy but the current implementation of that Indy might only be setup to return the entire DataStore. IOW, is it less efficient to return entire DataSeries (or even calculate them) if only most recent values are needed?
So, can these concerns be alleviated with use of a partial class? IOW, can I create a partial class where I would create calculations within a separate file that I can used over and over in other Indys or Strats? Can this class have multiple Properties that enable return of all the calculations I might need.