quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Possible future works

[James <jam...@gm...>]

Hi Luigi,

 

Yes, there are a few financial use cases for the Expectation-Maximization (EM) algorithm. For instance, it can be used to train models of stock market interactions. If we use a model to capture the interactions between the stock markets, EM algorithm can be used to iteratively improve the model until some parameter closely models the data, or until the algorithm times out.

 

Here is a link that illustrate the above example: http://www.tryfsharp.org/Learn/financial-computing#training-the-model

 

I’m not from finance background and I’m stilling learning QuantLib, so my proposal may not really fit this library. But please let me know if this could be useful and I will start working on it.

 

Thanks and regards,

James

 

 

 

From: Luigi Ballabio [mailto:lui...@gm...] 
Sent: Wednesday, December 24, 2014 2:32 PM
To: James
Cc: Xiang Ni; QuantLib developers
Subject: Re: [Quantlib-dev] Possible future works

 

Hello,

    do you have a financial use case for the algorithm?

 

Luigi

 

On Sat, Dec 20, 2014 at 11:58 PM, James <jam...@gm... <mailto:jam...@gm...> > wrote:

Hi Xiang Ni,

Thanks for your reply. I'm not surprised that there is a implementation already available. Actually, you can probably find available implementations for most algorithms that we are aware of. But whether the code we find fits the framework (QuantLib) is a question. For instance, the data structures used throughout the algorithm may need to be converted, and this task alone may not be trivial...

Whether an algorithm has already been implemented or not is a bit off the topic. I think a more important question should be - is this algorithm really needed for QuantLib?

Regards,
James


-----Original Message-----
From: Xiang Ni [mailto:xn...@ca... <mailto:xn...@ca...> ]
Sent: Friday, December 19, 2014 12:16 AM
To: James
Cc: qua...@li... <mailto:qua...@li...> 
Subject: Re: [Quantlib-dev] Possible future works

It seems that EM algo can be found here:

http://code.opencv.org/projects/opencv/repository/revisions/master/entry/modules/ml/src/em.cpp#L126

On Thu, December 18, 2014 3:09 pm, James wrote:
> Hi All,
>
>
>
> Having learned QuantLib for a while, I'm very impressed by the great
> design of the software architecture, and I would love to contribute to
> this project. I'm a software engineer from general signal processing
> background, but I don't really have much experience on quantitative
> finance. I have read the developers mail list archive but could not
> find any topic related to possible future works that a developer like
> me can contribute to. So I would be really appreciated if someone can
> let me know what is currently missing and will be nice to have in
> future QuantLib. A list of these possible future works will surely
> benefit the development of QuantLib.
>
>
>
> To start with, do you think a general Expectation-Maximization
> algorithm could be added into the future to-do-list?
>
>
>
> Thanks and regards,
>
> James
>
> ----------------------------------------------------------------------

> -------- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT
> Server from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards with Interactivity, Sharing, Native Excel Exports, App
> Integration & more Get technology previously reserved for
> billion-dollar corporations, FREE

> http://pubads.g.doubleclick.net/gampad/clk?id=164703151 <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg> &iu=/4140/ostg.
> clktrk_______________________________________________
> QuantLib-dev mailing list
> Qua...@li... <mailto:Qua...@li...> 
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>


--
Xiang Ni,

Department of Mathematics

California Institute of Technology

http://math.caltech.edu/people/xiang-homepage.html



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151 <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk> &iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-dev mailing list
Qua...@li... <mailto:Qua...@li...> 
https://lists.sourceforge.net/lists/listinfo/quantlib-dev





 

-- 

<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] Possible future works

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

Hello,
    do you have a financial use case for the algorithm?

Luigi

On Sat, Dec 20, 2014 at 11:58 PM, James <jam...@gm...> wrote:

> Hi Xiang Ni,
>
> Thanks for your reply. I'm not surprised that there is a implementation
> already available. Actually, you can probably find available
> implementations for most algorithms that we are aware of. But whether the
> code we find fits the framework (QuantLib) is a question. For instance, the
> data structures used throughout the algorithm may need to be converted, and
> this task alone may not be trivial...
>
> Whether an algorithm has already been implemented or not is a bit off the
> topic. I think a more important question should be - is this algorithm
> really needed for QuantLib?
>
> Regards,
> James
>
> -----Original Message-----
> From: Xiang Ni [mailto:xn...@ca...]
> Sent: Friday, December 19, 2014 12:16 AM
> To: James
> Cc: qua...@li...
> Subject: Re: [Quantlib-dev] Possible future works
>
> It seems that EM algo can be found here:
>
>
> http://code.opencv.org/projects/opencv/repository/revisions/master/entry/modules/ml/src/em.cpp#L126
>
> On Thu, December 18, 2014 3:09 pm, James wrote:
> > Hi All,
> >
> >
> >
> > Having learned QuantLib for a while, I'm very impressed by the great
> > design of the software architecture, and I would love to contribute to
> > this project. I'm a software engineer from general signal processing
> > background, but I don't really have much experience on quantitative
> > finance. I have read the developers mail list archive but could not
> > find any topic related to possible future works that a developer like
> > me can contribute to. So I would be really appreciated if someone can
> > let me know what is currently missing and will be nice to have in
> > future QuantLib. A list of these possible future works will surely
> > benefit the development of QuantLib.
> >
> >
> >
> > To start with, do you think a general Expectation-Maximization
> > algorithm could be added into the future to-do-list?
> >
> >
> >
> > Thanks and regards,
> >
> > James
> >
> > ----------------------------------------------------------------------
> > -------- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT
> > Server from Actuate! Instantly Supercharge Your Business Reports and
> > Dashboards with Interactivity, Sharing, Native Excel Exports, App
> > Integration & more Get technology previously reserved for
> > billion-dollar corporations, FREE
> > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.
> > clktrk_______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
>
>
> --
> Xiang Ni,
>
> Department of Mathematics
>
> California Institute of Technology
>
> http://math.caltech.edu/people/xiang-homepage.html
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

[Quantlib-dev] Intraday patch

[Joseph W. <joe...@gm...>]

I've just pushed up a patch to quantlib that provides basic support
for intraday calculations.  The patch consists of two new classes

timestamp - which is a simple UTC timestamp class.  It is a subclass
of Date, and can be used whereever date is.

