Dukascopy
 
 
Wiki JStore Search Login

Attention! Read the forum rules carefully before posting a topic.

    Try to find an answer in Wiki before asking a question.
    Submit programming questions in this forum only.
    Off topics are strictly forbidden.

Any topics which do not satisfy these rules will be deleted.

Parallel Strategy Backtesting
 Post subject: Parallel Strategy Backtesting Post rating: 0   New post Posted: Sun 03 Feb, 2019, 16:39 
User avatar

User rating: 0
Joined: Fri 02 Mar, 2018, 09:51
Posts: 3
Location: Italy, VIGODARZERE
Dear Support,
I implement a function to optimize my strategy in the SDK environment. If I run the optimization using only one strategy at the time, all backtest results are identical to JForex platform optimization results, but if I run more than one strategy at time all results are mistaken... After a lot of tests, I noted that, since in my strategy I need to check filled orders at every new candle forming, the single running strategy is not able to recognize its own orders. In other words, each order is visible from every running strategies. How is it possible?? IContext of each strategy should be visible only its strategy and not from all others ones??

How can I open an order in one strategy and make this visible only for that strategy and not from all others ones?

thanks!
Regards


 
 Post subject: Re: Parallel Strategy Backtesting Post rating: 0   New post Posted: Mon 08 Jul, 2019, 03:02 
User avatar

User rating: 70
Joined: Sat 22 Sep, 2012, 17:43
Posts: 118
Location: Brazil, Fortaleza, Ceará
Orders belong to the Account owning the equity and margin used to generate those orders.
Any IContext created and connected to an Account should have access to all Order information connected with that Account.

This is both logical and correct.

Strategies are logical groupings of execution flow often operating on the same Account.
If there is a need to distinguish Account activity on a strategy by strategy basis then commenting and/or labelling the activities we wish to later identify is the answer.
The 'problem' described in the post above is a non-issue if we make use of the ability to add Comments and/or Labels to order submissions.

Consider the following options which make it possible for strategies to see all orders but at the same time isolate the ones that originate with them through string prefix-, -suffix or contains checking:

Interface IEngine
IOrder submitOrder(String label, Instrument instrument, IEngine.OrderCommand orderCommand, double amount)
IOrder submitOrder(String label, Instrument instrument, IEngine.OrderCommand orderCommand, double amount, double price)
IOrder submitOrder(String label, Instrument instrument, IEngine.OrderCommand orderCommand, double amount, double price, double slippage)
IOrder submitOrder(String label, Instrument instrument, IEngine.OrderCommand orderCommand, double amount, double price, double slippage, double stopLossPrice, double takeProfitPrice)
IOrder submitOrder(String label, Instrument instrument, IEngine.OrderCommand orderCommand, double amount, double price, double slippage, double stopLossPrice, double takeProfitPrice, long goodTillTime)
IOrder submitOrder(String label, Instrument instrument, IEngine.OrderCommand orderCommand, double amount, double price, double slippage, double stopLossPrice, double takeProfitPrice, long goodTillTime, String comment)

  • label - user defined identifier for the order. Label must be unique for the given user account among the current orders. Allowed characters: letters, numbers and "_". Label must have at most 256 characters.
  • comment - comment that will be saved in order

Interface IOrder
String getComment()
Returns comment that was set when order was submitted

String getLabel()
Returns label


 

Jump to:  

cron
  © 1998-2024 Dukascopy® Bank SA
On-line Currency forex trading with Swiss Forex Broker - ECN Forex Brokerage,
Managed Forex Accounts, introducing forex brokers, Currency Forex Data Feed and News
Currency Forex Trading Platform provided on-line by Dukascopy.com