I have a recurrent issue with the theorical price of a Call or Put.
Example 1: the price is the price at expiration (so often 0)
Example 2: a correct price only at bar+1

It's clearly wrong. Any idea?

CODE:
Please log in to see this code.

Log result in daily scale:

CODE:
Please log in to see this code.

1. So what is wrong here, the option price after expiration i.e. contract.Close[bar+1]?

2. What do you think is clearly wrong in the 2nd example?

Ok. I understood the issue. The Series of contract starts from startDate so I was not in the same "bar".

bar,Bars.Date[bar],Close[bar],option.Date[bar],option.Close[i]
31,11/16/2016,36.8,11/21/2016,5.58850757838319

But with this shift, it's not clear the bar to use to buy.sell:

Usually we buy at bar+1 but for an option it seems incorrect:

CODE:
Please log in to see this code.

Same question to Sell?

Discard my previous post. I don't know how I had this shift. It was probably a wrong code because I can't reproduce it.

But I still have an issue about the price of an option.
I noticed that if an option is created at bar, the Close of the option is correct from bar but from 0 to bar-1 it's incorrect. From bar-1 to 0, it contains the value at the expiration, so 0 or abs(Close - strike).
Can you clarify your model because these values are incorrect.

Even if I don't need the past (bar-x), I also noticed that if at bar-1 the Close of the option was 0 ShortAtClose(bar) generates a Runtime Error (Position Entry cannot be zero) even if the Close of the option at bar is NOT zero.

CODE:
Please log in to see this code.

Here are the results if the option is created at bar=30 which is 1/30/2017

Date[30]=1/30/2017 12:00:00 AM
put.Symbol: !AAL_45.00_170317_PUT
Date Close put.Date put.Close
1/26/2017 12:00:00 AM 49.59 1/26/2017 12:00:00 AM 0
1/27/2017 12:00:00 AM 46.950001 1/27/2017 12:00:00 AM 0
1/30/2017 12:00:00 AM 44.900002 1/30/2017 12:00:00 AM 2.05577461567276
1/31/2017 12:00:00 AM 44.25 1/31/2017 12:00:00 AM 2.3698234854946
2/1/2017 12:00:00 AM 44.049999 2/1/2017 12:00:00 AM 2.44734183692847

As you can see Close[30]=2.05577461567276 but a ShortAtClose(bar) will generate a Runtime Error Position Entry cannot be zero.
You can reproduce it for any instrument.
Can you please check this issue?

Note:
I only checked Close but I guess the issue is the same for Open

QUOTE:
As you can see Close[30]=2.05577461567276 but a ShortAtClose(bar) will generate a Runtime Error Position Entry cannot be zero.

Haven't had an issue executing your code coupled with various BuyAt*. I believe that the bar before is looked up by WLP for purposes of position sizing (basis price).

Here's the complete script and setup...

1. Symbol: AAL
2. Daily bars from 12/14/2016 to present
3. This script

CODE:
Please log in to see this code.

It's clear from the plot that the put's price is zero on bar 29 (and prior), therefore a basis price cannot be calculated for the trade. Buy why is the price of the synthetic option zero for bars 0 to 29? I'm not sure, yet.

It seems that there are bugs in the pricing model:

1. If the price of the underlying is above the strike prior to bar 30, then the put option is priced at zero.
2. Looking at the plot using Candlesticks, it's clear that there is a serious problem with the OHLC values of synthetic put contracts (calls are okay in this sense.)

We'll mark this as a bug. Thanks for pointing out the problem, and our apologies for the inconvenience this has caused.

Thank you for your investigation.

For me, there are two differents bugs:
1- The incorrect pricing model for the price from 0 to bar-1 for Put and Call. It's the "future" value at expiration so 0 or abs(price-strike).
It's less "visible" when it's not 0 but it's also incorrect.
2- When the Close at bar-1 is zero (bug 1), ShortAtClose(bar) uses Close=0. If the Close at bar-1 is not zero it seems correct it will use Close of bar.

What is the process to have a patch? Is it every month,year - or not fixed date...
Waiting for a patch do you have a workaround? (for point 2 - maybe to ShortAtLimit using Close of bar)

Cone, I was wondering if there has been a fix for synthetic put contracts? I am interested in backtesting bull credit spreads, and i want to make sure I am getting accurate results.

Thanks.

Hi jecjackal -
We're gearing back up for our first update in [..a long time..] and we have several higher priority client issues to take care of first. After that, we should be back on a schedule for more periodic updates and this one is on the list. Thank you for posting and your interest in the synthetic options feature!

Thanks for the update!

Hi jecjackal et.al.,
We got back to looking at synthetic options and the only 'error' found was that the high/low values of Put bars were reversed. You can't tell it by just looking at the chart (to see it you need to debug the values). This issue would affect stop/limit fills for Synthetic Puts and is fixed for the next upgrade.

Back to what we we're looking at above - it's been > 2 years :o

Re: post #7 and prior
Those issues are due to how the model calculates (or rather does not calculate) implied volatility. You'll find that implied volatility is not a direct calculation - there's really no way to find it without actually knowing the real market price of the option contract.

Instead, the synthetic model uses HistoricVolatility - the HV.Series indicator. And what's the period? You guessed it: 30 bars. Consequently, our error above was to assume that option pricing is available within those first 30 bars. Now we know to expect zero for synthetic option pricing within the first 30 bars of the underlying.

Also, as I recall, my initial analysis was flawed because the script used above was based on bar numbers and not dates. By changing the analysis period, different option contracts were being selected. If you use this code below and a date range ending on 3/14/2017, you'll see the option pricing for the contract (selected by the price on 1/30/2017) is deterministic and can be extended in the past by adjusting the starting date of the underlying.

CODE:
Please log in to see this code.

Take-aways:
1. High/Low values for Puts are currently reversed (6.9.20.7 and prior)
2. You need at least 30 bars of the underlying before the "start bar" of your synthetic contract so that the HV calculation can contribute.
3. If a synthetic contract's value is zero, it's probably because you don't have #2 or it's beyond the expire date.

We don't have a way to calculate Implied Volatility (or the real price of an option contract for that matter) for Synthetic contracts. Those who develop strategies for option trading can use synthetic contracts for that purpose, but you're encouraged to get some real price data to double check how your strategy would have actually performed.

Thanks for.the update Cone!