continoustime - is a day counter that supports intraday calculations
with timestamp.  ContinousTime allows the user to specify the base
unit, so it is now possible to specify
interest rates and volatility per day, per week, or per month (which
is defined as 30 days) rather than per year.

The only non backward compartible part is the use of "yearFraction" to
specify something other than a fraction of a year.  There is a
function "timeFraction" which calls yearFraction.

Also this counter does not handle leap seconds, but I plan to add that.

I also intentionally left time zones out of these additions since
that's another level of complexity.

I can write some unit tests and I'll add some more comments.  However,
before I do, I'd like some feedback about the general class structure
and to go through a code review.

Below is python code that uses the new interface

def option(strike, vol, t, putcall):
    now = TimeStamp.now()
    Settings.instance().evaluationDate = now
    settlementDate = todaysDate + Period(3, Weeks)
    riskFreeRate = FlatForward(settlementDate, 0.00, ContinuousTime.perDay())

    # option parameters
    exercise = EuropeanExercise(settlementDate)
    payoff = PlainVanillaPayoff(Option.Call, strike)
    x = np.arange(strike*0.8, strike*1.2, 0.01);

    volatility = BlackConstantVol(todaysDate, TARGET(), vol,
ContinuousTime.perDay())
    dividendYield = FlatForward(settlementDate, 0.00, ContinuousTime.perDay())
    underlying = SimpleQuote(0.0)
    process = BlackScholesMertonProcess(QuoteHandle(underlying),
                                    YieldTermStructureHandle(dividendYield),
                                    YieldTermStructureHandle(riskFreeRate),
                                    BlackVolTermStructureHandle(volatility))
    option = VanillaOption(payoff, exercise)
    # method: analytic
    option.setPricingEngine(AnalyticEuropeanEngine(process))
    def myfunc(x):
        underlying .setValue(x)
        return option.NPV()
    def mydelta(x):
        underlying.setValue(x)
        return option.delta()
    def mytheta(x):
        underlying.setValue(x)
        return option.theta()
    plt.figure(1, figsize=(5,8))
    plt.subplot(211)
    y = map(payoff, x)
    plt.plot(x, y)
    plt.plot(x, map(myfunc,x))
    plt.subplot(212)
    plt.plot(x, map(mydelta,x))

Re: [Quantlib-dev] Possible future works

[James <jam...@gm...>]

Hi Xiang Ni,

Thanks for your reply. I'm not surprised that there is a implementation already available. Actually, you can probably find available implementations for most algorithms that we are aware of. But whether the code we find fits the framework (QuantLib) is a question. For instance, the data structures used throughout the algorithm may need to be converted, and this task alone may not be trivial...

Whether an algorithm has already been implemented or not is a bit off the topic. I think a more important question should be - is this algorithm really needed for QuantLib? 

Regards,
James

-----Original Message-----
From: Xiang Ni [mailto:xn...@ca...] 
Sent: Friday, December 19, 2014 12:16 AM
To: James
Cc: qua...@li...
Subject: Re: [Quantlib-dev] Possible future works

It seems that EM algo can be found here:

http://code.opencv.org/projects/opencv/repository/revisions/master/entry/modules/ml/src/em.cpp#L126

On Thu, December 18, 2014 3:09 pm, James wrote:
> Hi All,
>
>
>
> Having learned QuantLib for a while, I'm very impressed by the great 
> design of the software architecture, and I would love to contribute to 
> this project. I'm a software engineer from general signal processing 
> background, but I don't really have much experience on quantitative  
> finance. I have read the developers mail list archive but could not 
> find any topic related to possible future works that a developer like 
> me can contribute to. So I would be really appreciated if someone can 
> let me know what is currently missing and will be nice to have in 
> future QuantLib. A list of these possible future works will surely 
> benefit the development of QuantLib.
>
>
>
> To start with, do you think a general Expectation-Maximization 
> algorithm could be added into the future to-do-list?
>
>
>
> Thanks and regards,
>
> James
>
> ----------------------------------------------------------------------
> -------- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT 
> Server from Actuate! Instantly Supercharge Your Business Reports and 
> Dashboards with Interactivity, Sharing, Native Excel Exports, App 
> Integration & more Get technology previously reserved for 
> billion-dollar corporations, FREE 
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.
> clktrk_______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>


--
Xiang Ni,

Department of Mathematics

California Institute of Technology

http://math.caltech.edu/people/xiang-homepage.html

[Quantlib-dev] Intraday extensions for bitcoin derivatives trading

[Joseph W. <joe...@gm...>]

Just to throw out some ideas for dealing with bitcoin derivatives.

Bitcoin has two unique features.  The trading is continuous.  The
expiry times are short, and all the numbers are quoted in days rather
than in years.

So:

1) I write some new classes that are just placeholders for time
stamps.  To keep it simple, the simpletimestamp class will keep
everything in GMT, so we don't have to worry about time zone heck.

2) I write a new daycounter called "continuousdays" which will return
the number of *days* between two timestamps.  It appears that if I use
that daycounter then everything will work.

The two issues I see are:

The method "yearFraction" ought really to be named "timeFraction"

Also, I'm trying to figure out how to prevent (or whether to prevent)
someone from mixing year and day valued functions.

[Quantlib-dev] Quantlib for bitcoin derivatives

[Joseph W. <joe...@gm...>]

Hi all,

I've started up an operation here in Hong Kong trading bitcoin
derivatives, and it look like that I'll need to make some additions to
QuantLib.  Here is just a list of features that it looks I need off
the top of my head.  I'll be adding them, but i didn't want to
reinvent the wheel and it's be interested in design issues.

1) classes for XBT and XLT.  This seems pretty straight forward
2) classes for intraday calculations.  The issue with XBT is that most
of the options are short dated which means that one day is too much
granularity.  I'll need a timestamp class.
3) The other problem is that most calculations seem to be done by year
as the base unit.  With XBT it makes more sense to calculate by day

Also, there might be some need for an "exchange" class to track
exchanges since I'm doing arb trades.  A "wallet" class might also be
useful, but at that point this seems like something that would be
better done outside of QuantLib.

Thoughts?

Re: [Quantlib-dev] Possible future works

[Xiang N. <xn...@ca...>]

It seems that EM algo can be found here:

http://code.opencv.org/projects/opencv/repository/revisions/master/entry/modules/ml/src/em.cpp#L126

