Announcement

Collapse
No announcement yet.

Partner 728x90

Collapse

How to implement complex, persistent long-running Strategies?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    How to implement complex, persistent long-running Strategies?

    Hi. So I have one of those complex, persistent, long-running strategies
    and of course it is implemented as an assembly DLL since it has several
    dozen classes.

    Elsewhere on this forum, when I was starting out, implementing a Strategy
    subclass; to be attached to a chart; I suffered through the discussion on
    "clones" and just which one of the clones was to "survive" and become the
    fully elaborated Strategy instance.

    I solved that problem, not without a lot of issues; and have been using
    this unmanaged Strategy for a while now.

    However, for not much reason I can determine, the Chart to which the
    Strategy is attached; decides that it is going to alter or perhaps reset, or
    perhaps simply send a Terminate State to the Strategy instance...
    ...thus making this quite an unreliable method for me to use.

    Enter the role of the AddOn. So, I was able to compile the excellent
    AddOn example given; and I'm just going to have to re-implement my
    Strategy code, no longer as a Strategy sub-class, but as an AddOn.

    I'd be interested to know of others who have attempted to implement
    complex Strategies as assembly DLL's (unmanaged) and have had
    success in getting run-time stability. Because I simply can't make it
    stable enough to eventually become a long-running Bot, for example.

    Now, implementing as an AddOn is, of course, possible; but the "support
    inheritance" of the Strategy base class is absent; and so quite a few
    things need to be different, including Order Entry, etc...

    But that's not a problem at all. What I'm looking for is long-running stability;
    and so I'll just add to this thread some of the key milestones and challenges
    I encounter as I re-implement my Strategy as an AddOn.

    hyperscalper

    #2
    Hello Hyperscalper,

    Thanks for your post.

    We can leave this thread open for community feedback on transitioning to an AddOn as opposed to using a self contained strategy.

    AddOn Freamework code can be used to submit orders and track order/execution/position at account level. If this is ultimately what you are going for and do not want to utilize features like Strategy Performance Reports, this may work out for you, but to many, transitioning away from a NinjaScript strategy and reimplementing in an AddOn might be significantly more difficult.

    AddOn's cannot use indicators as freely as we can in strategies, so if you want to adapt to an AddOn this may be a challenging part as you would have to modify your indicators to work without Series objects so you can implement in an AddOn. (This would involve using Bars.Get in many places.)

    However, for not much reason I can determine, the Chart to which the
    Strategy is attached; decides that it is going to alter or perhaps reset, or
    perhaps simply send a Terminate State to the Strategy instance...
    ...thus making this quite an unreliable method for me to use.
    If this is the underlying reason why you have moved to AddOn Frame than from a strategy, I would like to flush this out as it it will likely just involve an understanding of the State system and the NinjaScript LifeCycle. Keep in mind, a NinjaScript strategy is spawned so it can be added to a Strategies dialog, once it is configured, and once it starts. Each instance that is spawned there will pass through states, but the instance that actually starts processing could be identified as the script that hits State.DataLoaded. If you set a bool to true in State.DataLoaded and check for that bool in State.Terminated, we can add a print to tell us when the final State.Terminated for the active script occurs.

    I think you are best off sticking with a Strategy, but understanding when your scripts are changing states will need to be better understood if that is an issue for you.

    If you add a print in OnStateChange for State so you can see when the State changes, could you describe some scenarios you are seeing the state change where you would not expect? If you let us know some specific cases, we can share our insight. If we can reproduce them with a simple test script like I have attached (or with some modifications) that can help us get on the same page as well.

    Further detail on states and the NinjaScript LifeCycle can be found below for the thread's reference.

    OnStateChange - https://ninjatrader.com/support/help...tatechange.htm

    NinjaScript LifeCycle - https://ninjatrader.com/support/help...fecycle_of.htm

    We look forward to assisting.
    Attached Files
    JimNinjaTrader Customer Service

    Comment

    Latest Posts

    Collapse

    Topics Statistics Last Post
    Started by aslane, Today, 02:50 AM
    0 responses
    3 views
    0 likes
    Last Post aslane
    by aslane
     
    Started by fx.practic, Today, 02:07 AM
    1 response
    10 views
    0 likes
    Last Post NinjaTrader_Marco  
    Started by Ousher, Today, 01:29 AM
    0 responses
    8 views
    0 likes
    Last Post Ousher
    by Ousher
     
    Started by tonynt, Today, 01:23 AM
    0 responses
    4 views
    0 likes
    Last Post tonynt
    by tonynt
     
    Started by cmarkb, Today, 01:18 AM
    1 response
    11 views
    0 likes
    Last Post cmarkb
    by cmarkb
     
    Working...
    X