QuoteOriginally posted by: Cuchulainn(Counter)example, Black modelF = K = 1T = 1r = 0ThenC = N(d) - N(-d) = 0 (1) (My thesis is this does not always have a solution, e.g. C = 10 ==> sig == ?? and sig = 0, C == ??)where d = sig/2.So, if I have done my arithmetic then (1) has or has not a solution.Is this a solution for F=K?from eq (2.4) of By Implication [$]\hat\sigma = \frac{-2}{\sqrt {T}}\cdot\Phi^{-1}\left(\frac{(1-\beta)}{2}\right)[$]where [$]\beta = \frac{marketPrice }{e^{-r T}\cdot\sqrt{F K}}[$]and [$] F = S \cdot e^{b T}[$]http://www.pjaeckel.webspace.virginmedi ... cation.pdf

Last edited by tthrift on December 18th, 2014, 11:00 pm, edited 1 time in total.

QuoteOriginally posted by: CuchulainnQuoteYour idea to try minimization instead of zero crossing finders does seem to catch more solutions. ( ie. least squared error/brent )It was a great suggestion!The idea was triggered by the wish to be able to find a solution in all cases, even if it is 'only' a best solution in some generalized sense. When there is a solution it will be the same one as we would get with NR, for example.The idea can be seen as a generalization of the matrix casePaul Wilmott has an example in his third volume page 874 of a contract producing two vols as a solution! (you get positive and negative vega).My concerns are:1. 2 solutions, so Brent might find the wrong one. In that case we need a global optimizer. If there is more than 1 solution, Differential Evolution will find the global minimum which may or may not be the same at that produced by Brent.2. No solution, so LS gives the 'best' one. 3. There is a unique solution.These are niggly questions and they have consequences for conclusions for the data coming out of the code IMO.I need something like Lefschetz fixed point theoremI have just read that Sage has code to count the number of fixed points. It's in the package somewhere.I read a bit about the topology and failed to find the counting code at sage.Pretty interesting stuff like "at least one fixed point exists" and beyond.While I think I might get the gist of the goal, I don't understand enough to be useful. However, I appreciate your showing me what is involved. I share your concern regarding the uniqueness and existence of a single inverse solution for iv from price using vanilla BSM options.My personal uncertainty is hard to eliminate, since my math background is not strong enough for me prove that is the case.But from a practical perspective I am not too worried about it at this point.If my understanding is correct, volatility increases monotonically with vanilla BSM option price.So I would expect one and only one iv corresponding to each valid price ( barring numerical artifacts ).The function has a single inflection point. Price is always greater than zero and less than some max price.The curve should have 1, 2, or 3 fixed points where it intersects the line, volatility = option price.The book example that you pointed out is interesting. As described, I don't see how it applies to the possible existence of multiple BSM ivs for some given price. The uncertainty described there is caused by people's inability to predict the future.It does not seem to me to be due to multiple values of the inverse BSM equation. The example deals with the uncertainty by guessing high and low vols, then calculating a worst case. As far as I understand, while 2 possible vols can happen in the example, one corresponds to being long an option and the other being short.If I'm long an option BSM gamma and BSM vega are always positive.If I'm short an option BSM gamma and BSM vega are always negative. While I might not think a global optimizer is needed, I don't know.I certainly have no objection to running one to see if it might do better.Global optima are also local optima.Thanks,-Terry-

- Cuchulainn
**Posts:**59013**Joined:****Location:**Amsterdam-
**Contact:**

// I had a closer look at Lefschetz. Unfortunately, it is shrouded in algebraic topology terms and I have not been able to find a good example yet.A possible transformation isy = x/(x+1) where x is the option price or the vol. So, my idea is to use this transformation in the Black formula which might help. I have not tried it here but it is very useful in other contexts.This transforms (zero, infinity) to (0,1). Could we now solve as a _constrained_ optimization with 0 <= x <= 1?QuoteGlobal optima are also local optima.But not vice versa.A comparison of several current optimization methods, and theuse of transformations in constrained problemsBy M. J. Box*

Last edited by Cuchulainn on December 21st, 2014, 11:00 pm, edited 1 time in total.