On Thu, December 18, 2014 3:09 pm, James wrote:
> Hi All,
>
>
>
> Having learned QuantLib for a while, I'm very impressed by the great
> design
> of the software architecture, and I would love to contribute to this
> project. I'm a software engineer from general signal processing
> background,
> but I don't really have much experience on quantitative  finance. I have
> read the developers mail list archive but could not find any topic related
> to possible future works that a developer like me can contribute to. So I
> would be really appreciated if someone can let me know what is currently
> missing and will be nice to have in future QuantLib. A list of these
> possible future works will surely benefit the development of QuantLib.
>
>
>
> To start with, do you think a general Expectation-Maximization algorithm
> could be added into the future to-do-list?
>
>
>
> Thanks and regards,
>
> James
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>


-- 
Xiang Ni,

Department of Mathematics

California Institute of Technology

http://math.caltech.edu/people/xiang-homepage.html

[Quantlib-dev] Possible future works

[James <jam...@gm...>]

Hi All,

 

Having learned QuantLib for a while, I'm very impressed by the great design
of the software architecture, and I would love to contribute to this
project. I'm a software engineer from general signal processing background,
but I don't really have much experience on quantitative  finance. I have
read the developers mail list archive but could not find any topic related
to possible future works that a developer like me can contribute to. So I
would be really appreciated if someone can let me know what is currently
missing and will be nice to have in future QuantLib. A list of these
possible future works will surely benefit the development of QuantLib.

 

To start with, do you think a general Expectation-Maximization algorithm
could be added into the future to-do-list?

 

Thanks and regards,

James 

Re: [Quantlib-dev] upgrade solution to VC12 (Visual 2013)

[Eric E. <eri...@re...>]

Hi Georgy,

On Tue, 9 Dec 2014 00:20:05 +0100
Georgy Dschikia <geo...@gm...> wrote:

> Thank you. I'll try it out. Are you planning to include VC12 files in
> a 1.4 release of QuantLIb?

What is your objective?

The script upgrade_vc.py is what I use to upgrade VC files for the
ObjectHandler, QuantLibAddin, and QuantLibXL projects.  It would be
possible to modify that script for use with other projects e.g.
QuantLib.

Are you looking for the VC12 files for QuantLib?  For ObjectHandler /
QuantLibAddin / QuantLibXL?  Does it have to be the 1.4 release, would
1.5 be OK?

The 1.4 releases of QL/OH/QLA/QLXL already shipped without VC12 files.
If you wanted VC12 files for 1.4 you would probably need to create them
yourself somehow.

For the upcoming 1.5 release:

- QuantLib: VC12 files are available on luigi (lballabio)'s git master
- OH/QLA/QLXL: VC12 files are available on maddazanzi's git master and
  that will eventually be merged to my master (and to luigi's) for
  inclusion in 1.5.

If you let us know exactly what you want I can better tell you where to
find it.

Kind Regards,
Eric

Re: [Quantlib-dev] upgrade solution to VC12 (Visual 2013)

[Georgy D. <geo...@gm...>]

Thank you. I'll try it out. Are you planning to include VC12 files in a 1.4
release of QuantLIb?
Kind regards,
Georgy

On Wed, Dec 3, 2014 at 3:35 PM, Eric Ehlers <eri...@re...> wrote:

> Hello,
>
> > Where can I find the ObjectHandler\dev_tools\upgrade_vc.py file? It is
> > missing in ObjectHandler-1.4.0.zip
> > <
> http://sourceforge.net/projects/quantlib/files/ObjectHandler/1.4.0/ObjectHandler-1.4.0.zip/download
> >
>
> That file is not packaged with the release.  You will have to grab it
> from git.
>
> In my repo I have already run this upgrade, to generate VC12 files
> for ObjectHandler, QuantLibAddin, and QuantLibXL.  But I have not yet
> pushed the relevant commit to my remote.  Unfortunately I cannot do that
> for you right now because I am on the road.
>
> If you can wait a couple days, and if you are happy to work from a clone
> of my repo, then you can use the VC12 files that I have created.
>
> If you decide to do the upgrade yourself then let me know because this
> one did not go 100% automatic, there was a little bit of manual
> tinkering required.
>
> Kind Regards,
> Eric
>

Re: [Quantlib-dev] upgrade solution to VC12 (Visual 2013)

[Eric E. <eri...@re...>]

Hello,

> Where can I find the ObjectHandler\dev_tools\upgrade_vc.py file? It is
> missing in ObjectHandler-1.4.0.zip
> <http://sourceforge.net/projects/quantlib/files/ObjectHandler/1.4.0/ObjectHandler-1.4.0.zip/download>

That file is not packaged with the release.  You will have to grab it
from git.

In my repo I have already run this upgrade, to generate VC12 files
for ObjectHandler, QuantLibAddin, and QuantLibXL.  But I have not yet
pushed the relevant commit to my remote.  Unfortunately I cannot do that
for you right now because I am on the road.

If you can wait a couple days, and if you are happy to work from a clone
of my repo, then you can use the VC12 files that I have created.

If you decide to do the upgrade yourself then let me know because this
one did not go 100% automatic, there was a little bit of manual
tinkering required.

Kind Regards,
Eric

Re: [Quantlib-dev] upgrade solution to VC12 (Visual 2013)

[Eric E. <eri...@re...>]

P.S. The VC12 files are available on the remote repo of git user
maddazanzi.  You can grab the relevant commit from there:

https://github.com/maddazanzi/quantlib/commit/396c5e630adf9de0a4d67e793a7c35e601174ff3

Re: [Quantlib-dev] QuantLib + boost 1.55

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

Google suggests to try -mmacosx-version-min=10.7 instead.

Luigi

On Wed, Dec 3, 2014 at 2:50 AM, jasonhsing <jas...@fo...> wrote:

> Hi Luigi,
>
> I have set CXXFLAGS and LDFLAGS to -stdlib=libstdc++
> -mmacosx-version-min=10.6.
> But the Quantlib still cannot work, because of a clang: error:
>          invalid deployment target for -stdlib=libc++ (requires OS X 10.7
> or
> later).
>
> Any suggestions?
> Thank you so much.
> <
> http://quantlib.10058.n7.nabble.com/file/n16099/Screen_Shot_2014-12-02_at_%E4%B8%8B%E5%8D%888.jpg
> >
> Jason
>
>
>
> --
> View this message in context:
> http://quantlib.10058.n7.nabble.com/QuantLib-boost-1-55-tp14715p16099.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] QuantLib + boost 1.55

[jasonhsing <jas...@fo...>]

Hi Luigi,

I have set CXXFLAGS and LDFLAGS to -stdlib=libstdc++
-mmacosx-version-min=10.6.
But the Quantlib still cannot work, because of a clang: error:
         invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or
later).

