quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] Regarding OpenMP and Open MPI library support

[Luigi B. <lui...@gm...>]

Yes, by looking at the git logs most of the pragmas were commented out in
commit ed061df111; the one in lattice.hpp was restored in ec35ebde89.
This was in 2014, so probably with ancient versions of both the compilers
and openmp.
Vamshi, if you want to have a look, it would be useful to have an opinion
from someone that actually knows openmp.

Luigi


On Thu, Jan 6, 2022 at 9:25 PM Peter Caspers <pca...@gm...> wrote:

> Hi,
>
> in the past we saw that a "blind" usage of open mp does more harm than
> good, see
>
> https://sourceforge.net/p/quantlib/mailman/message/32461242/
>
> so we removed most of the pragmas. It seems that the omp pragma
> survived in lattice.hpp contrary to what is said in the mail thread, I
> don't remember if there is a good reason for that. Maybe something to
> review at some point. There are two more places, zabrsmilesection.hpp
> and gaussian1dswaptionengine.cpp where I think enabling openmp gives
> _some_ speedup although it's far from what you would hope for if I
> remember correctly.
>
> grep --include="*.?pp"  -nH --null -r -e "pragma omp" *
> ql/experimental/volatility/zabrsmilesection.hpp209:#pragma omp parallel for
> ql/methods/lattices/lattice.hpp169:        #pragma omp parallel for
> ql/methods/finitedifferences/operators/triplebandlinearop.cpp127:
>           //#pragma omp parallel for
> ql/methods/finitedifferences/operators/triplebandlinearop.cpp137:
>           //#pragma omp parallel for
> ql/methods/finitedifferences/operators/triplebandlinearop.cpp153:
>       //#pragma omp parallel for
> ql/methods/finitedifferences/operators/triplebandlinearop.cpp172:
>       //#pragma omp parallel for
> ql/methods/finitedifferences/operators/triplebandlinearop.cpp187:
>   //#pragma omp parallel for
> ql/methods/finitedifferences/operators/triplebandlinearop.cpp203:
>   //#pragma omp parallel for
> ql/methods/finitedifferences/operators/triplebandlinearop.cpp220:
>   #pragma omp parallel for
> ql/methods/finitedifferences/operators/triplebandlinearop.cpp238:
>   //#pragma omp parallel for
> ql/methods/finitedifferences/operators/triplebandlinearop.cpp260:
>   //#pragma omp parallel for
> ql/methods/finitedifferences/operators/ninepointlinearop.cpp147:
>  //#pragma omp parallel for
> ql/methods/finitedifferences/operators/ninepointlinearop.cpp191:
>  //#pragma omp parallel for
> ql/methods/finitedifferences/parallelevolver.hpp51:
> //#pragma omp parallel for
> ql/methods/finitedifferences/parallelevolver.hpp102:
> //#pragma omp parallel for
> ql/methods/finitedifferences/stepcondition.hpp48:            //#pragma
> omp parallel for
> ql/pricingengines/swaption/gaussian1dswaptionengine.cpp118:#pragma omp
> parallel for default(shared) firstprivate(p) if(expiry0>settlement)
>
> Thanks
> Peter
>
> On Thu, 6 Jan 2022 at 13:18, Jonathan Sweemer <sw...@gm...> wrote:
> >
> > Hi Vamshi,
> >
> > OpenMP is only wired into a few places in QuantLib so if your program
> doesn't use those specific code paths then you probably won't see much
> difference in terms of speed.
> >
> > Moreover, QuantLib is not thread safe in general, and wasn't
> specifically designed for thread-level parallelism. See Luigi's answer on
> Stack Overflow for more details: https://stackoverflow.com/a/47098133
> >
> > The good news is that you can use multiprocessing instead of
> multithreading with your HPC cluster to parallelize your jobs across cores
> and nodes.
> >
> >
> > On Thu, Jan 6, 2022 at 12:28 PM Vamshi Krishna <kri...@gm...>
> wrote:
> >>
> >> Hiii Users
> >>
> >> I am new in this group and new to quantlib. I come for HPC back ground.
> >>
> >> I have tried some examples program with openMP but no major performance
> gained.
> >>
> >> When I tried FinanceBench program which which have openMP functions and
> shown good performance on multi cores.
> >>
> >> I do not, I am do correctly or not.
> >>
> >> If any user could help me "how to use quantlib on multi cores and
> multiple node hpc cluster,  I will be thankful.
> >>
> >> Regards
> >> Vamshi Krishna
> >> _______________________________________________
> >> QuantLib-users mailing list
> >> Qua...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >
> > _______________________________________________
> > QuantLib-users mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Regarding OpenMP and Open MPI library support

[Peter C. <pca...@gm...>]

Hi,

in the past we saw that a "blind" usage of open mp does more harm than good, see

https://sourceforge.net/p/quantlib/mailman/message/32461242/

so we removed most of the pragmas. It seems that the omp pragma
survived in lattice.hpp contrary to what is said in the mail thread, I
don't remember if there is a good reason for that. Maybe something to
review at some point. There are two more places, zabrsmilesection.hpp
and gaussian1dswaptionengine.cpp where I think enabling openmp gives
_some_ speedup although it's far from what you would hope for if I
remember correctly.

grep --include="*.?pp"  -nH --null -r -e "pragma omp" *
ql/experimental/volatility/zabrsmilesection.hpp209:#pragma omp parallel for
ql/methods/lattices/lattice.hpp169:        #pragma omp parallel for
ql/methods/finitedifferences/operators/triplebandlinearop.cpp127:
          //#pragma omp parallel for
ql/methods/finitedifferences/operators/triplebandlinearop.cpp137:
          //#pragma omp parallel for
ql/methods/finitedifferences/operators/triplebandlinearop.cpp153:
      //#pragma omp parallel for
ql/methods/finitedifferences/operators/triplebandlinearop.cpp172:
      //#pragma omp parallel for
ql/methods/finitedifferences/operators/triplebandlinearop.cpp187:
  //#pragma omp parallel for
ql/methods/finitedifferences/operators/triplebandlinearop.cpp203:
  //#pragma omp parallel for
ql/methods/finitedifferences/operators/triplebandlinearop.cpp220:
  #pragma omp parallel for
ql/methods/finitedifferences/operators/triplebandlinearop.cpp238:
  //#pragma omp parallel for
ql/methods/finitedifferences/operators/triplebandlinearop.cpp260:
  //#pragma omp parallel for
ql/methods/finitedifferences/operators/ninepointlinearop.cpp147:
 //#pragma omp parallel for