QuoteOriginally posted by: Cuchulainn// I had a closer look at Lefschetz. Unfortunately, it is shrouded in algebraic topology terms and I have not been able to find a good example yet.A possible transformation isy = x/(x+1) where x is the option price or the vol. So, my idea is to use this transformation in the Black formula which might help. I have not tried it here but it is very useful in other contexts.This transforms (zero, infinity) to (0,1). Could we now solve as a _constrained_ optimization with 0 <= x <= 1?QuoteGlobal optima are also local optima.But not vice versa.A comparison of several current optimization methods, and theuse of transformations in constrained problemsBy M. J. Box*I modified the LS solver slightly to get y = x/(x+1) working with price.So far I tried one approach with vol that did not work.Thanks for the paper/reference.I'll read it.( When I glanced at it I had sortof a dega vu. I remember seeing it many years ago. I don't remember what I was attempting to optimize at the time. )

Just some remarks (Spot = 100, Rates = 0, vol = 0.04% for data ?): It does not make much sense to "solve" for volatility if one does nothave a good pricer, which solver ever is used.One can use systems like Mathematica or Maple with high precision forextreme values (if done with care). But fixed precision will alwayshave problems in simply using the usual formula, no matter how goodthe cumulative Normal is implemented:One subtracts 2 terms and that introduces cancellation errors if theyare of same magnitude. That happens if Call ~ 0, i.e. strike very high.For example strike=140 gives terms of 0.23 E-14. And would result in afalse price (or even zero) in careless coding, since the first 2 placeswill cancel out - but the needed trailing 2 places can not be providedfor each single term.And though from Math there is an inversion price <---> vol that is nottrue as soon as one goes to (fixed precision) Numerics. One always canbreak that far OTM (I even have some doubts in numerical monotony here).For that take strike=70. The price of a call is discounted pay off +premium ~ 30 + 0.8 E-19 and that is 30.0 in double precision. Thus itis the price for vol=0: any vol up to 4% (and somewhat beyond) will do.Note that for these 2 examples one does not have to go for strikes beingmore extreme. And having computational costs in mind the answer is notby increasing digits and using Boost, MMA, Maple or fancy solvers.Functionally (having a good pricer) I would implement towards "vega ~ 0then task does not make sense" (though not longer working in that field).Besides that one will not get that price. From Numerics the thing is flawed and "ill-posed".

QuoteOriginally posted by: AVtJust some remarks (Spot = 100, Rates = 0, vol = 0.04% for data ?): It does not make much sense to "solve" for volatility if one does nothave a good pricer, which solver ever is used.One can use systems like Mathematica or Maple with high precision forextreme values (if done with care). But fixed precision will alwayshave problems in simply using the usual formula, no matter how goodthe cumulative Normal is implemented:One subtracts 2 terms and that introduces cancellation errors if theyare of same magnitude. That happens if Call ~ 0, i.e. strike very high.For example strike=140 gives terms of 0.23 E-14. And would result in afalse price (or even zero) in careless coding, since the first 2 placeswill cancel out - but the needed trailing 2 places can not be providedfor each single term.And though from Math there is an inversion price <---> vol that is nottrue as soon as one goes to (fixed precision) Numerics. One always canbreak that far OTM (I even have some doubts in numerical monotony here).For that take strike=70. The price of a call is discounted pay off +premium ~ 30 + 0.8 E-19 and that is 30.0 in double precision. Thus itis the price for vol=0: any vol up to 4% (and somewhat beyond) will do.Note that for these 2 examples one does not have to go for strikes beingmore extreme. And having computational costs in mind the answer is notby increasing digits and using Boost, MMA, Maple or fancy solvers.Functionally (having a good pricer) I would implement towards "vega ~ 0then task does not make sense" (though not longer working in that field).Besides that one will not get that price. From Numerics the thing is flawed and "ill-posed".AVt:Great input.Thanks for your kind suggestions!Especially when you are "no longer working in that field."I have been looking at your 2007 excel iv examples.I was too thick headed and only recently found your iv paper in the references of Jaeckle's LBR paper.I am still trying to understand the approach you took in your 2007 iv work.Good stuff.Thanks,-Terry-PS. The pricer in your 2007 excel iv example was implemented from a different form of the equation than the pricers I had seen.It seems like the cancelation artifacts are occurring in a little different location.Maybe not.Perhaps a way to find a pricer that behaves better for vega ~0 is to find a form of the equation that forces the cancelation errors to occur in a different region.please forgive errors:usual N(d1) - N(d2)yours (1-N(-d1)) - (1-N(-d2))other1? (1-N(-d1)) - N(d2)other2? N(d1) - (1-N(-d2))other3? calc invC = 1/AnyAbove then C = 1/invC