Any suggestions? 
Thank you so much.
<http://quantlib.10058.n7.nabble.com/file/n16099/Screen_Shot_2014-12-02_at_%E4%B8%8B%E5%8D%888.jpg> 
Jason 



--
View this message in context: http://quantlib.10058.n7.nabble.com/QuantLib-boost-1-55-tp14715p16099.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] upgrade solution to VC12 (Visual 2013)

[Georgy D. <geo...@gm...>]

Where can I find the ObjectHandler\dev_tools\upgrade_vc.py file? It is
missing in ObjectHandler-1.4.0.zip
<http://sourceforge.net/projects/quantlib/files/ObjectHandler/1.4.0/ObjectHandler-1.4.0.zip/download>
...

On Thu, Aug 14, 2014 at 1:58 PM, Eric Ehlers <eri...@na...>
wrote:

>   The file is
> ObjectHandler\dev_tools\upgrade_vc.py.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Performance hit of QL_REQUIRE

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

Hi Francois,
    I didn't notice any particular slowdown. Then again, as you
say, QL_REQUIRE is a macro in the C++ library. On the happy path, the cost
is just the evaluation of the condition.

Luigi


On Wed, Nov 26, 2014 at 2:54 PM, Francois Botha <ig...@gm...> wrote:

> Hi,
>
> It seems since v1.0.0 a lot of QL_REQUIRE statements were added. Do you
> have any idea of how that impacted on the performance, if any?
>
> A user of the QLNet version noticed a big impact, but in QLNet we use a
> normal function, and not a macro, so the impact is somewhat expected
> (parameter values are evaluated whether or not the condition holds).
>
> I'm curious as to whether any impact was noticed in QuantLib.
>
> See discussion at https://github.com/amaggiulli/qlnet/issues/40
>
> thanks
> Francois Botha
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>


-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

[Quantlib-dev] Performance hit of QL_REQUIRE

[Francois B. <ig...@gm...>]

Hi,

It seems since v1.0.0 a lot of QL_REQUIRE statements were added. Do you
have any idea of how that impacted on the performance, if any?

A user of the QLNet version noticed a big impact, but in QLNet we use a
normal function, and not a macro, so the impact is somewhat expected
(parameter values are evaluated whether or not the condition holds).

I'm curious as to whether any impact was noticed in QuantLib.

See discussion at https://github.com/amaggiulli/qlnet/issues/40

thanks
Francois Botha

Re: [Quantlib-dev] Interpolated ZeroInflationIndexes

[Francois B. <ig...@gm...>]

No, it's still work in progress. Guess it's about time I finish it. :-)
On 20 Nov 2014 4:57 PM, "Luigi Ballabio" <lui...@gm...> wrote:

> Hi Francois,
>     did you ever submit this fix? I don't seem to remember it.
> Or was the problem fixed in another way?
>
> Luigi
>
> On Thu, Jul 10, 2014 at 4:36 PM, Francois Botha <ig...@gm...> wrote:
>
>> Peter,
>>
>> Here is my first attempt at solving this bug. Can you confirm whether it
>> solves your problem?
>> https://github.com/igitur/quantlib/tree/inflation_reference_period_fix
>>
>> Francois Botha
>>
>>
>> On 18 June 2014 17:27, Francois Botha <ig...@gm...> wrote:
>>
>>> Haha. I actually did read your email the other day, but I didn't make
>>> the connection when I discovered the issue now. No fix yet, but I'll see if
>>> I can get something together. It will have to  involve passing the original
>>> reference date through to the fixing algorithm.
>>>
>>> F
>>>
>>> Francois Botha
>>>
>>>
>>> On 18 June 2014 17:17, Peter Caspers <pca...@gm...> wrote:
>>>
>>>> Hi Francois,
>>>>
>>>> yes, you have to use June's 30 days. This is corresponding to the
>>>> question I sent earlier (see below), the second (Murex) way of doing
>>>> the interpolation is the correct one.
>>>>
>>>> Do you have a fix for that ? This would be great.
>>>>
>>>> best
>>>> Peter
>>>>
>>>> I am comparing Murex and QuantLib concerning Inflation Pricing. I
>>>> observe a difference in the way an index fixing is interpolated
>>>> between known (i.e. already fixed) values. Here is an example:
>>>> Take the EUHICP XT index which has fixings
>>>> 01.08.2012 (Aug 12) 115.10
>>>> 01.09.2012 (Sep 12) 115.97
>>>> Now I want to look up the fixing on 28.08.2012 belonging to an
>>>> observation date on 28.11.2012 (3m observation lag). In QL the
>>>> interpolation is done as follows:
>>>> Days between 01.08. and 01.09. = 31, Days between 01.08. and 28.08. =
>>>> 27, Interpolated Fixing = 115.10 + 27/31 * ( 115.97 - 115.10 )
>>>> In Murex on the opposite:
>>>> Days between 01.11. and 01.12. = 30, Days between 01.11. and 28.11. =
>>>> 27, Interpolated Fixing = 115.10 + 27/30 * ( 115.97 - 115.10 )
>>>>
>>>> On 18 June 2014 16:50, Francois Botha <ig...@gm...> wrote:
>>>> > Hi,
>>>> >
>>>> > I think the interpolation in ZeroInflationIndex::fixing isn't exactly
>>>> > correctly.
>>>> >
>>>> > Consider a linearly interpolated Zero Inflation Index with
>>>> observation lag
>>>> > of 4 months. If the reference date is in June, the observation date
>>>> will be
>>>> > in February, which has only 28 days. I believe the interpolation
>>>> should use
>>>> > June's 30 days instead of February's 28 days. As it is, the
>>>> interpolation
>>>> > will be "maxed out" by 28 June and will remain flat until 30 June.
>>>> Do you
>>>> > guys agree?
>>>> >
>>>> > regards
>>>> > Francois Botha
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> > HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>>>> Solutions
>>>> > Find What Matters Most in Your Big Data with HPCC Systems
>>>> > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>>>> > Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>>>> > http://p.sf.net/sfu/hpccsystems
>>>> > _______________________________________________
>>>> > QuantLib-dev mailing list
>>>> > Qua...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>> >
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community
>> Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>
>

