QuantConnect Community

Hi Tim De Lise ! Please post this to the open source LEAN group:

https://groups.google.com/forum/#!forum/lean-engine

This is due to the limits of numerical precision in decimals (30 digits). Instead of trying to calculate them more accurately you should request the raw pricing for the asset. 

Hi Jared I'm afraid the problem is more serious than just a decimal rounding issue.  I adjusted my effective leverage down to about 20% of what is full leverage and still have the margin errors when i go back to 2016, but not in 2017-2018.  

I also noticed a straight equity algo that was posted by Jing Wu, which had backtesting back to 2008.  I didn't inspect the calculation for weight allocation too closely but it was a strategy worked on by several traders.  When I cloned it and ran the backtest I also saw lots of these margin errors, so effectively the orders were not placed because the system thought the portfolio wouldn't allow that amount of leverage.  Again that could be erroneous weight calculation in the code but I thought it stranget hat no one else brought up that issue with the algo.  

The data normalization mode looks like it might help for doing some calculations, but from my perspective this shouldn't affect the margin calculation.  The backtester should accurately calculate the margin requirement no matter when kind of data I choose to use for the algorithm.  I could be wrong about that though, and I will play around with that.

I'm pretty sure this illustrates is the problem:

All options contracts in historical data are based on normal prices.  So back in 2016, I wanted to buy 10 contracts with a strike price of $20.00.  That is equivalent to 1000 shares of underlying, which would be $20,000 of underlying.  But I am proposing that the lean backtester is then using the adjusted historical price, which could be like $1000 dollars per share.  If this is the case, the backtester is thinking that the underlying is 1000 shares at $1000 so it would require margin for $1,000,000 of underlying.  Hence not allowing me to trade.

Using the adjust price for straight trading equities is OK, since in backtesting I also assume the historical price of the equity is the adjusted price.  so to get $20,000 of exposure, with adjusted hist price of $1,000 I would only trade 20 shares, instead of 1000 shares at the real price of $20.00.  But with the options contracts, using this adjusted price for margin requirement calculation isn't working.  

Would it be possible to give an option in the brokerage model to completely disable all margin requirements?  Obvioulsy this is not ideal but it would nice to be able to run a backtest without having to worry about the backtesting engine disallowing trades based on margin requirements.

My Mistake, apparently someone else did bring up the margin error issue on that equity post I linked.

Options trading does not support adjusted pricing precisely because of the strike price. If you look in the console you should see warning messages when you're asking for adjusted data. This is automatically changed to request raw data.   

You can effectively disable leverage by simply setting it very high. You can also model it with say 100x your actual capital.

Wiithout an example algorithm its hard to give more assistance. Please attach a backtest of something specific and we can assist further. 

Hi Jared.  I am attaching a backtest which runs the first 2 months of 2016.  In my console I have many instances of this error message:

Backtest Handled Error: Order Error: id: 35, Insufficient buying power to complete order (Value:-23490), Reason: Id: 35, Initial Margin: -23491, Free Margin: -70410.49999999999999999999995

and in the Logs you can see a printout.  Each time through the optionchain I print out the underlying symbol and price.  The incorrect price is for DUST:

2016-01-04 15:50:00 : DUST 755.0
2016-01-04 15:50:00 : NUGT 21.088

THis continues throughout the backtest.  The other symbol in the backtest, NUGT seems to be OK, around 20.  SO this is the issue that I have been seeing.

So I've been debugging this for some time.  I have noticed if run the same backtest with only DUST, not both DUST and NUGT, then the DUST prices are perfect.  When I add NUGT to the mix, the NUGT prices are good, but the DUST prices then go to the adjusted priced, even though the price normalization message is present for both underlyings.  I think we are getting to the bottom of this.

2016-01-05 15:50:00 : DUST 15.27

SO my conclusion is that this error is not present with 1 underlying stock, but YES this bug is present when running 2 underlyings.

Jared Broad Sorry for the rambling on here, but I just found that if I explicitly set the price mode to Raw for each of the underlyings, then the prices seems to come out correct.  In the backtest I had commented that line out.  So it seems pretty good with the price mode set to raw.  However I think there are still issues with the backtester simulated the automatic assignment of short contracts.  This is a nice feature but seems to be a bit funky.  I'm not quite sure how it is supposed to be working, since the underlying is never actually added to the simulated portfolio.  Anyways I should prob open a fresh thread for that.  

Actually if you can post things you think may be bugs to support@quantconnect.com so the engineering team can review and assess. Using the forums as bug tracking software is inefficient for everyone.