Last edited by tthrift on December 27th, 2014, 11:00 pm, edited 1 time in total.

- Cuchulainn
**Posts:**59013**Joined:****Location:**Amsterdam-
**Contact:**

QuoteOriginally posted by: AVtJust some remarks (Spot = 100, Rates = 0, vol = 0.04% for data ?): It does not make much sense to "solve" for volatility if one does nothave a good pricer, which solver ever is used.One can use systems like Mathematica or Maple with high precision forextreme values (if done with care). But fixed precision will alwayshave problems in simply using the usual formula, no matter how goodthe cumulative Normal is implemented:One subtracts 2 terms and that introduces cancellation errors if theyare of same magnitude. That happens if Call ~ 0, i.e. strike very high.For example strike=140 gives terms of 0.23 E-14. And would result in afalse price (or even zero) in careless coding, since the first 2 placeswill cancel out - but the needed trailing 2 places can not be providedfor each single term.And though from Math there is an inversion price <---> vol that is nottrue as soon as one goes to (fixed precision) Numerics. One always canbreak that far OTM (I even have some doubts in numerical monotony here).For that take strike=70. The price of a call is discounted pay off +premium ~ 30 + 0.8 E-19 and that is 30.0 in double precision. Thus itis the price for vol=0: any vol up to 4% (and somewhat beyond) will do.Note that for these 2 examples one does not have to go for strikes beingmore extreme. And having computational costs in mind the answer is notby increasing digits and using Boost, MMA, Maple or fancy solvers.Functionally (having a good pricer) I would implement towards "vega ~ 0then task does not make sense" (though not longer working in that field).Besides that one will not get that price. From Numerics the thing is flawed and "ill-posed".So, what's a structural solution? Is the term "ill-posed" just a manner of speech or in this sense?My guess is that it is a problem in which the input data is contaminated by noise (?).

Last edited by Cuchulainn on December 28th, 2014, 11:00 pm, edited 1 time in total.

I thought the sketched would be enough ... [at extreme vol] 1) classical codesuffers from cancellation and 2) numerically an inverse is neither uniquenor discrete. Except you allow for arbitrary precision.1) For the example K=70 classical code would need 18 + 2 decimals to getcorrect results in 18 decimals = double precision, i.e. one needs doubleextended precision to get the result in the usual way (MS does not haveit, if cdfN is ever coded for that - it will boil down short below).2) For K=140 and price = 30 + 0.8 E-19 one would need 2 (for 30) + 19 (forthe zeros) + 18 (for the tail) ~ 40 decimals to express the price. Nobodywould feed such a price. Backing out IV is questionable, even if you havea pricer good enough for that.One should "read" Alan's test as a request for stress and stability(for both the algo and the implementation), likewise you can use40% and 3.5 days to expiry.

- Cuchulainn
**Posts:**59013**Joined:****Location:**Amsterdam-
**Contact:**

I have tested ITM calls and puts using my Differential Evolution (DE) solver. Compared with the incorrect errors we seem to be getting consistent results by cross checking, e.g.T = 1, r = b = 0, S = 100// Callsa) K = 6.30957, C = 93.6904, sig = 0.3409436b) K = 10, C = 90, sig = 0.070218// Putsc) K = 1584.89, P = 1484.89, sig = 0.29404d) K = 158.489, P = 58.489296, sig = 0.2420727My vols different significantly! Using them in BS gives the correct option price. But it is not 0.04!(?) Maybe DE is better at sniffing out infeasible regions and/or insensitive to noisy data?? Need to experiment a bit more.

Last edited by Cuchulainn on January 19th, 2015, 11:00 pm, edited 1 time in total.

Looks nice. I will try your x^16 objective in my codes next time I have a problem.

- Cuchulainn
**Posts:**59013**Joined:****Location:**Amsterdam-
**Contact:**

