Find the IV for this...

Robert, you think in practical terms, that's fine,
but I just wanted my program to be able to calculate the IV even for such option parameters, since they are legal and valid parameters as can be seen.
 
When this is Nov, and the next one is Dec, best process is to take options with no bid and ignore them along with their put/call other strike.


upload_2021-11-14_18-43-25.png


upload_2021-11-14_18-43-47.png

upload_2021-11-14_18-44-57.png
 
thecoder said:
It seems your program can calculate the IVs correctly according to the 1st chart in your this posting:
https://www.elitetrader.com/et/threads/find-the-iv-for-this.362833/page-2#post-5488945
What's the name of your program?
As said, YahooFinance can't (cf. the posted Put table: the IVs of the higher strikes are wrong or just some pure fantasy numbers! :)), and unfortunately also my program can't as well :-(
More...

It has been said that "volatility is the wrong number to put in the wrong formula to get to the right price ... "

Sometimes there is more darkness than light when exploring options concepts ...
 
The reason why most, if not all, of the IV finder programs can't find the IV for the said parameters (as well for other higher strikes in the posted Put table) is that it seems that there is a (or should I say another?) BUG in Black-Scholes-Merton (BSM)!

I've located the bug: it's in the Put/Call parity logic! It for some params (like those used here) gives a negative value (ie. negative Premium), so the solution is/was to make this: Premium = max(0.0, Premium). But this kludge just hides (ie. covers up) the bug!

Unfortunately I could not come up yet with a fix :-(
As next I'll test whether my FairPut algorithm handles those corner cases better than BSM.
 
Last edited:
thecoder said:
The reason why most, if not all, of the IV finder programs can't find the IV for the said parameters (as well for other higher strikes in the posted Put table) is that it seems that there is a (or should I say another?) BUG in Black-Scholes-Merton (BSM)!

I've located the bug: it's in the Put/Call parity logic! It for some params (like those used here) gives a negative value (ie. negative Premium), so the solution is/was to make this: Premium = max(0.0, Premium). But this kludge just hides (ie. covers up) the bug!

Unfortunately I could not come up yet with a fix :-(
As next I'll test whether my FairPut algorithm handles those corner cases better than BSM.
More...

I suspect that you are simply re-inventing the wheel here.

The reason that you could not calculate IV was that the deep ITM put option price was being quoted below parity.

In practice, there are a number of effective ways to deal with this, rather than simply insult the BS formula,

1. Clean your data ... relying on Yahoo!Finance is not recommended ... at least for American style options ... ensure that your ITM put options do not trade below parity ... see what IV you generate if you use a price of 95.60 v 95.40

2. Use OTM options to calculate IV
 
  • Like
Reactions: PPC
@jamesbp, good advice re parity, thx, will apply, yes, should fix the issue, indeed; am going to apply & test.
Also thx to Robert, who said similar things re parity.

Man, glad I'm not the only one as even the giant YahooFinance doesn't know this simple parity fact as the posted Put table of them shows & proves.

Update:
Code: 
PgmArgs: ./options_tester.exe IV_finder 0 93.40 95.20 95.40 4.40 100.0 6
Params: fC=0 Last=93.40 Bid=95.20 Ask=95.40 S=4.40 K=100.00 DTE=6.000000(t=0.016438) rPct=0.000000(r=0.000000) qPct=0.000000(q=0.000000) DaysInYear=365.000000 MaxSteps=50 ErrPct=0.000001
Pr=95.300000
DBG: via P/C parity: rawCall=-0.3000000 Call=0.0000000
ERR: Given Last/Bid/Ask produces negative rawOppositePremium! Ie. the calculated Premium of 95.300000 is below Parity. Please fix.
:)
Not done yet, but looks good so far...

Update2: of course DividendYield and EarningsYield could also be the cause for the Parity discrepancy... But then things become really complicated... I think for IV calc one can omit them...
 
Last edited:
I need to find a way to make it parity-conform by computing an artificial value for the r parameter... Then it should work, IMO.
 
You must log in or register to reply here.
Back
Top