Re: [Quantlib-dev] Interpolated ZeroInflationIndexes

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

Also on interpolation of inflation rates, a quick peer review: I think line
169 of <ql/termstructures/inflationtermstructure.cpp> was supposed to
interpolate linearly between the two zero rates, but the formula is wrong.
Is anyone using, or did anyone try to use this forceLinearInterpolation
feature and can confirm?

Thanks,
    Luigi


On Thu, Nov 20, 2014 at 3:57 PM, Luigi Ballabio <lui...@gm...>
wrote:

> Hi Francois,
>     did you ever submit this fix? I don't seem to remember it.
> Or was the problem fixed in another way?
>
> Luigi
>
> On Thu, Jul 10, 2014 at 4:36 PM, Francois Botha <ig...@gm...> wrote:
>
>> Peter,
>>
>> Here is my first attempt at solving this bug. Can you confirm whether it
>> solves your problem?
>> https://github.com/igitur/quantlib/tree/inflation_reference_period_fix
>>
>> Francois Botha
>>
>>
>> On 18 June 2014 17:27, Francois Botha <ig...@gm...> wrote:
>>
>>> Haha. I actually did read your email the other day, but I didn't make
>>> the connection when I discovered the issue now. No fix yet, but I'll see if
>>> I can get something together. It will have to  involve passing the original
>>> reference date through to the fixing algorithm.
>>>
>>> F
>>>
>>> Francois Botha
>>>
>>>
>>> On 18 June 2014 17:17, Peter Caspers <pca...@gm...> wrote:
>>>
>>>> Hi Francois,
>>>>
>>>> yes, you have to use June's 30 days. This is corresponding to the
>>>> question I sent earlier (see below), the second (Murex) way of doing
>>>> the interpolation is the correct one.
>>>>
>>>> Do you have a fix for that ? This would be great.
>>>>
>>>> best
>>>> Peter
>>>>
>>>> I am comparing Murex and QuantLib concerning Inflation Pricing. I
>>>> observe a difference in the way an index fixing is interpolated
>>>> between known (i.e. already fixed) values. Here is an example:
>>>> Take the EUHICP XT index which has fixings
>>>> 01.08.2012 (Aug 12) 115.10
>>>> 01.09.2012 (Sep 12) 115.97
>>>> Now I want to look up the fixing on 28.08.2012 belonging to an
>>>> observation date on 28.11.2012 (3m observation lag). In QL the
>>>> interpolation is done as follows:
>>>> Days between 01.08. and 01.09. = 31, Days between 01.08. and 28.08. =
>>>> 27, Interpolated Fixing = 115.10 + 27/31 * ( 115.97 - 115.10 )
>>>> In Murex on the opposite:
>>>> Days between 01.11. and 01.12. = 30, Days between 01.11. and 28.11. =
>>>> 27, Interpolated Fixing = 115.10 + 27/30 * ( 115.97 - 115.10 )
>>>>
>>>> On 18 June 2014 16:50, Francois Botha <ig...@gm...> wrote:
>>>> > Hi,
>>>> >
>>>> > I think the interpolation in ZeroInflationIndex::fixing isn't exactly
>>>> > correctly.
>>>> >
>>>> > Consider a linearly interpolated Zero Inflation Index with
>>>> observation lag
>>>> > of 4 months. If the reference date is in June, the observation date
>>>> will be
>>>> > in February, which has only 28 days. I believe the interpolation
>>>> should use
>>>> > June's 30 days instead of February's 28 days. As it is, the
>>>> interpolation
>>>> > will be "maxed out" by 28 June and will remain flat until 30 June.
>>>> Do you
>>>> > guys agree?
>>>> >
>>>> > regards
>>>> > Francois Botha
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> > HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>>>> Solutions
>>>> > Find What Matters Most in Your Big Data with HPCC Systems
>>>> > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>>>> > Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>>>> > http://p.sf.net/sfu/hpccsystems
>>>> > _______________________________________________
>>>> > QuantLib-dev mailing list
>>>> > Qua...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>> >
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community
>> Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] Interpolated ZeroInflationIndexes

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

Hi Francois,
    did you ever submit this fix? I don't seem to remember it.
Or was the problem fixed in another way?

Luigi

On Thu, Jul 10, 2014 at 4:36 PM, Francois Botha <ig...@gm...> wrote:

> Peter,
>
> Here is my first attempt at solving this bug. Can you confirm whether it
> solves your problem?
> https://github.com/igitur/quantlib/tree/inflation_reference_period_fix
>
> Francois Botha
>
>
> On 18 June 2014 17:27, Francois Botha <ig...@gm...> wrote:
>
>> Haha. I actually did read your email the other day, but I didn't make the
>> connection when I discovered the issue now. No fix yet, but I'll see if I
>> can get something together. It will have to  involve passing the original
>> reference date through to the fixing algorithm.
>>
>> F
>>
>> Francois Botha
>>
>>
>> On 18 June 2014 17:17, Peter Caspers <pca...@gm...> wrote:
>>
>>> Hi Francois,
>>>
>>> yes, you have to use June's 30 days. This is corresponding to the
>>> question I sent earlier (see below), the second (Murex) way of doing
>>> the interpolation is the correct one.
>>>
>>> Do you have a fix for that ? This would be great.
>>>
>>> best
>>> Peter
>>>
>>> I am comparing Murex and QuantLib concerning Inflation Pricing. I
>>> observe a difference in the way an index fixing is interpolated
>>> between known (i.e. already fixed) values. Here is an example:
>>> Take the EUHICP XT index which has fixings
>>> 01.08.2012 (Aug 12) 115.10
>>> 01.09.2012 (Sep 12) 115.97
>>> Now I want to look up the fixing on 28.08.2012 belonging to an
>>> observation date on 28.11.2012 (3m observation lag). In QL the
>>> interpolation is done as follows:
>>> Days between 01.08. and 01.09. = 31, Days between 01.08. and 28.08. =
>>> 27, Interpolated Fixing = 115.10 + 27/31 * ( 115.97 - 115.10 )
>>> In Murex on the opposite:
>>> Days between 01.11. and 01.12. = 30, Days between 01.11. and 28.11. =
>>> 27, Interpolated Fixing = 115.10 + 27/30 * ( 115.97 - 115.10 )
>>>
>>> On 18 June 2014 16:50, Francois Botha <ig...@gm...> wrote:
>>> > Hi,
>>> >
>>> > I think the interpolation in ZeroInflationIndex::fixing isn't exactly
>>> > correctly.
>>> >
>>> > Consider a linearly interpolated Zero Inflation Index with observation
>>> lag
>>> > of 4 months. If the reference date is in June, the observation date
>>> will be
>>> > in February, which has only 28 days. I believe the interpolation
>>> should use
>>> > June's 30 days instead of February's 28 days. As it is, the
>>> interpolation
>>> > will be "maxed out" by 28 June and will remain flat until 30 June.  Do
>>> you
>>> > guys agree?
>>> >
>>> > regards
>>> > Francois Botha
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>>> Solutions
>>> > Find What Matters Most in Your Big Data with HPCC Systems
>>> > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>>> > Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>>> > http://p.sf.net/sfu/hpccsystems
>>> > _______________________________________________
>>> > QuantLib-dev mailing list
>>> > Qua...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>> >
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>


