Addition of Interactive Brokers Algorithmic orders

[sicsix]

I have added optional parameters to the orders to allow setting an IB Algorithm via enum OrderAlgorithm to MarketOrder(), LimitOrder() and SetHoldings(). Settings for the algorithm are stored in class AlgoParams.

The OrderAlgorithm and List[AlgoParams] are passed all the way through to the IB ordering API where the OrderAlgorithm enum is decoded into a string corresponding to the IB Algorithm API requirements, eg. OrderAlgorithm.ArrivalPrice becomes "ArrivalPx". List[AlgoParams] is recast(???) into List[TagValue] and sent off to IB with the order. (I used [ instead of < because it doesn't seem to work here)

SetHoldings() functions by design as synchronous, so allowing IB algos to be used might be a bad idea, as the IB algos can often take a lot longer than a normal market order to resolve.

Backtest results are not changed by setting an IB algo, a market order is a market order IB algo or not.

I'm very new to C#, a novice at programming and this is my first time on GitHub so I hope I haven't made too many mistakes.

[mchandschuh]

I think this requires some thought/design/input by others on the QC team. @StefanoRaggi - perhaps this is another use case for the order parameters stuff you did for FA accounts?

[mchandschuh]

Please revert changes to this file.

[sicsix]

Will do, this wasn't supposed to be committed.

[mchandschuh]

These are specific to interactive brokers and should be under the QuantConnect.Brokerages.InteractiveBrokers namespace -- still located in the Common project -- but we may want a more generalized way of handling brokerage specific order parameters rather than having to define special types for every brokerage -- so not sure how I feel about this yet

[sicsix]

I had an idea this morning to pass a single class through the ordering system instead of the two IB specific variables in this pull. Something like OrderExtra contained in it's own file. Inside that would be special parameters for every broker that are individual to that broker.

So for example I could set OrderExtra.IB.Algorithm.AdaptiveAlgo and pass the parameters through in the same way.

This would be cleaner and broker agnostic, and any extra order options could be added to the OrderExtra class for any broker.

Thoughts?

[sicsix]

Added a different solution. The new class in OrderExtras.cs is a bit of a mess but the general idea is there.
EDIT: I don't know where BenchmarkAlgorithm.cs came from, it doesn't even exist in my IDE. Ignore that diff.

[sicsix]

@mchandschuh has a good point. After looking at @StefanoRaggi Financial Adviser pull request, I've basically ended up duplicating his work for passing more order properties through. This algorithm selection stuff would fit perfectly into his new OrderProperties class.

[jaredbroad]

Thank you @sic, tidy PR overall! We'll review and squish this into the FA PR and see if we can add the advanced orders quickly after.

@StefanoRaggi - Perhaps the default OrderProperties should be empty & have Brokerage Specific implementations? i.e. "InteractiveBrokersOrderProperties"

Then users could set the order default properties for their fav brokerage?

//In initialize:
DefaultOrderProperties = new InteractiveBrokersOrderProperties() {
      FaGroup = "",
      OrderAlgorithm = InteractiveBrokers.OrderAlgorithm.DarkIce
}

[mchandschuh]

@sic8 - We've added a new type, InteractiveBrokersOrderProperties which implements IOrderProperties. This allows for brokerages to define properties specific to their api. You could try reworking what you've done by using the order properties.

• Start clean from a fresh QuantConnect/Lean/master
• Add Algorithm specific parameters to InteractiveBrokersOrderProperties
• In InteractiveBrokersBrokerage check for the algorithm parameters via the order.Properties

[jaredbroad]

Closing for now but this isn't too far off; lets do a new PR and leverage Stefano's work =)