ql/methods/finitedifferences/operators/ninepointlinearop.cpp191:
 //#pragma omp parallel for
ql/methods/finitedifferences/parallelevolver.hpp51:
//#pragma omp parallel for
ql/methods/finitedifferences/parallelevolver.hpp102:
//#pragma omp parallel for
ql/methods/finitedifferences/stepcondition.hpp48:            //#pragma
omp parallel for
ql/pricingengines/swaption/gaussian1dswaptionengine.cpp118:#pragma omp
parallel for default(shared) firstprivate(p) if(expiry0>settlement)

Thanks
Peter

On Thu, 6 Jan 2022 at 13:18, Jonathan Sweemer <sw...@gm...> wrote:
>
> Hi Vamshi,
>
> OpenMP is only wired into a few places in QuantLib so if your program doesn't use those specific code paths then you probably won't see much difference in terms of speed.
>
> Moreover, QuantLib is not thread safe in general, and wasn't specifically designed for thread-level parallelism. See Luigi's answer on Stack Overflow for more details: https://stackoverflow.com/a/47098133
>
> The good news is that you can use multiprocessing instead of multithreading with your HPC cluster to parallelize your jobs across cores and nodes.
>
>
> On Thu, Jan 6, 2022 at 12:28 PM Vamshi Krishna <kri...@gm...> wrote:
>>
>> Hiii Users
>>
>> I am new in this group and new to quantlib. I come for HPC back ground.
>>
>> I have tried some examples program with openMP but no major performance gained.
>>
>> When I tried FinanceBench program which which have openMP functions and shown good performance on multi cores.
>>
>> I do not, I am do correctly or not.
>>
>> If any user could help me "how to use quantlib on multi cores and multiple node hpc cluster,  I will be thankful.
>>
>> Regards
>> Vamshi Krishna
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Regarding OpenMP and Open MPI library support

[Jonathan S. <sw...@gm...>]

Hi Vamshi,

OpenMP is only wired into a few places in QuantLib so if your program
doesn't use those specific code paths then you probably won't see much
difference in terms of speed.

Moreover, QuantLib is not thread safe in general, and wasn't specifically
designed for thread-level parallelism. See Luigi's answer on Stack Overflow
for more details: https://stackoverflow.com/a/47098133

The good news is that you can use multiprocessing instead of multithreading
with your HPC cluster to parallelize your jobs across cores and nodes.


On Thu, Jan 6, 2022 at 12:28 PM Vamshi Krishna <kri...@gm...> wrote:

> Hiii Users
>
> I am new in this group and new to quantlib. I come for HPC back ground.
>
> I have tried some examples program with openMP but no major performance
> gained.
>
> When I tried FinanceBench program which which have openMP functions and
> shown good performance on multi cores.
>
> I do not, I am do correctly or not.
>
> If any user could help me "how to use quantlib on multi cores and multiple
> node hpc cluster,  I will be thankful.
>
> Regards
> Vamshi Krishna
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Regarding OpenMP and Open MPI library support

[Vamshi K. <kri...@gm...>]

Hiii Users

I am new in this group and new to quantlib. I come for HPC back ground.

I have tried some examples program with openMP but no major performance
gained.

When I tried FinanceBench program which which have openMP functions and
shown good performance on multi cores.

I do not, I am do correctly or not.

If any user could help me "how to use quantlib on multi cores and multiple
node hpc cluster,  I will be thankful.

Regards
Vamshi Krishna

Re: [Quantlib-users] Model for pricing Asian options

[Peter C. <pca...@gm...>]

Yes you can set up a commodity volatility surface that accepts call /
put prices as an input and implies volatilities from them. You can
then use that volatility surface to price an APO. Notice that it's not
the engine that converts a call / put price to a volatility, this is
done separately in the vol term structure instance that is passed to
the engine.
Best, Peter


On Tue, 4 Jan 2022 at 19:26, Ashish Bansal <ash...@gm...> wrote:
>
> Thanks Luigi and Peter.
>
> Peter,
> We are using QL through python. I hope the above engine is supported through the OREdata-SWIG. Let me try it out.
>
> Does this engine provide the Implied Vol for APO trades when passing the exchange price? The Asian engine in QL doesn't.
>
> Thanks
> Ashish
>
> On Mon, 3 Jan 2022 at 20:30, Peter Caspers <pca...@gm...> wrote:
>>
>> Hey Ashish,
>>
>> in addition to what Luigi said, this might be of interest to you:
>>
>> https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/pricingengines/commodityapoengine.hpp
>>
>> Thanks
>> Peter
>>
>> On Mon, 3 Jan 2022 at 15:17, Luigi Ballabio <lui...@gm...> wrote:
>> >
>> > Not that I know of.
>> >
>> > On Wed, Dec 29, 2021 at 2:08 PM Ashish Bansal <ash...@gm...> wrote:
>> >>
>> >> Do you know if Asian option engines have moment matching inbuilt?
>> >>
>> >> On Tue, 28 Dec 2021 at 21:03, Luigi Ballabio <lui...@gm...> wrote:
>> >>>
>> >>> Hello Ashish, no, it's not.
>> >>>
>> >>> Luigi
>> >>>
>> >>>
>> >>> On Thu, Dec 2, 2021 at 11:35 AM Ashish Bansal <ash...@gm...> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> Is the turnbull-wakeman model supported in QL for pricing the asian options? I wish to price the commodity asian options.
>> >>>>
>> >>>> Regards,
>> >>>> Ashish
>> >>>> _______________________________________________
>> >>>> QuantLib-users mailing list
>> >>>> Qua...@li...
>> >>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>> >
>> > _______________________________________________
>> > QuantLib-users mailing list
>> > Qua...@li...
>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Model for pricing Asian options

[Ashish B. <ash...@gm...>]

Thanks Luigi and Peter.

Peter,
We are using QL through python. I hope the above engine is supported
through the OREdata-SWIG. Let me try it out.

Does this engine provide the Implied Vol for APO trades when passing the
exchange price? The Asian engine in QL doesn't.

Thanks
Ashish

On Mon, 3 Jan 2022 at 20:30, Peter Caspers <pca...@gm...> wrote:

> Hey Ashish,
>
> in addition to what Luigi said, this might be of interest to you:
>
>
> https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/pricingengines/commodityapoengine.hpp
>
> Thanks
> Peter
>
> On Mon, 3 Jan 2022 at 15:17, Luigi Ballabio <lui...@gm...>
> wrote:
> >
> > Not that I know of.
> >
> > On Wed, Dec 29, 2021 at 2:08 PM Ashish Bansal <ash...@gm...>
> wrote:
> >>
> >> Do you know if Asian option engines have moment matching inbuilt?
> >>
> >> On Tue, 28 Dec 2021 at 21:03, Luigi Ballabio <lui...@gm...>
> wrote:
> >>>
> >>> Hello Ashish, no, it's not.
> >>>
> >>> Luigi
> >>>
> >>>
> >>> On Thu, Dec 2, 2021 at 11:35 AM Ashish Bansal <ash...@gm...>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> Is the turnbull-wakeman model supported in QL for pricing the asian
> options? I wish to price the commodity asian options.
> >>>>
> >>>> Regards,
> >>>> Ashish
> >>>> _______________________________________________
> >>>> QuantLib-users mailing list
> >>>> Qua...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >
> > _______________________________________________
> > QuantLib-users mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Model for pricing Asian options

[Peter C. <pca...@gm...>]

Hey Ashish,

in addition to what Luigi said, this might be of interest to you:

https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/pricingengines/commodityapoengine.hpp

Thanks
Peter

On Mon, 3 Jan 2022 at 15:17, Luigi Ballabio <lui...@gm...> wrote:
>
> Not that I know of.
>
> On Wed, Dec 29, 2021 at 2:08 PM Ashish Bansal <ash...@gm...> wrote:
>>
>> Do you know if Asian option engines have moment matching inbuilt?
>>
>> On Tue, 28 Dec 2021 at 21:03, Luigi Ballabio <lui...@gm...> wrote:
>>>
>>> Hello Ashish, no, it's not.
>>>
>>> Luigi
>>>
>>>
>>> On Thu, Dec 2, 2021 at 11:35 AM Ashish Bansal <ash...@gm...> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Is the turnbull-wakeman model supported in QL for pricing the asian options? I wish to price the commodity asian options.
>>>>
>>>> Regards,
>>>> Ashish
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Model for pricing Asian options

[Luigi B. <lui...@gm...>]

Not that I know of.

On Wed, Dec 29, 2021 at 2:08 PM Ashish Bansal <ash...@gm...>
wrote:

> Do you know if Asian option engines have moment matching inbuilt?
>
> On Tue, 28 Dec 2021 at 21:03, Luigi Ballabio <lui...@gm...>
> wrote:
>
>> Hello Ashish, no, it's not.
>>
>> Luigi
>>
>>
>> On Thu, Dec 2, 2021 at 11:35 AM Ashish Bansal <ash...@gm...>
>> wrote:
>>
>>> Hi,
>>>
>>> Is the turnbull-wakeman model supported in QL for pricing the asian
>>> options? I wish to price the commodity asian options.
>>>
>>> Regards,
>>> Ashish
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>

Re: [Quantlib-users] Model for pricing Asian options

[Ashish B. <ash...@gm...>]

Do you know if Asian option engines have moment matching inbuilt?

On Tue, 28 Dec 2021 at 21:03, Luigi Ballabio <lui...@gm...>
wrote:

> Hello Ashish, no, it's not.
>
> Luigi
>
>
> On Thu, Dec 2, 2021 at 11:35 AM Ashish Bansal <ash...@gm...>
> wrote:
>
>> Hi,
>>
>> Is the turnbull-wakeman model supported in QL for pricing the asian
>> options? I wish to price the commodity asian options.
>>
>> Regards,
>> Ashish
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] Is a gamma pricing model available?

[Luigi B. <lui...@gm...>]

Hi,
    I'm not very familiar with those engines, but from the interface I'd
say that the variance gamma process can be only used
with AnalyticVarianceGammaEngine and FFTVarianceGammaEngine
(FFTVanillaEngine uses Black/Scholes, and FFTEngine is the base class of
the other two FFT engines).  From what I can see, the analytic engine
performs a numerical integration to calculate the expected option value
(the "integral approach" mentioned in the docs) while the FFT engines
implement the quoted paper.  Not sure about the pros and cons.

Hope this helps,
    Luigi


On Wed, Dec 1, 2021 at 3:36 AM Peng Yu <pen...@gm...> wrote:

>
> https://github.com/lballabio/QuantLib/tree/f47242c966d191e1b542162b1f2d726615bdba89/ql/experimental/variancegamma
>
> Are you talking about the above?
>
> I see there are 4 engines.
>
> - analyticvariancegammaengine
> - fftengine
> - fftvanillaengine
> - fftvariancegammaengine
>
> I see the following doc.
>
> analyticvariancegammaengine:
>     //! Variance Gamma Pricing engine for European vanilla options
> using integral approach
>
> What is integral approach? Is there a doc explaining what it is?
>
> fftengine:
>
>         The FFT engine calculates the values of all options with the
> same expiry at the same time.
>         For that reason it is very inefficient to price options
> individually.  When using this engine
>         you should collect all the options you wish to price in a list and
> call
>         the engine's precalculate method before calling the NPV method
> of the option.
>         References:
>         Carr, P. and D. B. Madan (1998),
>         "Option Valuation using the fast Fourier transform,"
>         Journal of Computational Finance, 2, 61-73.
>
> fftvanillaengine
>     //! FFT Pricing engine vanilla options under a Black Scholes process
>     /*! \ingroup vanillaengines
>         \test the correctness of the returned values is tested by
>         comparison with Black Scholes pricing.
>
> fftvariancegammaengine
>     //! FFT engine for vanilla options under a Variance Gamma process
>     /*! \ingroup vanillaengines
>         \test the correctness of the returned values is tested by
>         comparison with known good values and the analytic approach
>
> But it is confusing to me about whether all four can be used with
> ql.VarianceGammaProcess, or only analyticvariancegammaengine and
> fftvariancegammaengine can be used with ql.VarianceGammaProcess.
>
> I don't see these engines documented in python. Is the doc incomplete?
> Could you explain the difference between them, what is the pros and
> cons of each engine, and when to use which engine?
>
>
> https://quantlib-python-docs.readthedocs.io/en/latest/search.html?q=fftengine&check_keywords=yes&area=default#
>
> Could you show an example of how to use ql.VarianceGammaProcess in python?
>
> On 11/30/21, Luigi Ballabio <lui...@gm...> wrote:
> > Hi,
> >     there's a couple of engines supporting the VarianceGammaProcess (you
> > can find them in ql/experimenta/variancegamma) but they only support
> > European options.  The two papers you quoted are not implemented.
> >
> > Luigi
> >
> >
> > On Tue, Nov 30, 2021 at 4:03 PM Peng Yu <pen...@gm...> wrote:
> >
> >> I see the following two methods in this direction.
> >>
> >> Pricing American Options Under Variance Gamma
> >> https://www.math.columbia.edu/~smirnov/Alihirsa.pdf
> >>
> >> A fast method for pricing American options under the variance gamma
> model
> >> http://arxiv-export-lb.library.cornell.edu/abs/1903.07519v1
> >>
> >> I also notice there is VarianceGammaProcess in quantlib. Does
> >> VarianceGammaProcess implement any of these two methods? Or it is
> >> something totally different?
> >>
> >> I want to model American options. I tried the following code (full
> >> code attached).
> >>
> >> american_option.setPricingEngine(
> >> ql.BinomialVanillaEngine(
> >> process = ql.VarianceGammaProcess(
> >> ql.QuoteHandle(
> >> ql.SimpleQuote(spot_price)
> >> )
> >> , ql.YieldTermStructureHandle(
> >> ql.FlatForward(calculation_date, dividend_rate, day_count)
> >> )
> >> , ql.YieldTermStructureHandle(
> >> ql.FlatForward(calculation_date, risk_free_rate, day_count)
> >> )
> >> , sigma = 0.2
> >> , nu = 1
> >> , theta = 1
> >> )
> >> , type = 'crr'
> >> , steps = 200)
> >> )
> >>
> >> But I got the following error. I am not sure what the meaning of the
> >> error is. Does it mean BinomialVanillaEngine is not compatible with
> >> VarianceGammaProcess? Could anybody show me the correct way to price
> >> American options using variance Gamma processes?
> >>
> >> Traceback (most recent call last):
> >>   File "./main.py", line 26, in <module>
> >>     ql.BinomialVanillaEngine(
> >>   File
> >>
> "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/QuantLib/QuantLib.py",
> >> line 12456, in BinomialVanillaEngine
> >>     return cls(process, steps)
> >>   File
> >>
> "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/QuantLib/QuantLib.py",
> >> line 12365, in __init__
> >>     _QuantLib.BinomialCRRVanillaEngine_swiginit(self,
> >> _QuantLib.new_BinomialCRRVanillaEngine(arg2, steps))
> >> TypeError: in method 'new_BinomialCRRVanillaEngine', argument 1 of
> >> type 'ext::shared_ptr< GeneralizedBlackScholesProcess > const &'
> >>
> >> > I see a gamma pricing model is mentioned below. But I don't see any
> >> > formula in the page. Does anybody where I can find a more detailed
> >> > description of the gamma pricing model?
> >> >
> >> > Does quantlib have an implementation of a gamma pricing model? (I
> >> > don't find it. But I may miss it.)
> >> >
> >> > https://www.investopedia.com/terms/g/gamma-pricing-model.asp
> >>
> >> --
> >> Regards,
> >> Peng
> >> _______________________________________________
> >> QuantLib-users mailing list
> >> Qua...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >>
> >
>
>
> --
> Regards,
> Peng
>

Re: [Quantlib-users] Model for pricing Asian options

[Luigi B. <lui...@gm...>]

Hello Ashish, no, it's not.

Luigi


On Thu, Dec 2, 2021 at 11:35 AM Ashish Bansal <ash...@gm...>
wrote:

> Hi,
>
> Is the turnbull-wakeman model supported in QL for pricing the asian
> options? I wish to price the commodity asian options.
>
> Regards,
> Ashish
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] XCCY ASW's

[Luigi B. <lui...@gm...>]

Hello Ben, it's not updated yet.  Would you mind opening an issue on
GitHub?  Thanks!

Luigi


On Thu, Dec 23, 2021 at 9:17 AM Ben Watson <ben...@ma...>
wrote:

> I am pricing some xccy asset swaps. The asset swap function takes an IBOR
> index, Has this been updated to take a RFR index or is that supported
> already?
>
> Regards
>
> Ben
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] XCCY ASW's

[Ben W. <ben...@ma...>]

I am pricing some xccy asset swaps. The asset swap function takes an IBOR index, Has this been updated to take a RFR index or is that supported already?

Regards

Ben

[Quantlib-users] QuantLibXL Prerelease 1.23

[SX L <han...@ho...>]

Hi, I am looking at the prerelease. In QuantLibAddin/qlo/enumerations/factories/termstructuresfactory.hpp, we have the typedef as below:
    typedef boost::shared_ptr<QuantLib::YieldTermStructure>(*YieldTermStructureConstructor)(
            QuantLib::Natural nDays,
            const QuantLib::Calendar& calendar,
            const std::vector<boost::shared_ptr<QuantLib::RateHelper> >& rh,
            const QuantLib::DayCounter& dayCounter,
            const std::vector<QuantLib::Handle<QuantLib::Quote> >& jumps,
            const std::vector<QuantLib::Date>& jumpDates,
            const QuantLib::MixedInterpolation::Behavior behavior,
            const QuantLib::Size n);
However, for most of the constructors in QuantLibAddin/qlo/enumerations/constructors/enumeratedpairs.hpp (examples below), the last two parameters are missing. Are we going to get undefined behavior, or the two extra parameters will be ignored for sure?
    boost::shared_ptr<QuantLib::YieldTermStructure> ZEROYIELD_LOGLINEAR_PiecewiseYieldCurve(
            QuantLib::Natural nDays,
            const QuantLib::Calendar& calendar,
            const std::vector<boost::shared_ptr<QuantLib::RateHelper> >& rateHelpers,
            const QuantLib::DayCounter& dayCounter,
            const std::vector<QuantLib::Handle<QuantLib::Quote> >& jumps,
            const std::vector<QuantLib::Date>& jumpDates);

Re: [Quantlib-users] Is Implied volatility method available for Asian option class

[Matthew K. <mat...@gm...>]

This is an interesting question and thank you for bringing it up. One
reason I think an impliedVolatility function is omitted from AsianOption
instruments is that there isn't a canonical definition for what implied
volatility means to an Asian option. Sure, there's always a definition of
IV for Black-Scholes type models where you can solve for the volatility
parameter, but if you notice in the VanillaOption class, impliedVolatility
is hard coded as the solution to an AnalyticEuropeanEngine if the
instrument has European exercise and FdBlackScholesVanillaEngine otherwise.
QL actually ties the definition of IV to an instrument, giving no used
control over what engine generates it. So, I would vote we never add an
impliedVolatility function to Asian options, because there isn't a
broadly-accepted definition of what engine should be used to define IV for
Asian options.

That said, if you want to just have some code in your local repo that
replicates the VanillaOption behavior, add this to the
DiscreteAveragingAsianOption header class:

Volatility impliedVolatility(Real price,
                                     const
ext::shared_ptr<GeneralizedBlackScholesProcess>& process,
                                     Real accuracy = 1.0e-4,
                                     Size maxEvaluations = 100,
                                     Volatility minVol = 1.0e-7,
                                     Volatility maxVol = 4.0) const;

And add this to the DiscreteAveragingAsianOption cpp file:

    Volatility DiscreteAveragingAsianOption::impliedVolatility(
        Real targetValue,
        const ext::shared_ptr<GeneralizedBlackScholesProcess>& process,
        Real accuracy,
        Size maxEvaluations,
        Volatility minVol,
        Volatility maxVol) const
                                     {
        QL_REQUIRE(!isExpired(), "option expired");

        ext::shared_ptr<SimpleQuote> volQuote(new SimpleQuote);

        ext::shared_ptr<GeneralizedBlackScholesProcess> newProcess =
            detail::ImpliedVolatilityHelper::clone(process, volQuote);

        std::unique_ptr<PricingEngine> engine;
        engine.reset(new
AnalyticDiscreteGeometricAveragePriceAsianEngine(newProcess));

        return detail::ImpliedVolatilityHelper::calculate(*this, *engine,
*volQuote, targetValue,
                                                          accuracy,
maxEvaluations, minVol, maxVol);
    }

You'll need to resolve some new dependencies in those files and recompile,
but that's it. Also note that I defaulted to using the
AnalyticDiscreteGeometricAveragePriceAsianEngine engine, but you can use
whatever you want there.

On Tue, Dec 7, 2021 at 6:03 AM Ashish Bansal <ash...@gm...>
wrote:

> Hi,
>
> I am trying to evaluate the Arithmetic averaging Asian option using QL
> class called DiscreteAveragingAsianOption. However, there is no method
> under it to calculate the implied volatility, which is present for plain
> vanilla and barrier options.
>
> Please help how can I calculate IV for Asian options.
>
> Regards,
> Ashish
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>


-- 
Matthew P. Kolbe
(312) 218-6595
mat...@gm...

Re: [Quantlib-users] Fast way to obtain discount factors on an array of dates?

[Luigi B. <lui...@gm...>]

Hi Jian,
    no, there's no vector call — sorry.

Luigi


On Mon, Dec 6, 2021 at 9:09 PM jian Xu <jia...@gm...> wrote:

> Hi,
>
> YieldTermStructure has a function discount() to return the discount
> factor on a single date.  But is there a function to return an array
> of discount factors on an array of dates?
>
> Currently, I'm looping in python
>
> disc = np.array([disc_curve.discount(d) for d in dates])
>
> But the python loops are pretty slow.  Just wondering if there's any
> faster way to do this.  Thanks a lot!
>
> Jian
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] RFR option matters

[Peter C. <pca...@gm...>]

In our code the vol type "normal / lognormal" and shift size for
lognormal vols will depend on the vol term structure you feed into the
coupon pricer. I think it's fine to combine the linear vol decay
formula with any vol type / shift, even if the inspiration for that
formula comes from Ho-Lee.

In actual calculations we always use normal vols. Glad to hear that
this is in line with BBG and backed up by Mr Mercurio, what more can
you wish for? :-)

On Wed, 8 Dec 2021 at 19:55, R M <rm...@gm...> wrote:
>
> I spoke with Mercurio today. Bloomberg are implementing adjustments based on a linear vol decay of normal rates. This is probably what we will go for as well, at least for automated things.
>
> Get Outlook for iOS
> ________________________________
> From: Ryan McCrickerd <rmc...@ch...>
> Sent: Tuesday, December 7, 2021 8:24:32 PM
> To: Peter Caspers <pca...@gm...>
> Cc: QuantLib users <qua...@li...>
> Subject: Re: [Quantlib-users] RFR option matters
>
> That’s great, thanks.
>
> One thing I am a little confused by is that in section 6.3 of Lyashenko & Mercurio (cited in your code) they specify a log normal / black rate, which is not actually consistent with a piecewise linear vol decay. This decay is derived in appendix A instead from a Gaussian short rate model, which produces shifted log normal dynamics for forward/backward rates. But the shift is so large that these are practically Gaussian, like the short rate.
>
> So do you plan on using BlackOvernightIndexedCouponPricer with a (very) shifted rate, or would it make more sense to define a NormalOvernightIndexedCouponPricer?
>
> Regards,
> Ryan
>
> Get Outlook for iOS
> ________________________________
> From: Peter Caspers <pca...@gm...>
> Sent: Tuesday, December 7, 2021 8:40:21 AM
> To: R M <rm...@gm...>
> Cc: QuantLib users <qua...@li...>
> Subject: Re: [Quantlib-users] RFR option matters
>
> Hi Ryan,
>
> we started with this
>
> https://urldefense.com/v3/__https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/cashflows/blackovernightindexedcouponpricer.cpp*L43__;Iw!!EbLleU--iSTUgtNy!-cgw--C4C8zcw1uAbQpSSeqg_yWQ-D4JcDLjU7lLG7-2ngiczr2x0EDsQq-eJJLip4D9--BJ$ [github[.]com]
>
> However I am sure this will require amendments going forward as a
> "market formula" for RFR Caps evolves.
>
> Thanks
> Peter
>
> On Mon, 22 Nov 2021 at 15:47, R M <rm...@gm...> wrote:
> >
> > Hello QuantLib users,
> >
> > My employer is going through the rigmarole of sourcing RFR option data (e.g. SONIA cap/floor/swaption premiums/vols).
> >
> > It always amazes me that when you ask a data provider for details on the instrument to which a data point corresponds, you don't get a response like "yes, that information is clearly fundamental, here you go". It's more like "everyone knows". But recently we had one provider tell us that their RFR cap/floor data relates to cap/floors that include the first period, and another told us that theirs don't. It also transpired that one provider was using middle-of-period time-to-maturities for mapping cap/floor premiums to vols, which just seems barbaric to me. (I guess this is to blame for that.)
> >
> > I don't think QL has started implementing vol surface construction from RFR option data (?), for which these issues are... fundamental. But have discussions on this begun? If not, happy to open a GitHub issue and continue this there.
> >
> > Regards,
> > Ryan
> > _______________________________________________
> > QuantLib-users mailing list
> > Qua...@li...
> > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/quantlib-users__;!!EbLleU--iSTUgtNy!-cgw--C4C8zcw1uAbQpSSeqg_yWQ-D4JcDLjU7lLG7-2ngiczr2x0EDsQq-eJJLip7Mdv2tq$ [lists[.]sourceforge[.]net]
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/quantlib-users__;!!EbLleU--iSTUgtNy!-cgw--C4C8zcw1uAbQpSSeqg_yWQ-D4JcDLjU7lLG7-2ngiczr2x0EDsQq-eJJLip7Mdv2tq$ [lists[.]sourceforge[.]net]
>
> Disclaimer
>
> Chatham Financial Europe, Ltd is authorised and regulated by the Financial Conduct Authority of the United Kingdom with reference number 197251.
>
> The privacy and security of your personal data is important to us. Your details may be stored in our client and contacts database for the purpose of sending you business communications, updates, newsletters, event invitations and other information which we think is relevant to you. If you would like further information about the types of personal data we hold about you, our legal grounds for doing so, how we collect and protect your personal data and your rights in relation to such data, please see Chatham's Privacy Policy.
>
> The information contained in this e-mail is confidential and is only for the use of the intended recipient. If you are not the intended recipient, any further copying, use, distribution or disclosure of the contents of this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently expunge the original e-mail, and any electronic copies, from your system and destroy any hard copy versions of the e-mail. Where the content of this e-mail is personal or otherwise unconnected with our or our clients' business, we accept no responsibility or liability for such content. Telephone calls may be monitored and/or recorded.

Re: [Quantlib-users] RFR option matters

[R M <rm...@gm...>]

I spoke with Mercurio today. Bloomberg are implementing adjustments based on a linear vol decay of normal rates. This is probably what we will go for as well, at least for automated things.

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Ryan McCrickerd <rmc...@ch...>
Sent: Tuesday, December 7, 2021 8:24:32 PM
To: Peter Caspers <pca...@gm...>
Cc: QuantLib users <qua...@li...>
Subject: Re: [Quantlib-users] RFR option matters

That’s great, thanks.

One thing I am a little confused by is that in section 6.3 of Lyashenko & Mercurio (cited in your code) they specify a log normal / black rate, which is not actually consistent with a piecewise linear vol decay. This decay is derived in appendix A instead from a Gaussian short rate model, which produces shifted log normal dynamics for forward/backward rates. But the shift is so large that these are practically Gaussian, like the short rate.

So do you plan on using BlackOvernightIndexedCouponPricer with a (very) shifted rate, or would it make more sense to define a NormalOvernightIndexedCouponPricer?

Regards,
Ryan

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Peter Caspers <pca...@gm...>
Sent: Tuesday, December 7, 2021 8:40:21 AM
To: R M <rm...@gm...>
Cc: QuantLib users <qua...@li...>
Subject: Re: [Quantlib-users] RFR option matters

Hi Ryan,

we started with this

https://urldefense.com/v3/__https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/cashflows/blackovernightindexedcouponpricer.cpp*L43__;Iw!!EbLleU--iSTUgtNy!-cgw--C4C8zcw1uAbQpSSeqg_yWQ-D4JcDLjU7lLG7-2ngiczr2x0EDsQq-eJJLip4D9--BJ$ [github[.]com]

However I am sure this will require amendments going forward as a
"market formula" for RFR Caps evolves.

Thanks
Peter

On Mon, 22 Nov 2021 at 15:47, R M <rm...@gm...> wrote:
>
> Hello QuantLib users,
>
> My employer is going through the rigmarole of sourcing RFR option data (e.g. SONIA cap/floor/swaption premiums/vols).
>
> It always amazes me that when you ask a data provider for details on the instrument to which a data point corresponds, you don't get a response like "yes, that information is clearly fundamental, here you go". It's more like "everyone knows". But recently we had one provider tell us that their RFR cap/floor data relates to cap/floors that include the first period, and another told us that theirs don't. It also transpired that one provider was using middle-of-period time-to-maturities for mapping cap/floor premiums to vols, which just seems barbaric to me. (I guess this is to blame for that.)
>
> I don't think QL has started implementing vol surface construction from RFR option data (?), for which these issues are... fundamental. But have discussions on this begun? If not, happy to open a GitHub issue and continue this there.
>
> Regards,
> Ryan
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/quantlib-users__;!!EbLleU--iSTUgtNy!-cgw--C4C8zcw1uAbQpSSeqg_yWQ-D4JcDLjU7lLG7-2ngiczr2x0EDsQq-eJJLip7Mdv2tq$ [lists[.]sourceforge[.]net]


_______________________________________________
QuantLib-users mailing list
Qua...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/quantlib-users__;!!EbLleU--iSTUgtNy!-cgw--C4C8zcw1uAbQpSSeqg_yWQ-D4JcDLjU7lLG7-2ngiczr2x0EDsQq-eJJLip7Mdv2tq$ [lists[.]sourceforge[.]net]

Disclaimer

Chatham Financial Europe, Ltd is authorised and regulated by the Financial Conduct Authority of the United Kingdom with reference number 197251.

The privacy and security of your personal data is important to us. Your details may be stored in our client and contacts database for the purpose of sending you business communications, updates, newsletters, event invitations and other information which we think is relevant to you. If you would like further information about the types of personal data we hold about you, our legal grounds for doing so, how we collect and protect your personal data and your rights in relation to such data, please see Chatham's Privacy Policy<https://www.chathamfinancial.com/privacy-policy>.

The information contained in this e-mail is confidential and is only for the use of the intended recipient. If you are not the intended recipient, any further copying, use, distribution or disclosure of the contents of this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently expunge the original e-mail, and any electronic copies, from your system and destroy any hard copy versions of the e-mail. Where the content of this e-mail is personal or otherwise unconnected with our or our clients' business, we accept no responsibility or liability for such content. Telephone calls may be monitored and/or recorded.

Re: [Quantlib-users] RFR option matters

[Ryan M. <rmc...@ch...>]

That’s great, thanks.

One thing I am a little confused by is that in section 6.3 of Lyashenko & Mercurio (cited in your code) they specify a log normal / black rate, which is not actually consistent with a piecewise linear vol decay. This decay is derived in appendix A instead from a Gaussian short rate model, which produces shifted log normal dynamics for forward/backward rates. But the shift is so large that these are practically Gaussian, like the short rate.

So do you plan on using BlackOvernightIndexedCouponPricer with a (very) shifted rate, or would it make more sense to define a NormalOvernightIndexedCouponPricer?

Regards,
Ryan

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Peter Caspers <pca...@gm...>
Sent: Tuesday, December 7, 2021 8:40:21 AM
To: R M <rm...@gm...>
Cc: QuantLib users <qua...@li...>
Subject: Re: [Quantlib-users] RFR option matters

Hi Ryan,

we started with this

https://urldefense.com/v3/__https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/cashflows/blackovernightindexedcouponpricer.cpp*L43__;Iw!!EbLleU--iSTUgtNy!-cgw--C4C8zcw1uAbQpSSeqg_yWQ-D4JcDLjU7lLG7-2ngiczr2x0EDsQq-eJJLip4D9--BJ$ [github[.]com]

However I am sure this will require amendments going forward as a
"market formula" for RFR Caps evolves.

Thanks
Peter

On Mon, 22 Nov 2021 at 15:47, R M <rm...@gm...> wrote:
>
> Hello QuantLib users,
>
> My employer is going through the rigmarole of sourcing RFR option data (e.g. SONIA cap/floor/swaption premiums/vols).
>
> It always amazes me that when you ask a data provider for details on the instrument to which a data point corresponds, you don't get a response like "yes, that information is clearly fundamental, here you go". It's more like "everyone knows". But recently we had one provider tell us that their RFR cap/floor data relates to cap/floors that include the first period, and another told us that theirs don't. It also transpired that one provider was using middle-of-period time-to-maturities for mapping cap/floor premiums to vols, which just seems barbaric to me. (I guess this is to blame for that.)
>
> I don't think QL has started implementing vol surface construction from RFR option data (?), for which these issues are... fundamental. But have discussions on this begun? If not, happy to open a GitHub issue and continue this there.
>
> Regards,
> Ryan
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/quantlib-users__;!!EbLleU--iSTUgtNy!-cgw--C4C8zcw1uAbQpSSeqg_yWQ-D4JcDLjU7lLG7-2ngiczr2x0EDsQq-eJJLip7Mdv2tq$ [lists[.]sourceforge[.]net]


_______________________________________________
QuantLib-users mailing list
Qua...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/quantlib-users__;!!EbLleU--iSTUgtNy!-cgw--C4C8zcw1uAbQpSSeqg_yWQ-D4JcDLjU7lLG7-2ngiczr2x0EDsQq-eJJLip7Mdv2tq$ [lists[.]sourceforge[.]net]

Disclaimer

Chatham Financial Europe, Ltd is authorised and regulated by the Financial Conduct Authority of the United Kingdom with reference number 197251.

The privacy and security of your personal data is important to us. Your details may be stored in our client and contacts database for the purpose of sending you business communications, updates, newsletters, event invitations and other information which we think is relevant to you. If you would like further information about the types of personal data we hold about you, our legal grounds for doing so, how we collect and protect your personal data and your rights in relation to such data, please see Chatham's Privacy Policy<https://www.chathamfinancial.com/privacy-policy>.

The information contained in this e-mail is confidential and is only for the use of the intended recipient. If you are not the intended recipient, any further copying, use, distribution or disclosure of the contents of this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently expunge the original e-mail, and any electronic copies, from your system and destroy any hard copy versions of the e-mail. Where the content of this e-mail is personal or otherwise unconnected with our or our clients' business, we accept no responsibility or liability for such content. Telephone calls may be monitored and/or recorded.

[Quantlib-users] Is Implied volatility method available for Asian option class

[Ashish B. <ash...@gm...>]

Hi,

I am trying to evaluate the Arithmetic averaging Asian option using QL
class called DiscreteAveragingAsianOption. However, there is no method
under it to calculate the implied volatility, which is present for plain
vanilla and barrier options.

Please help how can I calculate IV for Asian options.

Regards,
Ashish

Re: [Quantlib-users] RFR option matters

[Peter C. <pca...@gm...>]

Hi Ryan,

we started with this

https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/cashflows/blackovernightindexedcouponpricer.cpp#L43

However I am sure this will require amendments going forward as a
"market formula" for RFR Caps evolves.

Thanks
Peter

On Mon, 22 Nov 2021 at 15:47, R M <rm...@gm...> wrote:
>
> Hello QuantLib users,
>
> My employer is going through the rigmarole of sourcing RFR option data (e.g. SONIA cap/floor/swaption premiums/vols).
>
> It always amazes me that when you ask a data provider for details on the instrument to which a data point corresponds, you don't get a response like "yes, that information is clearly fundamental, here you go". It's more like "everyone knows". But recently we had one provider tell us that their RFR cap/floor data relates to cap/floors that include the first period, and another told us that theirs don't. It also transpired that one provider was using middle-of-period time-to-maturities for mapping cap/floor premiums to vols, which just seems barbaric to me. (I guess this is to blame for that.)
>
> I don't think QL has started implementing vol surface construction from RFR option data (?), for which these issues are... fundamental. But have discussions on this begun? If not, happy to open a GitHub issue and continue this there.
>
> Regards,
> Ryan
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Quantlib-users] Fast way to obtain discount factors on an array of dates?

[jian Xu <jia...@gm...>]

Hi,

YieldTermStructure has a function discount() to return the discount
factor on a single date.  But is there a function to return an array
of discount factors on an array of dates?

Currently, I'm looping in python

disc = np.array([disc_curve.discount(d) for d in dates])

But the python loops are pretty slow.  Just wondering if there's any
faster way to do this.  Thanks a lot!

Jian

[Quantlib-users] Model for pricing Asian options

[Ashish B. <ash...@gm...>]

Hi,

Is the turnbull-wakeman model supported in QL for pricing the asian
options? I wish to price the commodity asian options.

Regards,
Ashish

Re: [Quantlib-users] Is a gamma pricing model available?

[Peng Yu <pen...@gm...>]

https://github.com/lballabio/QuantLib/tree/f47242c966d191e1b542162b1f2d726615bdba89/ql/experimental/variancegamma

Are you talking about the above?

I see there are 4 engines.

- analyticvariancegammaengine
- fftengine
- fftvanillaengine
- fftvariancegammaengine

I see the following doc.

analyticvariancegammaengine:
    //! Variance Gamma Pricing engine for European vanilla options
using integral approach

What is integral approach? Is there a doc explaining what it is?

fftengine:

        The FFT engine calculates the values of all options with the
same expiry at the same time.
        For that reason it is very inefficient to price options
individually.  When using this engine
        you should collect all the options you wish to price in a list and call
        the engine's precalculate method before calling the NPV method
of the option.
        References:
        Carr, P. and D. B. Madan (1998),
        "Option Valuation using the fast Fourier transform,"
        Journal of Computational Finance, 2, 61-73.

fftvanillaengine
    //! FFT Pricing engine vanilla options under a Black Scholes process
    /*! \ingroup vanillaengines
        \test the correctness of the returned values is tested by
        comparison with Black Scholes pricing.

fftvariancegammaengine
    //! FFT engine for vanilla options under a Variance Gamma process
    /*! \ingroup vanillaengines
        \test the correctness of the returned values is tested by
        comparison with known good values and the analytic approach

But it is confusing to me about whether all four can be used with
ql.VarianceGammaProcess, or only analyticvariancegammaengine and
fftvariancegammaengine can be used with ql.VarianceGammaProcess.

I don't see these engines documented in python. Is the doc incomplete?
Could you explain the difference between them, what is the pros and
cons of each engine, and when to use which engine?

https://quantlib-python-docs.readthedocs.io/en/latest/search.html?q=fftengine&check_keywords=yes&area=default#

Could you show an example of how to use ql.VarianceGammaProcess in python?

On 11/30/21, Luigi Ballabio <lui...@gm...> wrote:
> Hi,
>     there's a couple of engines supporting the VarianceGammaProcess (you
> can find them in ql/experimenta/variancegamma) but they only support
> European options.  The two papers you quoted are not implemented.
>
> Luigi
>
>
> On Tue, Nov 30, 2021 at 4:03 PM Peng Yu <pen...@gm...> wrote:
>
>> I see the following two methods in this direction.
>>
>> Pricing American Options Under Variance Gamma
>> https://www.math.columbia.edu/~smirnov/Alihirsa.pdf
>>
>> A fast method for pricing American options under the variance gamma model
>> http://arxiv-export-lb.library.cornell.edu/abs/1903.07519v1
>>
>> I also notice there is VarianceGammaProcess in quantlib. Does
>> VarianceGammaProcess implement any of these two methods? Or it is
>> something totally different?
>>
>> I want to model American options. I tried the following code (full
>> code attached).
>>
>> american_option.setPricingEngine(
>> ql.BinomialVanillaEngine(
>> process = ql.VarianceGammaProcess(
>> ql.QuoteHandle(
>> ql.SimpleQuote(spot_price)
>> )
>> , ql.YieldTermStructureHandle(
>> ql.FlatForward(calculation_date, dividend_rate, day_count)
>> )
>> , ql.YieldTermStructureHandle(
>> ql.FlatForward(calculation_date, risk_free_rate, day_count)
>> )
>> , sigma = 0.2
>> , nu = 1
>> , theta = 1
>> )
>> , type = 'crr'
>> , steps = 200)
>> )
>>
>> But I got the following error. I am not sure what the meaning of the
>> error is. Does it mean BinomialVanillaEngine is not compatible with
>> VarianceGammaProcess? Could anybody show me the correct way to price
>> American options using variance Gamma processes?
>>
>> Traceback (most recent call last):
>>   File "./main.py", line 26, in <module>
>>     ql.BinomialVanillaEngine(
>>   File
>> "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/QuantLib/QuantLib.py",
>> line 12456, in BinomialVanillaEngine
>>     return cls(process, steps)
>>   File
>> "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/QuantLib/QuantLib.py",
>> line 12365, in __init__
>>     _QuantLib.BinomialCRRVanillaEngine_swiginit(self,
>> _QuantLib.new_BinomialCRRVanillaEngine(arg2, steps))
>> TypeError: in method 'new_BinomialCRRVanillaEngine', argument 1 of
>> type 'ext::shared_ptr< GeneralizedBlackScholesProcess > const &'
>>
>> > I see a gamma pricing model is mentioned below. But I don't see any
>> > formula in the page. Does anybody where I can find a more detailed
>> > description of the gamma pricing model?
>> >
>> > Does quantlib have an implementation of a gamma pricing model? (I
>> > don't find it. But I may miss it.)
>> >
>> > https://www.investopedia.com/terms/g/gamma-pricing-model.asp
>>
>> --
>> Regards,
>> Peng
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>


-- 
Regards,
Peng

Re: [Quantlib-users] Is a gamma pricing model available?

[Luigi B. <lui...@gm...>]

Hi,
    there's a couple of engines supporting the VarianceGammaProcess (you
can find them in ql/experimenta/variancegamma) but they only support
European options.  The two papers you quoted are not implemented.

Luigi


On Tue, Nov 30, 2021 at 4:03 PM Peng Yu <pen...@gm...> wrote:

> I see the following two methods in this direction.
>
> Pricing American Options Under Variance Gamma
> https://www.math.columbia.edu/~smirnov/Alihirsa.pdf
>
> A fast method for pricing American options under the variance gamma model
> http://arxiv-export-lb.library.cornell.edu/abs/1903.07519v1
>
> I also notice there is VarianceGammaProcess in quantlib. Does
> VarianceGammaProcess implement any of these two methods? Or it is
> something totally different?
>
> I want to model American options. I tried the following code (full
> code attached).
>
> american_option.setPricingEngine(
> ql.BinomialVanillaEngine(
> process = ql.VarianceGammaProcess(
> ql.QuoteHandle(
> ql.SimpleQuote(spot_price)
> )
> , ql.YieldTermStructureHandle(
> ql.FlatForward(calculation_date, dividend_rate, day_count)
> )
> , ql.YieldTermStructureHandle(
> ql.FlatForward(calculation_date, risk_free_rate, day_count)
> )
> , sigma = 0.2
> , nu = 1
> , theta = 1
> )
> , type = 'crr'
> , steps = 200)
> )
>
> But I got the following error. I am not sure what the meaning of the
> error is. Does it mean BinomialVanillaEngine is not compatible with
> VarianceGammaProcess? Could anybody show me the correct way to price
> American options using variance Gamma processes?
>
> Traceback (most recent call last):
>   File "./main.py", line 26, in <module>
>     ql.BinomialVanillaEngine(
>   File
> "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/QuantLib/QuantLib.py",
> line 12456, in BinomialVanillaEngine
>     return cls(process, steps)
>   File
> "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/QuantLib/QuantLib.py",
> line 12365, in __init__
>     _QuantLib.BinomialCRRVanillaEngine_swiginit(self,
> _QuantLib.new_BinomialCRRVanillaEngine(arg2, steps))
> TypeError: in method 'new_BinomialCRRVanillaEngine', argument 1 of
> type 'ext::shared_ptr< GeneralizedBlackScholesProcess > const &'
>
> > I see a gamma pricing model is mentioned below. But I don't see any
> > formula in the page. Does anybody where I can find a more detailed
> > description of the gamma pricing model?
> >
> > Does quantlib have an implementation of a gamma pricing model? (I
> > don't find it. But I may miss it.)
> >
> > https://www.investopedia.com/terms/g/gamma-pricing-model.asp
>
> --
> Regards,
> Peng
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>