-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] FW: SABR regression

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

Something like it. I'm about to commit it.  I don't think there's other
values besides 4 and 8.

Luigi

On Wed, Nov 19, 2014 at 5:34 PM, Peter Caspers <pca...@gm...>
wrote:

> fine for me. Would we need something like
>
> QL_REQUIRE(seed == (sizeof(seed) == 4 ? 12345 : 6789), "...")
>
> then ? Are 4 and 8 bytes then only possible values on the myriads of
> platforms that are supported ?
>
> On 19 November 2014 17:13, Luigi Ballabio <lui...@gm...>
> wrote:
> > Nope, the first arg to boost::hash_combine must be a size_t.
> > At this point I'd go for choosing the expected result based on the size
> of
> > size_t. What do you think?
> >
> >
> > On Wed, Nov 19, 2014 at 10:44 AM, Luigi Ballabio <
> lui...@gm...>
> > wrote:
> >>
> >> It looks like we crossed answers :)
> >>
> >> I'll check what happens using long instead of size_t.
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] FW: SABR regression

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

fine for me. Would we need something like

QL_REQUIRE(seed == (sizeof(seed) == 4 ? 12345 : 6789), "...")

then ? Are 4 and 8 bytes then only possible values on the myriads of
platforms that are supported ?

On 19 November 2014 17:13, Luigi Ballabio <lui...@gm...> wrote:
> Nope, the first arg to boost::hash_combine must be a size_t.
> At this point I'd go for choosing the expected result based on the size of
> size_t. What do you think?
>
>
> On Wed, Nov 19, 2014 at 10:44 AM, Luigi Ballabio <lui...@gm...>
> wrote:
>>
>> It looks like we crossed answers :)
>>
>> I'll check what happens using long instead of size_t.

Re: [Quantlib-dev] FW: SABR regression

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

Nope, the first arg to boost::hash_combine must be a size_t.
At this point I'd go for choosing the expected result based on the size of
size_t. What do you think?


On Wed, Nov 19, 2014 at 10:44 AM, Luigi Ballabio <lui...@gm...>
wrote:

> It looks like we crossed answers :)
>
> I'll check what happens using long instead of size_t.
>

Re: [Quantlib-dev] QuantLib + boost 1.55

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

Thanks, it's fixed now.

Luigi

On Mon, Nov 17, 2014 at 7:50 PM, auser <ade...@gm...> wrote:

> Hey Luigi,
>
> Thanks for your message this indeed solves the issue.
> One small correction: stdlib instead of stlib. It is also in one of your SO
> posts.
>
>
>
>
> --
> View this message in context:
> http://quantlib.10058.n7.nabble.com/QuantLib-boost-1-55-tp14715p16048.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] FW: SABR regression

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

It looks like we crossed answers :)

I'll check what happens using long instead of size_t.

Luigi


On Wed, Nov 19, 2014 at 10:42 AM, Luigi Ballabio <lui...@gm...>
wrote:

> No, I think long is 32 bits too.
>
> How about simply checking the hash against two different values depending
> on the size of std::size_t?
>
>
> On Wed, Nov 19, 2014 at 10:25 AM, Peter Caspers <pca...@gm...>
> wrote:
>
>> std::size_t could be the problem (noarbsabr.cpp L329), is that 32 Bit
>> under VC9 ? Should we use usigned long instead, is that always 64 Bit ?
>>
>> On 19 November 2014 09:43, Luigi Ballabio <lui...@gm...>
>> wrote:
>>
>>> It only fails on VC++9.  NoArbSabrTest::testAbsorptionMatrix fails to
>>> verify the hash value of the absorption matrix.
>>>
>>> On Wed, Nov 19, 2014 at 6:43 AM, Peter Caspers <pca...@gm...>
>>> wrote:
>>>
>>>> oops. For me the test suite in the current master both with and without
>>>> #170 runs fine. Only the new regression case included in 170 fails without
>>>> the patch. Let me know what error pops up on your side.
>>>> Peter
>>>>
>>>>
>>>>
>>>> On 18 November 2014 21:57, Ferdinando M. Ametrano <na...@am...>
>>>> wrote:
>>>>
>>>>> wow, this was fast!
>>>>> btw by "sabr test" I meant one test in the QuantlIb test suite
>>>>>
>>>>> On Tue, Nov 18, 2014 at 9:47 PM, Peter Caspers <pca...@gm...
>>>>> > wrote:
>>>>>
>>>>>> Alright, I added a test case for the regression you found and one for
>>>>>> the direct/inverse functions (a deterministic one, yes). I'll have a look
>>>>>> at your data and see if we can extract more interesting test cases from
>>>>>> that.
>>>>>>
>>>>>> And please send the new case when you are back.
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>> On 18 November 2014 20:31, Ferdinando M. Ametrano <na...@am...
>>>>>> > wrote:
>>>>>>
>>>>>>> Yes Peter, I can provide a caplet snapshot for a test.
>>>>>>>
>>>>>>> As for a direct/inverse test: yes please, but avoid random numbers
>>>>>>> as that would make tests unpredictable.
>>>>>>>
>>>>>>> Please also note that one sabr test is currently failing: I don't
>>>>>>> know if because of yesterday's patch or it has been failing for a while.
>>>>>>> thurdays, back at my desk,  I can provide more details, but you might want
>>>>>>> to check it up on your setup in the meantime
>>>>>>> On Nov 18, 2014 9:33 AM, "Peter Caspers" <pca...@gm...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> yes, please send an example (otherwise I could already take the one
>>>>>>>> from the excel you sent earlier ? or was that made up ?). In addtion I
>>>>>>>> think I should add a technical test like
>>>>>>>>
>>>>>>>> for random input x
>>>>>>>> - y = direct(x) generates admissable values
>>>>>>>> - direct( inverse( y ) ) = y
>>>>>>>>
>>>>>>>> for sabr, noarbsabr, zabr and svi. What do you think ?
>>>>>>>>
>>>>>>>> Peter
>>>>>>>>
>>>>>>>>
>>>>>>>> On 17 November 2014 20:07, Ferdinando M. Ametrano <
>>>>>>>> na...@am...> wrote:
>>>>>>>>
>>>>>>>>> Thank you Peter for the timely fix.
>>>>>>>>>
>>>>>>>>> One takeaway is to create a unit test to check for possible future
>>>>>>>>> regressions.
>>>>>>>>> Do you have a relevant dataset from some paper to suggest? If not,
>>>>>>>>> I could provide a snapshot of current euro caplets.
>>>>>>>>> On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <
>>>>>>>>> pao...@es...> wrote:
>>>>>>>>>
>>>>>>>>>>  Hi Peter,
>>>>>>>>>>
>>>>>>>>>> I tested your modifications and they work properly. The results
>>>>>>>>>> are in line with the ones obtained using QL 1.2.
>>>>>>>>>>
>>>>>>>>>> Anyway, the details (forward and time to expiry) are written in
>>>>>>>>>> the excel file attached in the previous email.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> time
>>>>>>>>>>
>>>>>>>>>> fwd
>>>>>>>>>>
>>>>>>>>>> 0.1342
>>>>>>>>>>
>>>>>>>>>> 1.1075%
>>>>>>>>>>
>>>>>>>>>> 0.3833
>>>>>>>>>>
>>>>>>>>>> 1.1025%
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thank you very much for your help.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Paolo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Paolo Mazzocchi*
>>>>>>>>>>
>>>>>>>>>> *Deloitte Consulting Srl*
>>>>>>>>>>
>>>>>>>>>> consulente di
>>>>>>>>>>
>>>>>>>>>> *FINANCIAL ENGINEERING - Banca IMI*
>>>>>>>>>>
>>>>>>>>>> Tel: 02-72615029  Int: 35029
>>>>>>>>>>
>>>>>>>>>> *pao...@es...
>>>>>>>>>> <pao...@es...>*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *From:* Peter Caspers [mailto:pca...@gm...]
>>>>>>>>>> *Sent:* Monday, November 17, 2014 7:00 PM
>>>>>>>>>> *To:* Ferdinando M. Ametrano
>>>>>>>>>> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
>>>>>>>>>> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Ferdinando,
>>>>>>>>>>
>>>>>>>>>> I pushed a fix here (effectively it should yield the same results
>>>>>>>>>> as the file attached earlier)
>>>>>>>>>>
>>>>>>>>>> https://github.com/lballabio/quantlib/pull/170
>>>>>>>>>>
>>>>>>>>>> As far as I remember the reason for the change in the
>>>>>>>>>> transformation function (for 1.3 or 1.4 ?) were nan / inf values occuring
>>>>>>>>>> from time to time in the calibration. This is why I replaced the parabolas
>>>>>>>>>> by truncated parabolas with linear wings (such that the result is C^1).
>>>>>>>>>>
>>>>>>>>>> If you feel that your test case is still working better in 1.2,
>>>>>>>>>> could you please send some more details (forward, time to expiry), I'd be
>>>>>>>>>> happy to discuss again then.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>> Peter
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 17 November 2014 13:25, Peter Caspers <pca...@gm...>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Ferdinando,
>>>>>>>>>>
>>>>>>>>>> one problem is the transformation function direct(...) which is
>>>>>>>>>> buggy for alpha and nu. Can you try the attached version instead and see if
>>>>>>>>>> it works better ?
>>>>>>>>>>
>>>>>>>>>> I'd like to have a closer look and try on more cases before I
>>>>>>>>>> send a PR though.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Peter
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 17 November 2014 12:06, Ferdinando M. Ametrano <
>>>>>>>>>> na...@am...> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Peter
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SABR implementation on the current trunk has a regression
>>>>>>>>>> compared with QuantLib 1.2.1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> While trying to calibrate problematic smiles as:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> strike
>>>>>>>>>>
>>>>>>>>>> 1.00%
>>>>>>>>>>
>>>>>>>>>> 1.13%
>>>>>>>>>>
>>>>>>>>>> 1.25%
>>>>>>>>>>
>>>>>>>>>> 1.38%
>>>>>>>>>>
>>>>>>>>>> 1.50%
>>>>>>>>>>
>>>>>>>>>> vol1
>>>>>>>>>>
>>>>>>>>>> 23.20%
>>>>>>>>>>
>>>>>>>>>> 20.25%
>>>>>>>>>>
>>>>>>>>>> 31.21%
>>>>>>>>>>
>>>>>>>>>> 39.02%
>>>>>>>>>>
>>>>>>>>>> 50.45%
>>>>>>>>>>
>>>>>>>>>> vol2
>>>>>>>>>>
>>>>>>>>>> 16.67%
>>>>>>>>>>
>>>>>>>>>> 20.20%
>>>>>>>>>>
>>>>>>>>>> 27.85%
>>>>>>>>>>
>>>>>>>>>> 32.79%
>>>>>>>>>>
>>>>>>>>>> 37.27%
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> max error
>>>>>>>>>>
>>>>>>>>>> rms error
>>>>>>>>>>
>>>>>>>>>> end criteria
>>>>>>>>>>
>>>>>>>>>> alpha
>>>>>>>>>>
>>>>>>>>>> beta
>>>>>>>>>>
>>>>>>>>>> nu
>>>>>>>>>>
>>>>>>>>>> rho
>>>>>>>>>>
>>>>>>>>>> 1.79%
>>>>>>>>>>
>>>>>>>>>> 0.94%
>>>>>>>>>>
>>>>>>>>>>  StationaryPoint
>>>>>>>>>>
>>>>>>>>>> 0.58%
>>>>>>>>>>
>>>>>>>>>> 25.00%
>>>>>>>>>>
>>>>>>>>>> 346.03%
>>>>>>>>>>
>>>>>>>>>> 34.19%
>>>>>>>>>>
>>>>>>>>>> 0.65%
>>>>>>>>>>
>>>>>>>>>> 0.43%
>>>>>>>>>>
>>>>>>>>>> StationaryPoint
>>>>>>>>>>
>>>>>>>>>> 0.62%
>>>>>>>>>>
>>>>>>>>>> 25.00%
>>>>>>>>>>
>>>>>>>>>> 193.97%
>>>>>>>>>>
>>>>>>>>>> 63.66%
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> the current trunk instead fails for the second smile with error
>>>>>>>>>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If one tries to just use the four leftmost volatilities to
>>>>>>>>>> simplify the problem, both calibrations fail with the same error. This
>>>>>>>>>> leads me to believe the problem is about the solver looking for a solution
>>>>>>>>>> in the negative nu region. If this is the case it could be solved having a
>>>>>>>>>> positive constraint for nu. Do you agree? Could you please look into it?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please find attached a spreadsheet reproducing the error. We
>>>>>>>>>> might even want to add a non regression test to the test suite.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> thank you for your help
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> regards
>>>>>>>>>>
>>>>>>>>>> F
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Prima di stampare, pensa all'ambiente ** Think about the
>>>>>>>>>> environment before printing
>>>>>>>>>>
>>>>>>>>>> ------------------------------
>>>>>>>>>>
>>>>>>>>>> Il presente messaggio, inclusi gli eventuali allegati, ha natura
>>>>>>>>>> aziendale e potrebbe contenere informazioni confidenziali e/o riservate.
>>>>>>>>>> Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il
>>>>>>>>>> mittente e di cancellarlo.
>>>>>>>>>> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione
>>>>>>>>>> o diffusione non autorizzata del contenuto di questo messaggio o di parte
>>>>>>>>>> di esso.
>>>>>>>>>> Pur essendo state assunte le dovute precauzioni per ridurre al
>>>>>>>>>> minimo il rischio di trasmissione di virus, si suggerisce di effettuare gli
>>>>>>>>>> opportuni controlli sui documenti allegati al presente messaggio. Non si
>>>>>>>>>> assume alcuna responsabilità per eventuali danni o perdite derivanti dalla
>>>>>>>>>> presenza di virus.
>>>>>>>>>>
>>>>>>>>>> Per lo svolgimento delle attività di investimento nel Regno
>>>>>>>>>> Unito, la società è autorizzata da Banca d'Italia ed è soggetta alla
>>>>>>>>>> vigilanza limitata della Financial Conduct Authority ( FCA ) e della
>>>>>>>>>> Prudential Regulation Authority ( PRA ) . Maggiori informazioni in merito
>>>>>>>>>> ai poteri di vigilanza della Financial Conduct Authority ( FCA ) e della
>>>>>>>>>> Prudential Regulation Authority ( PRA ) sono a disposizione previa
>>>>>>>>>> richiesta.
>>>>>>>>>>
>>>>>>>>>> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la
>>>>>>>>>> filiale di Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in
>>>>>>>>>> Inghilterra & Galles sotto No.FC016201, Branch No.BR000036
>>>>>>>>>>
>>>>>>>>>> In osservanza dei requisito imposti dal Internal Revenue Service
>>>>>>>>>> (Agenzia delle Entrate degli Stati Uniti), qualunque discussione relativa a
>>>>>>>>>> temi di natura fiscale contenuta in questo messaggio o nei suoi allegati
>>>>>>>>>> non e’ intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
>>>>>>>>>> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
>>>>>>>>>> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
>>>>>>>>>> sollecitare o raccomandare una operazione finanziaria o altra transazione
>>>>>>>>>> indirizzata ad un altro destinatario.
>>>>>>>>>>
>>>>>>>>>> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
>>>>>>>>>> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
>>>>>>>>>> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
>>>>>>>>>> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
>>>>>>>>>> Irlanda.
>>>>>>>>>>
>>>>>>>>>> ***
>>>>>>>>>>
>>>>>>>>>> ------------------------------
>>>>>>>>>>
>>>>>>>>>> This email (including any attachment) is a corporate message and
>>>>>>>>>> may contain confidential and/or privileged and/or proprietary information.
>>>>>>>>>> If you have received this email in error, please notify the sender
>>>>>>>>>> immediately, do not use or share it and destroy this email. Any
>>>>>>>>>> unauthorised use, copying or disclosure of the material in this email or of
>>>>>>>>>> parts hereof (including reliance thereon) is strictly forbidden.
>>>>>>>>>> We have taken precautions to minimize the risk of transmitting
>>>>>>>>>> software viruses but nevertheless advise you to carry out your own virus
>>>>>>>>>> checks on any attachment of this message. We accept no liability for loss
>>>>>>>>>> or damage caused by software viruses.
>>>>>>>>>>
>>>>>>>>>> For the conduct of investment business in the UK, the Company is
>>>>>>>>>> authorised by Banca d’Italia and subject to limited regulation in the UK by
>>>>>>>>>> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
>>>>>>>>>> Authority ( PRA ). Details about the extent of our regulation by the
>>>>>>>>>> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
>>>>>>>>>> ( PRA ) are available from us on request.
>>>>>>>>>>
>>>>>>>>>> In the UK Intesa Sanpaolo S.p.A. operates through its London
>>>>>>>>>> Branch, located at 90 Queen Street, London EC4N 1SA. Registered in England
>>>>>>>>>> & Wales under No.FC016201, Branch No.BR000036
>>>>>>>>>>
>>>>>>>>>> To comply with requirements imposed by the IRS, we inform you
>>>>>>>>>> that any discussion of U.S. federal tax issues contained herein (including
>>>>>>>>>> any attachments) was not intended or written to be used, and cannot be used
>>>>>>>>>> by you, for the purpose of (i) avoiding penalties under the Internal
>>>>>>>>>> Revenue Code or (ii) promoting, marketing or recommending any transaction
>>>>>>>>>> or matter addressed herein to another party.
>>>>>>>>>>
>>>>>>>>>> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is
>>>>>>>>>> regulated by the Central Bank of Ireland and is a member of the Intesa
>>>>>>>>>> Sanpaolo Group. It is registered in Ireland as company no.125216 – VAT Reg.
>>>>>>>>>> No. IE 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock,
>>>>>>>>>> IFSC, Dublin 1, Ireland.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>> more
>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> <https://implementingquantlib.blogspot.com>
>>> <https://twitter.com/lballabio>
>>>
>>
>>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>