QuoteOriginally posted by: AlanIn my experience, the trickiest cases are those when the option value is in a legal range, and so aniv > 0 exists, but the price is extremely small. This happens frequently when the option price comes,not from the market, but from a model and you want to convert it to an iv.To take a simple example, suppose [$]S=100, \quad K =150, \quad T=1[$], and [$]\sigma = 0.04 = 4\%[$].The Black-Scholes call price [$]C \approx 9.01 \times 10^{-25}[$].Now, given that option price, try your iv routine. How did it do? Full disclosure: my 'robust iv routine' which I previously described, will also fail with this onebecause it is too simple and working at machine precision. However, with a little more work, you could writea `more robust iv routine' that will also work in this case, and using only machine precision.As another initial check, I ran this on my DE on the least squares formulation. I get sig == 0.039999 Letting K get bigger 120,130, 200 etc.... in double precision the machine precision is reached at ~ K = 135 (data falls off the radar). After that the solver gives incorrect results. Have not considered multiple precision. Maybe TT and Alan have some input. From all this I would tend to provisionally conclude that the DE is fine if we have enough machine bits. Apples and oranges.

Last edited by Cuchulainn on January 19th, 2015, 11:00 pm, edited 1 time in total.

Alan's test example can be done in double precision, with Excel, havinga good implementation. For data being more extreme there are other waysto compute prices (I sketched that at NuclearPhynance).http://axelvogt.de/axalom/BS&Vol_CodyMiller.xls.zipFor S=100, K=150, r=0, t=1, v=0.04 it gives call = 9.010020309E-25 andthe shiet finds vol = 0.039990446 giving a pricing error = 6.49E-26 for that.Of course one can push to situations where any code gives up. Hopefully.Anyway: the inversion price <-> volatility a) is flawed in Numerics inextreme situations and b) needs sound results on both ends to make sense.

- Cuchulainn
**Posts:**59013**Joined:****Location:**Amsterdam-
**Contact:**

For Differential Evolution (as mentioned I think) I get 0.04 exactly.

I tried bracketing (Golden Mean, Brent) that give 0.045005 and 0.040800, respectively, even with a krazee termination condition. As you say, the issue is more than just numerical.

Also tried C++ multiprecision but again it does not really help.

Note I solve a least squares minimisation problem rather than f(x) = 0. A more robust approach + less assumptions than Newton. Especially when vega ~ 0.

I don't get this. What is the deal with implied volatility? It's just a numerical root solver away. End of story, no?

Aren't all these approximations just a curiosity for unoccupied quants or am I missing something?

Aren't all these approximations just a curiosity for unoccupied quants or am I missing something?

This topic has been addressed many times in these forums, let me summarize what I perceive as the received wisdom. The very first thing to do when computing implied volatility is to check whether it is even defined. By that I mean that one needs to check that the option price observes certain boundary conditions, you can find those in Hull's text or the classic 1973 paper by Merton. It is sad how many people miss this very basic step and end up pulling their hair out over calculations where the ivol is undefined.

Assuming the observed option price conforms to the relevant boundary conditions, the next smart thing is to use an intelligent seed value to start whatever numerical algorithm you choose to use. The speed and accuracy of any search algorithm can be improved by using a good seed value. There's tons of literature out there on good seeds for faster ivol calculations, and they too have been discussed about many times on these forums. Corrado and Miller are two published authors who have contributed to this literature.

IMHO you will get much more bang for your buck looking after those two things than you will get with numerical technique overkill. It was so long ago but I seem to recall that I adapted the Brent method (from Numerical Recipes) with an intelligent seed and it typically solves in 2-3 iterations, usually 2. Never had a problem with it. Never. And if memory serves me correct the Brent method first attempts to use the Newton Raphson algorithm and if that goes wonky after an iteration or two it resorts to bisection.

Assuming the observed option price conforms to the relevant boundary conditions, the next smart thing is to use an intelligent seed value to start whatever numerical algorithm you choose to use. The speed and accuracy of any search algorithm can be improved by using a good seed value. There's tons of literature out there on good seeds for faster ivol calculations, and they too have been discussed about many times on these forums. Corrado and Miller are two published authors who have contributed to this literature.

IMHO you will get much more bang for your buck looking after those two things than you will get with numerical technique overkill. It was so long ago but I seem to recall that I adapted the Brent method (from Numerical Recipes) with an intelligent seed and it typically solves in 2-3 iterations, usually 2. Never had a problem with it. Never. And if memory serves me correct the Brent method first attempts to use the Newton Raphson algorithm and if that goes wonky after an iteration or two it resorts to bisection.

GZIP: On