quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] QuantLib in JavaScript

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

No idea of the effort.  You might try asking the JQuantLib people; I
think their port is the most complete.

Luigi

On Tue, Jan 29, 2013 at 6:04 PM, Ismael Ghalimi <is...@st...> wrote:
> Luigi,
>
> Thanks for the answer, much appreciated.
>
> SWIG would be a great start, but for the kind of tools we're considering
> building, a native port will be necessary (we need everything to run in the
> client).
>
> For previous ports to other languages, do you have an idea of how much
> efforts in took (person-months)?
>
> Thanks again for your help.
>
> -Ismael
>
>
> On Tue, Jan 29, 2013 at 8:19 AM, Luigi Ballabio <lui...@gm...>
> wrote:
>>
>> No plans that I know of.  And I don't want to discourage you, but the
>> effort would be substantial (we're talking between 200k and 300k lines
>> of code).  Is there any specific parts of the library you're
>> interested in? This might narrow the scope and make it easier to get
>> something working.
>>
>> Another way might be to wait for JavaScript support in SWIG (last I
>> heard, they were working on it).  If/when that happens, you could use
>> the existing SWIG interfaces to call the library from JavaScript.
>>
>> Luigi
>>
>>
>> On Sun, Jan 20, 2013 at 2:58 PM, Ismael Ghalimi <is...@st...> wrote:
>> > Hello,
>> >
>> > Is there any plans to do a JavaScript port of QuantLib that could run
>> > either
>> > on the client or on the server (using something like Node.js)? I know
>> > quite
>> > a few people who would be interested by this.
>> >
>> > If not, what would be the best way to approach such a project?
>> >
>> > Thanks in advance for your help.
>> >
>> > -Ismael
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> > MVPs and experts. ON SALE this month only -- learn more at:
>> > http://p.sf.net/sfu/learnmore_123012
>> > _______________________________________________
>> > QuantLib-dev mailing list
>> > Qua...@li...
>> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>> >
>
>

Re: [Quantlib-dev] QuantLib in JavaScript

[Ismael G. <is...@st...>]

Luigi,

Thanks for the answer, much appreciated.

SWIG would be a great start, but for the kind of tools we're considering
building, a native port will be necessary (we need everything to run in the
client).

For previous ports to other languages, do you have an idea of how much
efforts in took (person-months)?

Thanks again for your help.

-Ismael

On Tue, Jan 29, 2013 at 8:19 AM, Luigi Ballabio <lui...@gm...>wrote:

> No plans that I know of.  And I don't want to discourage you, but the
> effort would be substantial (we're talking between 200k and 300k lines
> of code).  Is there any specific parts of the library you're
> interested in? This might narrow the scope and make it easier to get
> something working.
>
> Another way might be to wait for JavaScript support in SWIG (last I
> heard, they were working on it).  If/when that happens, you could use
> the existing SWIG interfaces to call the library from JavaScript.
>
> Luigi
>
>
> On Sun, Jan 20, 2013 at 2:58 PM, Ismael Ghalimi <is...@st...> wrote:
> > Hello,
> >
> > Is there any plans to do a JavaScript port of QuantLib that could run
> either
> > on the client or on the server (using something like Node.js)? I know
> quite
> > a few people who would be interested by this.
> >
> > If not, what would be the best way to approach such a project?
> >
> > Thanks in advance for your help.
> >
> > -Ismael
> >
> >
> ------------------------------------------------------------------------------
> > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > MVPs and experts. ON SALE this month only -- learn more at:
> > http://p.sf.net/sfu/learnmore_123012
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
>

Re: [Quantlib-dev] QuantLib in JavaScript

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

No plans that I know of.  And I don't want to discourage you, but the
effort would be substantial (we're talking between 200k and 300k lines
of code).  Is there any specific parts of the library you're
interested in? This might narrow the scope and make it easier to get
something working.

Another way might be to wait for JavaScript support in SWIG (last I
heard, they were working on it).  If/when that happens, you could use
the existing SWIG interfaces to call the library from JavaScript.

Luigi


On Sun, Jan 20, 2013 at 2:58 PM, Ismael Ghalimi <is...@st...> wrote:
> Hello,
>
> Is there any plans to do a JavaScript port of QuantLib that could run either
> on the client or on the server (using something like Node.js)? I know quite
> a few people who would be interested by this.
>
> If not, what would be the best way to approach such a project?
>
> Thanks in advance for your help.
>
> -Ismael
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_123012
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] (no subject)

[Hachemi B. <hac...@gm...>]

http://saprobalt.lv/images/betterlifes.php





======================
Hachemi Benyahia
1/23/2013 6:27:48 PM

Re: [Quantlib-dev] CDS last period

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

yes, that's how I fixed it and then it is consistent with BBG. Thanks a 
lot for cross checking.
Peter

Am 21.01.2013 19:08, schrieb ja...@fr...:
> Hello again,
>
> I cant find documentation on exactly the maturity; I have (see below) on the first coupon date; which yes, as you say, uses Next20thIMM to T+1 (unadjusted) for the next coupon. Since the maturity follows from this date plus tenor then it should be that way.
> Besides, if the jumps you see are timed on dates after the 20-s then that must be it, and the code is wrongly not including the settlement delay.
>
> Changing the end date to include the settlement days might fix it:
> Date endDate = protectionStart_ + tenor_;
> in "void CdsHelper::initializeDates()"
> Passing this date to the schedule creation with the CDS rule will change the maturity in that way.
>
> see sect 5 of 'Standardizing coupon dates':
> http://www.cdsmodel.com/assets/cds-model/docs/Standard%20CDS%20Examples.pdf
> All other docs I know treat the maturity date as given.
>
> Thank you for taking the trouble of checking these things
> Pepe
>
>
> ----- Original Message -----
> From: "Peter Caspers" <pca...@gm...>
> To: ja...@fr...
> Cc: qua...@li..., "Luigi Ballabio" <lui...@gm...>
> Sent: Saturday, 19 January, 2013 7:02:09 PM
> Subject: Re: [Quantlib-dev] CDS last period
>
> This is not forgotten, Pepe ... Right now however, I'd like to ask a
> quick question:
>
> The CdsHelper constructors take the maturity as a period p and compute
> the maturity date of the CDS as the earliest IMM date on or after
> evaluationDate+p (unadjusted). As a result on trade date = 20th
> December, 2012 a 5Y helper will mature on 20th December, 2017. In BBG
> the maturity already rolls on the 20th by 3 month to 20th March, 2018.
> Also I see the "jump" in the CDS quotes we use (from Markit) on the IMM
> dates. From that I assume that the maturity date should be computed
> differently. Someone knows the exact convention ? Is it possibly
> startDate+p (where startDate = evaluationDate + 1d unadjusted usually) ?
> I tried to find that piece of convention in the different documents on
> standard CDS, but failed.
>
> Thanks for any help on this
> Peter
>
> Am 22.11.2012 10:03, schrieb ja...@fr...:
>> Hi Peter,
>> Great, thanks for setting up the code.
>> Also, can you change the constructors to this one pls, used the wrong variable in the previous one.
>> Best regards
>> Pepe
>>
>>
>> ----- Original Message -----
>> From: "Peter Caspers" <pca...@gm...>
>> To: ja...@fr...
>> Cc: qua...@li..., "Luigi Ballabio" <lui...@gm...>
>> Sent: Monday, 19 November, 2012 8:45:55 PM
>> Subject: Re: [Quantlib-dev] CDS last period
>>
>>
>> Hi Pepe,
>>
>> thanks for your feedback. I will try to merge your code in a separate commit, so one can compare the approaches on github and discuss the pros and cons.
>>
>>
>> Just a few comments why I did it how I did it:
>>
>>
>> If you set up a full coupon CDS with upfront (using the second constructor), the real upfront date and amount is taken into account. In case it lies in the future, you will get the accrual rebate npv from the pricing engines as an additional result, that doesn't hurt. In case it is in the past, you will get zero upfront npv and zero accrual rebate npv, which is fine, too.
>>
>> If you set up the same CDS without upfront information (using the first constructor), then the accrual rebate npv is computed as if trading in the position on the evaluation date. Since this is only an additional information, this should not be irritating. Furthermore, for the fair spread result it is very reasonable to take into account the rebate npv because otherwise you can not compare it to traded spreads (this indeed is not achieved in the case above when the upfront date is explicitly given and lies in the past - one could think about making this more consistent ... or just leave that as it is ... ? ).
>>
>> However, there is a bug in my code, because the accrual rebate computation only works if the first period of the CDS is the current one (line 65 in the midpoint engine and similar in the integral engine). I will have to fix that.
>>
>> Concerning the default lookback I explicitly added a comment concerning the protection start parameter, i.e. that it does not refer to the legal protection start but rather the "pricing" protection start. That is indeed important.
>>
>> Concerning the day counter, of course, why not. On the other hand the actual360(inc) is the only example I needed so far. But again, why not.
>>
>>
>> Thanks again and kind regards
>> Peter
>>
>>
>>
>> 2012/11/19 < ja...@fr... >
>>
>>
>> Peter, hi, apologies for the long delay, too many hobbies...
>>
>> The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date.
>> The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).
>>
>> I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
>> Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.
>>
>> Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter
>>
>> Best regards
>> Pepe
>>
>>
>> PS1
>> These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
>> Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:
>>
>> QL mkit QL(no rebate)
>> 6M 0.0013962 0.001391 0.0015124
>> 1Y 0.0024018 0.002396 0.0025179
>> 2Y 0.0066991 0.006683 0.0068754
>> 3Y 0.0128463 0.012795 0.0130785
>> 4Y 0.0227410 0.022554 0.0230541
>> 5Y 0.0357163 0.035221 0.0361139
>> 7Y 0.0610696 0.059787 0.0615613
>> 10Y 0.1036803 0.100268 0.1042708
>> 15Y 0.1578319 0.152918 0.1584299
>> 20Y 0.1948182 0.192336 0.1953589
>>
>>
>> As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
>> This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
>> Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.
>>
>> PS2
>> Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg.
>> Other points for the CDS:
>> -default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
>> -not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).
>>
>>
>>
>>

Re: [Quantlib-dev] CDS last period

[<ja...@fr...>]

Hello again,

I cant find documentation on exactly the maturity; I have (see below) on the first coupon date; which yes, as you say, uses Next20thIMM to T+1 (unadjusted) for the next coupon. Since the maturity follows from this date plus tenor then it should be that way. 
Besides, if the jumps you see are timed on dates after the 20-s then that must be it, and the code is wrongly not including the settlement delay.

Changing the end date to include the settlement days might fix it:
Date endDate = protectionStart_ + tenor_;
in "void CdsHelper::initializeDates()" 
Passing this date to the schedule creation with the CDS rule will change the maturity in that way. 

see sect 5 of 'Standardizing coupon dates':
http://www.cdsmodel.com/assets/cds-model/docs/Standard%20CDS%20Examples.pdf
All other docs I know treat the maturity date as given.

Thank you for taking the trouble of checking these things
Pepe


----- Original Message -----
From: "Peter Caspers" <pca...@gm...>
To: ja...@fr...
Cc: qua...@li..., "Luigi Ballabio" <lui...@gm...>
Sent: Saturday, 19 January, 2013 7:02:09 PM
Subject: Re: [Quantlib-dev] CDS last period

This is not forgotten, Pepe ... Right now however, I'd like to ask a 
quick question:

The CdsHelper constructors take the maturity as a period p and compute 
the maturity date of the CDS as the earliest IMM date on or after 
evaluationDate+p (unadjusted). As a result on trade date = 20th 
December, 2012 a 5Y helper will mature on 20th December, 2017. In BBG 
the maturity already rolls on the 20th by 3 month to 20th March, 2018. 
Also I see the "jump" in the CDS quotes we use (from Markit) on the IMM 
dates. From that I assume that the maturity date should be computed 
differently. Someone knows the exact convention ? Is it possibly 
startDate+p (where startDate = evaluationDate + 1d unadjusted usually) ? 
I tried to find that piece of convention in the different documents on 
standard CDS, but failed.

Thanks for any help on this
Peter

Am 22.11.2012 10:03, schrieb ja...@fr...:
> Hi Peter,
> Great, thanks for setting up the code.
> Also, can you change the constructors to this one pls, used the wrong variable in the previous one.
> Best regards
> Pepe
>
>
> ----- Original Message -----
> From: "Peter Caspers" <pca...@gm...>
> To: ja...@fr...
> Cc: qua...@li..., "Luigi Ballabio" <lui...@gm...>
> Sent: Monday, 19 November, 2012 8:45:55 PM
> Subject: Re: [Quantlib-dev] CDS last period
>
>
> Hi Pepe,
>
> thanks for your feedback. I will try to merge your code in a separate commit, so one can compare the approaches on github and discuss the pros and cons.
>
>
> Just a few comments why I did it how I did it:
>
>
> If you set up a full coupon CDS with upfront (using the second constructor), the real upfront date and amount is taken into account. In case it lies in the future, you will get the accrual rebate npv from the pricing engines as an additional result, that doesn't hurt. In case it is in the past, you will get zero upfront npv and zero accrual rebate npv, which is fine, too.
>
> If you set up the same CDS without upfront information (using the first constructor), then the accrual rebate npv is computed as if trading in the position on the evaluation date. Since this is only an additional information, this should not be irritating. Furthermore, for the fair spread result it is very reasonable to take into account the rebate npv because otherwise you can not compare it to traded spreads (this indeed is not achieved in the case above when the upfront date is explicitly given and lies in the past - one could think about making this more consistent ... or just leave that as it is ... ? ).
>
> However, there is a bug in my code, because the accrual rebate computation only works if the first period of the CDS is the current one (line 65 in the midpoint engine and similar in the integral engine). I will have to fix that.
>
> Concerning the default lookback I explicitly added a comment concerning the protection start parameter, i.e. that it does not refer to the legal protection start but rather the "pricing" protection start. That is indeed important.
>
> Concerning the day counter, of course, why not. On the other hand the actual360(inc) is the only example I needed so far. But again, why not.
>
>
> Thanks again and kind regards
> Peter
>
>
>
> 2012/11/19 < ja...@fr... >
>
>
> Peter, hi, apologies for the long delay, too many hobbies...
>
> The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date.
> The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).
>
> I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
> Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.
>
> Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter
>
> Best regards
> Pepe
>
>
> PS1
> These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
> Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:
>
> QL mkit QL(no rebate)
> 6M 0.0013962 0.001391 0.0015124
> 1Y 0.0024018 0.002396 0.0025179
> 2Y 0.0066991 0.006683 0.0068754
> 3Y 0.0128463 0.012795 0.0130785
> 4Y 0.0227410 0.022554 0.0230541
> 5Y 0.0357163 0.035221 0.0361139
> 7Y 0.0610696 0.059787 0.0615613
> 10Y 0.1036803 0.100268 0.1042708
> 15Y 0.1578319 0.152918 0.1584299
> 20Y 0.1948182 0.192336 0.1953589
>
>
> As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
> This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
> Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.
>
> PS2
> Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg.
> Other points for the CDS:
> -default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
> -not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).
>
>
>
>

Re: [Quantlib-dev] Autoconf in Linux fails

[Grześ A. <gan...@gm...>]

That was it, cheers! Shame that the error message wasn't a bit more clear....

On 21 January 2013 12:30, Luigi Ballabio <lui...@gm...> wrote:
> It looks like you don't have libtool installed (or autoconf can't find
> it).  Can you check that?
>
> Luigi
>
> On Mon, Jan 21, 2013 at 12:15 PM, Grześ Andruszkiewicz
> <gan...@gm...> wrote:
>> I have just downloaded the latest version of the code from svn, but
>> autoconf fails:
>>
>> ga@grzes:~/Dev/QuantLib$ ./autogen.sh
>> configure.ac:60: error: possibly undefined macro: AC_PROG_LIBTOOL
>>       If this token and others are legitimate, please use m4_pattern_allow.
>>       See the Autoconf documentation.
>> autoreconf: /usr/bin/autoconf failed with exit status: 1
>>
>> Run the command ./configure --help for information on options
>> that can change the behavior of the library.
>>
>> Any ideas?
>>
>> Regards,
>> Grzegorz
>>
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. SALE $99.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122412
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Autoconf in Linux fails

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

It looks like you don't have libtool installed (or autoconf can't find
it).  Can you check that?

Luigi

On Mon, Jan 21, 2013 at 12:15 PM, Grześ Andruszkiewicz
<gan...@gm...> wrote:
> I have just downloaded the latest version of the code from svn, but
> autoconf fails:
>
> ga@grzes:~/Dev/QuantLib$ ./autogen.sh
> configure.ac:60: error: possibly undefined macro: AC_PROG_LIBTOOL
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
>
> Run the command ./configure --help for information on options
> that can change the behavior of the library.
>
> Any ideas?
>
> Regards,
> Grzegorz
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Autoconf in Linux fails

[Grześ A. <gan...@gm...>]

I have just downloaded the latest version of the code from svn, but
autoconf fails:

ga@grzes:~/Dev/QuantLib$ ./autogen.sh
configure.ac:60: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

Run the command ./configure --help for information on options
that can change the behavior of the library.

Any ideas?

Regards,
Grzegorz

[Quantlib-dev] QuantLib in JavaScript

[Ismael G. <is...@st...>]

Hello,

Is there any plans to do a JavaScript port of QuantLib that could run
either on the client or on the server (using something like Node.js)? I
know quite a few people who would be interested by this.

If not, what would be the best way to approach such a project?

Thanks in advance for your help.

-Ismael

Re: [Quantlib-dev] CDS last period

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

This is not forgotten, Pepe ... Right now however, I'd like to ask a 
quick question:

The CdsHelper constructors take the maturity as a period p and compute 
the maturity date of the CDS as the earliest IMM date on or after 
evaluationDate+p (unadjusted). As a result on trade date = 20th 
December, 2012 a 5Y helper will mature on 20th December, 2017. In BBG 
the maturity already rolls on the 20th by 3 month to 20th March, 2018. 
Also I see the "jump" in the CDS quotes we use (from Markit) on the IMM 
dates. From that I assume that the maturity date should be computed 
differently. Someone knows the exact convention ? Is it possibly 
startDate+p (where startDate = evaluationDate + 1d unadjusted usually) ? 
I tried to find that piece of convention in the different documents on 
standard CDS, but failed.

Thanks for any help on this
Peter

Am 22.11.2012 10:03, schrieb ja...@fr...:
> Hi Peter,
> Great, thanks for setting up the code.
> Also, can you change the constructors to this one pls, used the wrong variable in the previous one.
> Best regards
> Pepe
>
>
> ----- Original Message -----
> From: "Peter Caspers" <pca...@gm...>
> To: ja...@fr...
> Cc: qua...@li..., "Luigi Ballabio" <lui...@gm...>
> Sent: Monday, 19 November, 2012 8:45:55 PM
> Subject: Re: [Quantlib-dev] CDS last period
>
>
> Hi Pepe,
>
> thanks for your feedback. I will try to merge your code in a separate commit, so one can compare the approaches on github and discuss the pros and cons.
>
>
> Just a few comments why I did it how I did it:
>
>
> If you set up a full coupon CDS with upfront (using the second constructor), the real upfront date and amount is taken into account. In case it lies in the future, you will get the accrual rebate npv from the pricing engines as an additional result, that doesn't hurt. In case it is in the past, you will get zero upfront npv and zero accrual rebate npv, which is fine, too.
>
> If you set up the same CDS without upfront information (using the first constructor), then the accrual rebate npv is computed as if trading in the position on the evaluation date. Since this is only an additional information, this should not be irritating. Furthermore, for the fair spread result it is very reasonable to take into account the rebate npv because otherwise you can not compare it to traded spreads (this indeed is not achieved in the case above when the upfront date is explicitly given and lies in the past - one could think about making this more consistent ... or just leave that as it is ... ? ).
>
> However, there is a bug in my code, because the accrual rebate computation only works if the first period of the CDS is the current one (line 65 in the midpoint engine and similar in the integral engine). I will have to fix that.
>
> Concerning the default lookback I explicitly added a comment concerning the protection start parameter, i.e. that it does not refer to the legal protection start but rather the "pricing" protection start. That is indeed important.
>
> Concerning the day counter, of course, why not. On the other hand the actual360(inc) is the only example I needed so far. But again, why not.
>
>
> Thanks again and kind regards
> Peter
>
>
>
> 2012/11/19 < ja...@fr... >
>
>
> Peter, hi, apologies for the long delay, too many hobbies...
>
> The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date.
> The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).
>
> I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
> Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.
>
> Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter
>
> Best regards
> Pepe
>
>
> PS1
> These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
> Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:
>
> QL mkit QL(no rebate)
> 6M 0.0013962 0.001391 0.0015124
> 1Y 0.0024018 0.002396 0.0025179
> 2Y 0.0066991 0.006683 0.0068754
> 3Y 0.0128463 0.012795 0.0130785
> 4Y 0.0227410 0.022554 0.0230541
> 5Y 0.0357163 0.035221 0.0361139
> 7Y 0.0610696 0.059787 0.0615613
> 10Y 0.1036803 0.100268 0.1042708
> 15Y 0.1578319 0.152918 0.1584299
> 20Y 0.1948182 0.192336 0.1953589
>
>
> As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
> This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
> Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.
>
> PS2
> Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg.
> Other points for the CDS:
> -default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
> -not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).
>
>
>
>

Re: [Quantlib-dev] Interest in fixing MSVC Level 4 warnings

[Mike S. <ma...@gm...>]

Hi Luigi,

Thanks for your reply.

A quick upper bound on the amount of warnings that would need to be fixed
is 1800. This is high because VS reports the same warning multiple times if
the code in question is in headers, and also because boost has some level 4
warnings in uBLAS headers.

I'm more than willing to use my spare time to generate patches that would
fix all the warnings, especially if they appear in headers so people who
include quantlib headers can do so without needing to resort to workarounds
if they want to bump up the warning level. When I submit the patches, I'll
describe which warning the patch fixes and we can go from there.

Look for patches over the next week or two.

Mike


On Thu, Jan 10, 2013 at 9:31 AM, Luigi Ballabio <lui...@gm...>wrote:

> Hi Mike,
>     given that we won't be able to go entirely warning-free (due to
> QL_FAIL etc.) I wouldn't want you to invest too much time on this.
> But if you want to have a look at the warnings and check if there's
> anything that should be fixed, by all means go ahead.  A count might
> indeed be useful in order to assess if the thing is worth pursuing.
>
> Later,
>     Luigi
>
>
>
> On Sun, Jan 6, 2013 at 11:35 PM, Mike Sharpe <ma...@gm...> wrote:
> > Hi all,
> >
> > First, I'd like to start off by saying thanks for your hard work on
> > quantlib! This is my first post to a quantlib mailing list. I've recently
> > developed an interest in mathematical finance and discovered quantlib
> over
> > the holidays, which has only piqued my interest more.
> >
> > As I'm still new to the codebase and most of the techniques that are
> used in
> > the code, I'd like to give back in some other way and one of the ways I
> can
> > do that is by looking into fixing some of the level 4 warnings for the
> > Microsoft compilers. Because the warnings could appear anywhere and I
> don't
> > want to cause any difficulties for other work, I wanted to check here to
> see
> > if there was any interest in seeing these warnings fixed.
> >
> > I'm not necessarily proposing fixing all of the warnings that I've seen
> in
> > the code (QL_FAIL triggers C4127 "conditional expression is constant"
> > because of the do { } while(false) macro guard, for example), but I do
> think
> > it'd a good idea to look through the list and fix some of them. If a
> count
> > of warnings would help, I can follow up with that soon.
> >
> > Mike
> >
> >
> >
> ------------------------------------------------------------------------------
> > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > MVPs and experts. ON SALE this month only -- learn more at:
> > http://p.sf.net/sfu/learnmore_123012
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
>

Re: [Quantlib-dev] Interest in fixing MSVC Level 4 warnings

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

Hi Mike,
    given that we won't be able to go entirely warning-free (due to
QL_FAIL etc.) I wouldn't want you to invest too much time on this.
But if you want to have a look at the warnings and check if there's
anything that should be fixed, by all means go ahead.  A count might
indeed be useful in order to assess if the thing is worth pursuing.

Later,
    Luigi



On Sun, Jan 6, 2013 at 11:35 PM, Mike Sharpe <ma...@gm...> wrote:
> Hi all,
>
> First, I'd like to start off by saying thanks for your hard work on
> quantlib! This is my first post to a quantlib mailing list. I've recently
> developed an interest in mathematical finance and discovered quantlib over
> the holidays, which has only piqued my interest more.
>
> As I'm still new to the codebase and most of the techniques that are used in
> the code, I'd like to give back in some other way and one of the ways I can
> do that is by looking into fixing some of the level 4 warnings for the
> Microsoft compilers. Because the warnings could appear anywhere and I don't
> want to cause any difficulties for other work, I wanted to check here to see
> if there was any interest in seeing these warnings fixed.
>
> I'm not necessarily proposing fixing all of the warnings that I've seen in
> the code (QL_FAIL triggers C4127 "conditional expression is constant"
> because of the do { } while(false) macro guard, for example), but I do think
> it'd a good idea to look through the list and fix some of them. If a count
> of warnings would help, I can follow up with that soon.
>
> Mike
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_123012
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Fwd: Inflation Index Interpolation / yoy volatility structure

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

Hi,

just as an update to the point below: The second way of interpolating seems
to be the correct one. I do not have a suggestion for a fix in ql however
(as I said below, everything under the assumption that my understanding of
the intended usage of the classes is correct).

I have a second question on inflation in ql concerning the yoy volatility
structure. I am trying to use a KInterpolatedYoyOptionletVolatilitySurface.
Retrieving a volatility for say maturity = 1y and a strike k the following
happens:

1 YoYOptionletVolatilitySurface::volatility( today + 1y , k ) is called.
The observation lag (3m) is subtracted from the maturity date and the time
to reference date is computed giving (apprx.) t  = 0.75. Then
volatilityImpl(t,k) is called =>

2 KInterpolatedYoYOptionletVolatilitySurface::volatilityImpl(t,k)
recomputes a physical date d from t=0.75 giving something like d =
today+9m and then retrieves a volatility slice for this d from the
yoyOptionletStripper, which is in my case an
InterpolatedYoYOptionletStripper =>

3 InterpolatedYoYOptionletStripper::slice(d) computes for each relevant
strike k a volatility by invoking volatility(d,k) on the respective
volatility curve. The latter is a PiecewiseYoYOptionletVolatilityCurve.
This triggers executiion of

4 YoYOptionletVolatilitySurface::volatility( today +9m , k ) which we
already had above. Again the observation lag (3m) is subtracted and we
arrive at today + 6m and (apprx.) t = 0.5, which is used as input to

5 InterpolatedYoYOptionletVolatilityCurve::volatilityImpl(t) which finally
returns the volatility for t=0.5.

It should be t=0.75 in my opinion however. I do not have a general fix, but
only a workaround changing the call in 2 into

slice_ = yoyOptionletStripper_->slice(d + this->observationLag() );

which should work if the default observation lag is used in 1.

Is my observation correct and would you consider the workaround more or
less reasonable ?

Thanks a lot for any input
Peter

---------- Forwarded message ----------
From: Peter Caspers <pca...@gm...>
Date: 2012/12/17
Subject: Inflation Index Interpolation
To: qua...@li...


Hi,

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 )

Which computation is the correct one, i.e. what is the market convention
that is actually applied to deals ? Maybe I am using the QL classes not as
intended ?

Thanks a lot
Peter

Re: [Quantlib-dev] European option validation

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

Here's the transcript of my Python session.

Python 2.7.3 (default, Sep 26 2012, 21:53:58)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from QuantLib import *
>>>
>>> today = Date.todaysDate()
>>>
>>> spot = SimpleQuote(100.0)
>>> q = SimpleQuote(0.0)
>>> r = SimpleQuote(0.1)
>>> vol = SimpleQuote(0.5)
>>>
>>> dc = Actual360()
>>> rTS = FlatForward(today, QuoteHandle(r), dc)
>>> qTS = FlatForward(today, QuoteHandle(q), dc)
>>> volTS = BlackConstantVol(today, NullCalendar(), QuoteHandle(vol), dc)
>>>
>>> process = BlackScholesMertonProcess(
...     QuoteHandle(spot),
...     YieldTermStructureHandle(qTS),
...     YieldTermStructureHandle(rTS),
...     BlackVolTermStructureHandle(volTS))
>>>
>>> exerciseDate = today+90
>>> exercise = EuropeanExercise(exerciseDate)
>>>
>>> payoff = PlainVanillaPayoff(Option.Call, 97.0)
>>>
>>> option = EuropeanOption(payoff, exercise)
>>> engine = AnalyticEuropeanEngine(process)
>>> option.setPricingEngine(engine)
>>>
>>> option.NPV()
12.612666351689272
>>>

On Wed, Jan 9, 2013 at 6:13 AM, ray 176 <ra...@gm...> wrote:
> Can you post me your code.
>
> I still can't get it to give  a valid results
> DayCounter is Actual360 and today date is used for yield term structure as
> per below.
>
>
> QuantLib::DayCounter dc = QuantLib::Actual360();
> QuantLib::Date today = QuantLib::Date::todaysDate();
>
> boost::shared_ptr<QuantLib::YieldTermStructure> rTS = flatRate(today, rRate,
> dc);
>
> boost::shared_ptr<QuantLib::YieldTermStructure>
>     flatRate(const QuantLib::Date& today,
>              const boost::shared_ptr<QuantLib::Quote>& forward,
>              const QuantLib::DayCounter& dc) {
>         return boost::shared_ptr<QuantLib::YieldTermStructure>(
>                           new QuantLib::FlatForward(today,
> QuantLib::Handle<QuantLib::Quote>(forward), dc));
>     }
>
>
>
> On 9 January 2013 00:47, Luigi Ballabio <lui...@gm...> wrote:
>>
>> tried the thing in QuantLib via Pyt
>
>
>

Re: [Quantlib-dev] European option validation

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

I've tried the thing in QuantLib via Python and I get 12.6127.  How
did you implement timeToDays?  With the Actual/360 day counter you're
using, the exercise date should be today's date plus 90 days to get
the correct time.  What date do you get?

Luigi


On Tue, Jan 8, 2013 at 9:12 PM, ray 176 <ra...@gm...> wrote:
> I am new to Quantlib code base, but I have a basic question,
>
> I tried to calculate a basic European option using the below but having
> difficulty to validate the results against my spreadsheet
>
> [Call] = blsprice(100, 97, 0.1, 0.25, 0.5) returns a Call  price of $12.61
> via spreadsheet
>
>
> but, via Quantlib I am getting value $10.77
>
>
> can you advice,
>
> I hope you don't mind that I posted the code below,
>
> QuantLib::Option::Type type(QuantLib::Option::Call);
> QuantLib::Real stock = 100;
> QuantLib::Real strike = 97;
> QuantLib::Real time = 0.25;
> QuantLib::Spread dividendYield = 0.00;
> QuantLib::Rate riskFreeRate = 0.1;
> QuantLib::Volatility volatility = 0.5;
>
> QuantLib::DayCounter dc = QuantLib::Actual360();
> QuantLib::Date today = QuantLib::Date::todaysDate();
>
> boost::shared_ptr<QuantLib::SimpleQuote> spot(new
> QuantLib::SimpleQuote(0.0));
> boost::shared_ptr<QuantLib::SimpleQuote> qRate(new
> QuantLib::SimpleQuote(0.0));
> boost::shared_ptr<QuantLib::YieldTermStructure> qTS = flatRate(today, qRate,
> dc);
> boost::shared_ptr<QuantLib::SimpleQuote> rRate(new
> QuantLib::SimpleQuote(0.0));
> boost::shared_ptr<QuantLib::YieldTermStructure> rTS = flatRate(today, rRate,
> dc);
> boost::shared_ptr<QuantLib::SimpleQuote> vol(new
> QuantLib::SimpleQuote(0.0));
> boost::shared_ptr<QuantLib::BlackVolTermStructure> volTS = flatVol(today,
> vol, dc);
>
> boost::shared_ptr<QuantLib::StrikedTypePayoff> payoff1(new
>            QuantLib::PlainVanillaPayoff(type, strike));
>            QuantLib::Date exDate = today + timeToDays(time);
>
> boost::shared_ptr<QuantLib::Exercise> exercise(new
> QuantLib::EuropeanExercise(exDate));
>
> spot ->setValue(strike);
>  qRate->setValue(dividendYield);
>  rRate->setValue(riskFreeRate);
> vol  ->setValue(volatility);
>
>  boost::shared_ptr<QuantLib::BlackScholesMertonProcess> stochProcess(new
>
> QuantLib::BlackScholesMertonProcess(QuantLib::Handle<QuantLib::Quote>(spot),
>
> QuantLib::Handle<QuantLib::YieldTermStructure>(qTS),
>
> QuantLib::Handle<QuantLib::YieldTermStructure>(rTS),
>
> QuantLib::Handle<QuantLib::BlackVolTermStructure>(volTS)));
>         boost::shared_ptr<QuantLib::PricingEngine> engine(
>                                     new
> QuantLib::AnalyticEuropeanEngine(stochProcess));
>
>  QuantLib::EuropeanOption option(payoff1, exercise);
>  option.setPricingEngine(engine);
>
>  QuantLib::Real calculated = option.NPV();
>
> .............................
>
> boost::shared_ptr<QuantLib::YieldTermStructure>
>     flatRate(const QuantLib::Date& today,
>              const boost::shared_ptr<QuantLib::Quote>& forward,
>              const QuantLib::DayCounter& dc) {
>         return boost::shared_ptr<QuantLib::YieldTermStructure>(
>                           new QuantLib::FlatForward(today,
> QuantLib::Handle<QuantLib::Quote>(forward), dc));
>     }
>
> Regards
> Ray
>
>
> ------------------------------------------------------------------------------
> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
> and more. Get SQL Server skills now (including 2012) with LearnDevNow -
> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only - learn more at:
> http://p.sf.net/sfu/learnmore_122512
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] European option validation

[ray 1. <ra...@gm...>]

I am new to Quantlib code base, but I have a basic question,

I tried to calculate a basic European option using the below but having
difficulty to validate the results against my spreadsheet

[Call] = *blsprice*(100, 97, 0.1, 0.25, 0.5) returns a C*all  *price of *$12.61
via* spreadsheet


but, via *Quantlib *I am getting value *$10.77*

can you advice,

I hope you don't mind that I posted the code below,

QuantLib::Option::Type type(QuantLib::Option::Call);
QuantLib::Real stock = 100;
QuantLib::Real strike = 97;
QuantLib::Real time = 0.25;
QuantLib::Spread dividendYield = 0.00;
QuantLib::Rate riskFreeRate = 0.1;
QuantLib::Volatility volatility = 0.5;

QuantLib::DayCounter dc = QuantLib::Actual360();
QuantLib::Date today = QuantLib::Date::todaysDate();

boost::shared_ptr<QuantLib::SimpleQuote> spot(new
QuantLib::SimpleQuote(0.0));
boost::shared_ptr<QuantLib::SimpleQuote> qRate(new
QuantLib::SimpleQuote(0.0));
boost::shared_ptr<QuantLib::YieldTermStructure> qTS = flatRate(today,
qRate, dc);
boost::shared_ptr<QuantLib::SimpleQuote> rRate(new
QuantLib::SimpleQuote(0.0));
boost::shared_ptr<QuantLib::YieldTermStructure> rTS = flatRate(today,
rRate, dc);
boost::shared_ptr<QuantLib::SimpleQuote> vol(new
QuantLib::SimpleQuote(0.0));
boost::shared_ptr<QuantLib::BlackVolTermStructure> volTS = flatVol(today,
vol, dc);

boost::shared_ptr<QuantLib::StrikedTypePayoff> payoff1(new
           QuantLib::PlainVanillaPayoff(type, strike));
           QuantLib::Date exDate = today + timeToDays(time);

boost::shared_ptr<QuantLib::Exercise> exercise(new
QuantLib::EuropeanExercise(exDate));

spot ->setValue(strike);
 qRate->setValue(dividendYield);
 rRate->setValue(riskFreeRate);
vol  ->setValue(volatility);

 boost::shared_ptr<QuantLib::BlackScholesMertonProcess> stochProcess(new

QuantLib::BlackScholesMertonProcess(QuantLib::Handle<QuantLib::Quote>(spot),

QuantLib::Handle<QuantLib::YieldTermStructure>(qTS),

QuantLib::Handle<QuantLib::YieldTermStructure>(rTS),

QuantLib::Handle<QuantLib::BlackVolTermStructure>(volTS)));
        boost::shared_ptr<QuantLib::PricingEngine> engine(
                                    new
QuantLib::AnalyticEuropeanEngine(stochProcess));

 QuantLib::EuropeanOption option(payoff1, exercise);
 option.setPricingEngine(engine);

 *QuantLib::Real calculated = option.NPV();*
*
*
*.............................*
*
*
boost::shared_ptr<QuantLib::YieldTermStructure>
    flatRate(const QuantLib::Date& today,
             const boost::shared_ptr<QuantLib::Quote>& forward,
             const QuantLib::DayCounter& dc) {
        return boost::shared_ptr<QuantLib::YieldTermStructure>(
                          new QuantLib::FlatForward(today,
QuantLib::Handle<QuantLib::Quote>(forward), dc));
    }

Regards
Ray

Re: [Quantlib-dev] CAT Bond valuation

[Grześ A. <gan...@gm...>]

Hi,

I think I can see why (2) doesn't really work :(. Why are most of the
methods on the Bond class non-virtual? And why is the pricer in this class
used only for npv and settlementPrice, and not for all the other things
(i.e. clean and dirty prices)---that seem rather similar?

Cheers,
Grzegorz


On 4 January 2013 16:33, Grześ Andruszkiewicz <gan...@gm...> wrote:

> Hi,
>
> Coming back to the risky bonds, I am still trying to figure out what would
> be the best design. Obviously I know a few not-so-elegant ways to just make
> it work, so this is not what I am after.
>
> The first and maybe main question is what do CashFlow::amount() and
> Coupon::nominal() represent. By looking at Luigi's QL book, and the Bond
> class implementation, I would say that amount() is the expected amount of
> the coupon (this is implied by the implementation of NPV calculation for
> bonds), and nominal() is the risk-free nominal value (implied by the
> calculation of the capital repayments in the Bond class again).
>
> All this makes sense for risk-free coupons, but not really for the risky
> ones. To make the current NPV calculation work, we should assume that
> amount() returns the expected amount as I said, but this breaks the yield
> calculation. The yield in the risky case is usually used to compare the
> market-implied riskiness of two different bonds, because obviously
> comparing just the market price is not enough. Hence one should use the
> risk-free amount() for this calculation. As for the nominal(), one could
> safely use the risk-free value, but it might be inconsistent with amount()
> for notes where the notional changes (decreases) as e.g. defaults or
> catastrophes happen.
>
> Also I am not sure about what things like the clean and dirty price mean
> for a risky bond.
>
> A few immediate ideas:
> (1) Add a new virtual method to CashFlow for the riskfreeAmount() (a
> better name anyone?) with default implementation to return the amount().
> Then we could change the Bond class to use the new value for appropriate
> quantities (yield() for example). This seems the cleanest way to do it, but
> it is a fundamental change in some core classes.
>
> (2) Create a base class for risky bonds, that inherits from the Bond
> class. Inside keep two copies of the the coupon list (or dynamically
> calculate one of these from the other)---one with expected amount(), and
> one with risk-free amount(). Override appropriate methods (yield() again
> for example) accordingly. This introduces obvious data and partly code
> duplication, but leaves the core classes unchanged.
>
> (3) Just go the same way as RiskyBond and subclasses (from
> experimental/credit) went---forget about the Bond subclass and use the
> amount() for risk-free values.  This is maybe the most pragmatic approach,
> but then some bonds are not a Bond... And we get loads of code duplication.
>
> I would be grateful for all comments and suggestions.
>
> Cheers,
> Grzegorz
>
> PS. What is the process for committing changes to the code base? Should I
> just commit using my Sourceforge account, or do I need extra permission?
> Are the changes reviewed by anyone?
>
>
> On 19 December 2012 15:18, Grześ Andruszkiewicz <gan...@gm...>wrote:
>
>> Hi Luigi,
>>
>> After spending way too much time on reading termsheets and talking to
>> people I am finally ready to write some code :)
>>
>> I managed to find a class that seems rather similar to what I am trying
>> to achieve: RiskyFloatingBond in experimental/credit. It seems to create
>> coupons as if there was no credit (CAT in my case) risk. The risk is only
>> taken into account while calculating (1) NPV (2) expectedCashflows(). In my
>> case I would still need to run Monte Carlo simulation in these two places.
>> If I ignore (2) for now, then I hopefully will be able to use the standard
>> approach for MC.
>>
>> Have you seen this class before? It was written by Roland Lichters in
>> 2008. Unfortunately a quick search didn't find any associated tests. Is it
>> actually used?
>>
>> This kind of approach gives me an easy way to calculate the yield of the
>> bond (disregarding the risks), which is often used by practitioners to
>> compare different bonds, combined with expected loss.
>>
>> Kind regards,
>> Grzegorz
>>
>>
>>
>> On 15 October 2012 15:11, Luigi Ballabio <lui...@gm...>wrote:
>>
>>> Grześ,
>>>     apologies for the delay.  As I was telling you, there's currently
>>> no example for coupon amounts calculated in a MC simulation.  If you
>>> want to go that route, you'll have to:
>>>
>>> - write the simulation itself.  There are a number of engines you can
>>> use as an example, so you should be covered with regards to creating a
>>> path generator, a path pricer and the several other pieces you'll
>>> need.  The notable difference in your case is that you'll want to
>>> return a number of cashflow amounts from the simulation, not a single
>>> number.  To do that, you'll have to use the second template argument
>>> of PathPricer: I think all the existing engines use its default (that
>>> is, Real for a single number) but you'll have to specify that you'll
>>> return a vector<Real> or something like it.
>>>
>>> - link the coupons to the simulation.  Again, there's no code doing
>>> this yet.  What I'd do is to create a new class inheriting from
>>> CashFlow and taking a pointer to the MC simulation.  When their
>>> amount() method is called, instances of this class should ask the
>>> simulation for the corresponding result.  In turn, this means that a)
>>> they should know which cashflow they are (the 1st, the 2nd...) among
>>> those calculated by the simulation and b) the simulation must
>>> implement some kind of caching to avoid being run several times as the
>>> Bond class asks its cashflows for their amounts.
>>>
>>> The above should keep you busy for a while :)
>>> Let me know when you need further advice...
>>>
>>> Later,
>>>     Luigi
>>>
>>>
>>> On Thu, Sep 13, 2012 at 5:56 PM, Grześ Andruszkiewicz
>>> <gan...@gm...> wrote:
>>> > Hi Luigi,
>>> >
>>> > Thanks for a long reply. We were just trying to follow your advice and
>>> > extend the Bond class, but we found a few potential issues:
>>> > 1. The Coupon class seems to have a fixed notional, whereas in our
>>> > case the notional could become smaller as a result of CAT events (that
>>> > deplete the notional of the CAT bond)
>>> > 2. The Bond class seems to assume that we can always calculate the
>>> > coupon amounts (independently for every coupon). I am not sure that
>>> > this is possible for CAT bonds (i.e. that coupons will be correlated
>>> > as a result of depleting the notional, catastrophe seasonality, etc.),
>>> > at least I am not comfortable to assume it at this point.
>>> > 3. Moreover, we wanted to have a way to price these instruments using
>>> > Monte Carlo techniques, i.e. use the underlying CAT engine to generate
>>> > random scenarios of events, given the events calculate the NPV of the
>>> > bond for every case, and average the results at the end. It is not
>>> > clear to how to achieve this with the Bond class...
>>> >
>>> > Are there other types of instruments in QuantLib with similar
>>> > characteristics, that we could use as examples?
>>> >
>>> > Kind regards,
>>> > Grzegorz
>>> >
>>> > On 31 August 2012 15:45, Luigi Ballabio <lui...@gm...>
>>> wrote:
>>> >> Hi Grześ,
>>> >>     I'd start by doing the least possible coding :)   Let me
>>> elaborate.
>>> >>
>>> >> In the architecture of QuantLib, you'll need an instrument class
>>> >> (describing the contract) and an engine class (doing the actual
>>> >> pricing).  You can ask your resident expert (hi, Lorenzo) or read
>>> >> chapter 2 of <https://sites.google.com/site/luigiballabio/>.
>>> >>
>>> >> As for the instrument, it is very tempting to inherit it from the
>>> >> existing Bond class (it's a bond, after all).  In the short term,
>>> >> that's what I advice.
>>> >>
>>> >> In the long term, I'm a bit worried that functions taking a Bond
>>> >> instance (such as, for instance, BondFunctions::yield, which
>>> >> calculates the bond yield) would take a CAT bond and do their job like
>>> >> they do for each other bond; that is, extract its coupons and perform
>>> >> the yield calculations disregarding the catastrophe feature.  This
>>> >> might or might not be what you want.
>>> >>
>>> >> In the _very_ short term, though, I'd just use the existing fixed-rate
>>> >> and floating-rate bond classes and use those until you see that the
>>> >> thing works.  It will save you some development time which I'd rather
>>> >> use for getting to a first working version.
>>> >>
>>> >> Which brings me to the second part, i.e., the engine class.  It will
>>> >> probably need to contain a discount curve and your loss distribution.
>>> >> Any idea about how you'll use them?
>>> >>
>>> >> Later,
>>> >>     Luigi
>>> >>
>>> >>
>>> >> On Fri, Aug 24, 2012 at 5:08 PM, Grześ Andruszkiewicz
>>> >> <gan...@gm...> wrote:
>>> >>> Hi Luigi,
>>> >>>
>>> >>> Thanks for your reply! I personally can't claim to be proficient with
>>> >>> Quantlib, but my colleague Lorenzo (CC'd) did the 3-day course in
>>> >>> London with yourself, so he must be an expert ;)
>>> >>>
>>> >>> I don't think there are any established models for CAT bonds. We are
>>> >>> actually part of one of these academic-industry projects and one of
>>> >>> the goals is to come up with a model and implementation for these
>>> >>> instruments. We thought it might be a good idea to make this
>>> >>> implementation part of quantlib, to make it potentially useful for
>>> >>> someone.
>>> >>>
>>> >>> To start with, I would be grateful for any hints on where to start,
>>> >>> e.g. what would be your first guess on the place in the class
>>> >>> hierarchy where this instrument would fit?
>>>
>>
>>
>

[Quantlib-dev] [ quantlib-Bugs-3599805 ] Schedule::until works incorrectly with non-full schedules

[SourceForge.net <no...@so...>]

Bugs item #3599805, was opened at 2013-01-07 07:16
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3599805&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sergey Khorev ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Schedule::until works incorrectly with non-full schedules

Initial Comment:
Schedule::until calls result.isRegular_.pop_back() that produces unspecified behaviour when isRegular_ is empty. Particularly, it is empty for schedules created with Schedule::Schedule(const std::vector<Date>& dates, const Calendar& calendar, BusinessDayConvention convention)).
I suggest you either restrict the method to complete interfaces or do pop_back only for complete interfaces.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3599805&group_id=12740

[Quantlib-dev] Interest in fixing MSVC Level 4 warnings

[Mike S. <ma...@gm...>]

Hi all,

First, I'd like to start off by saying thanks for your hard work on
quantlib! This is my first post to a quantlib mailing list. I've recently
developed an interest in mathematical finance and discovered quantlib over
the holidays, which has only piqued my interest more.

As I'm still new to the codebase and most of the techniques that are used
in the code, I'd like to give back in some other way and one of the ways I
can do that is by looking into fixing some of the level 4 warnings for the
Microsoft compilers. Because the warnings could appear anywhere and I don't
want to cause any difficulties for other work, I wanted to check here to
see if there was any interest in seeing these warnings fixed.

I'm not necessarily proposing fixing all of the warnings that I've seen in
the code (QL_FAIL triggers C4127 "conditional expression is constant"
because of the do { } while(false) macro guard, for example), but I do
think it'd a good idea to look through the list and fix some of them. If a
count of warnings would help, I can follow up with that soon.

Mike

Re: [Quantlib-dev] CAT Bond valuation

[Grześ A. <gan...@gm...>]

Hi,

Coming back to the risky bonds, I am still trying to figure out what would
be the best design. Obviously I know a few not-so-elegant ways to just make
it work, so this is not what I am after.

The first and maybe main question is what do CashFlow::amount() and
Coupon::nominal() represent. By looking at Luigi's QL book, and the Bond
class implementation, I would say that amount() is the expected amount of
the coupon (this is implied by the implementation of NPV calculation for
bonds), and nominal() is the risk-free nominal value (implied by the
calculation of the capital repayments in the Bond class again).

All this makes sense for risk-free coupons, but not really for the risky
ones. To make the current NPV calculation work, we should assume that
amount() returns the expected amount as I said, but this breaks the yield
calculation. The yield in the risky case is usually used to compare the
market-implied riskiness of two different bonds, because obviously
comparing just the market price is not enough. Hence one should use the
risk-free amount() for this calculation. As for the nominal(), one could
safely use the risk-free value, but it might be inconsistent with amount()
for notes where the notional changes (decreases) as e.g. defaults or
catastrophes happen.

Also I am not sure about what things like the clean and dirty price mean
for a risky bond.

A few immediate ideas:
(1) Add a new virtual method to CashFlow for the riskfreeAmount() (a better
name anyone?) with default implementation to return the amount(). Then we
could change the Bond class to use the new value for appropriate quantities
(yield() for example). This seems the cleanest way to do it, but it is a
fundamental change in some core classes.

(2) Create a base class for risky bonds, that inherits from the Bond class.
Inside keep two copies of the the coupon list (or dynamically calculate one
of these from the other)---one with expected amount(), and one with
risk-free amount(). Override appropriate methods (yield() again for
example) accordingly. This introduces obvious data and partly code
duplication, but leaves the core classes unchanged.

(3) Just go the same way as RiskyBond and subclasses (from
experimental/credit) went---forget about the Bond subclass and use the
amount() for risk-free values.  This is maybe the most pragmatic approach,
but then some bonds are not a Bond... And we get loads of code duplication.

I would be grateful for all comments and suggestions.

Cheers,
Grzegorz

PS. What is the process for committing changes to the code base? Should I
just commit using my Sourceforge account, or do I need extra permission?
Are the changes reviewed by anyone?


On 19 December 2012 15:18, Grześ Andruszkiewicz <gan...@gm...> wrote:

> Hi Luigi,
>
> After spending way too much time on reading termsheets and talking to
> people I am finally ready to write some code :)
>
> I managed to find a class that seems rather similar to what I am trying to
> achieve: RiskyFloatingBond in experimental/credit. It seems to create
> coupons as if there was no credit (CAT in my case) risk. The risk is only
> taken into account while calculating (1) NPV (2) expectedCashflows(). In my
> case I would still need to run Monte Carlo simulation in these two places.
> If I ignore (2) for now, then I hopefully will be able to use the standard
> approach for MC.
>
> Have you seen this class before? It was written by Roland Lichters in
> 2008. Unfortunately a quick search didn't find any associated tests. Is it
> actually used?
>
> This kind of approach gives me an easy way to calculate the yield of the
> bond (disregarding the risks), which is often used by practitioners to
> compare different bonds, combined with expected loss.
>
> Kind regards,
> Grzegorz
>
>
>
> On 15 October 2012 15:11, Luigi Ballabio <lui...@gm...> wrote:
>
>> Grześ,
>>     apologies for the delay.  As I was telling you, there's currently
>> no example for coupon amounts calculated in a MC simulation.  If you
>> want to go that route, you'll have to:
>>
>> - write the simulation itself.  There are a number of engines you can
>> use as an example, so you should be covered with regards to creating a
>> path generator, a path pricer and the several other pieces you'll
>> need.  The notable difference in your case is that you'll want to
>> return a number of cashflow amounts from the simulation, not a single
>> number.  To do that, you'll have to use the second template argument
>> of PathPricer: I think all the existing engines use its default (that
>> is, Real for a single number) but you'll have to specify that you'll
>> return a vector<Real> or something like it.
>>
>> - link the coupons to the simulation.  Again, there's no code doing
>> this yet.  What I'd do is to create a new class inheriting from
>> CashFlow and taking a pointer to the MC simulation.  When their
>> amount() method is called, instances of this class should ask the
>> simulation for the corresponding result.  In turn, this means that a)
>> they should know which cashflow they are (the 1st, the 2nd...) among
>> those calculated by the simulation and b) the simulation must
>> implement some kind of caching to avoid being run several times as the
>> Bond class asks its cashflows for their amounts.
>>
>> The above should keep you busy for a while :)
>> Let me know when you need further advice...
>>
>> Later,
>>     Luigi
>>
>>
>> On Thu, Sep 13, 2012 at 5:56 PM, Grześ Andruszkiewicz
>> <gan...@gm...> wrote:
>> > Hi Luigi,
>> >
>> > Thanks for a long reply. We were just trying to follow your advice and
>> > extend the Bond class, but we found a few potential issues:
>> > 1. The Coupon class seems to have a fixed notional, whereas in our
>> > case the notional could become smaller as a result of CAT events (that
>> > deplete the notional of the CAT bond)
>> > 2. The Bond class seems to assume that we can always calculate the
>> > coupon amounts (independently for every coupon). I am not sure that
>> > this is possible for CAT bonds (i.e. that coupons will be correlated
>> > as a result of depleting the notional, catastrophe seasonality, etc.),
>> > at least I am not comfortable to assume it at this point.
>> > 3. Moreover, we wanted to have a way to price these instruments using
>> > Monte Carlo techniques, i.e. use the underlying CAT engine to generate
>> > random scenarios of events, given the events calculate the NPV of the
>> > bond for every case, and average the results at the end. It is not
>> > clear to how to achieve this with the Bond class...
>> >
>> > Are there other types of instruments in QuantLib with similar
>> > characteristics, that we could use as examples?
>> >
>> > Kind regards,
>> > Grzegorz
>> >
>> > On 31 August 2012 15:45, Luigi Ballabio <lui...@gm...>
>> wrote:
>> >> Hi Grześ,
>> >>     I'd start by doing the least possible coding :)   Let me elaborate.
>> >>
>> >> In the architecture of QuantLib, you'll need an instrument class
>> >> (describing the contract) and an engine class (doing the actual
>> >> pricing).  You can ask your resident expert (hi, Lorenzo) or read
>> >> chapter 2 of <https://sites.google.com/site/luigiballabio/>.
>> >>
>> >> As for the instrument, it is very tempting to inherit it from the
>> >> existing Bond class (it's a bond, after all).  In the short term,
>> >> that's what I advice.
>> >>
>> >> In the long term, I'm a bit worried that functions taking a Bond
>> >> instance (such as, for instance, BondFunctions::yield, which
>> >> calculates the bond yield) would take a CAT bond and do their job like
>> >> they do for each other bond; that is, extract its coupons and perform
>> >> the yield calculations disregarding the catastrophe feature.  This
>> >> might or might not be what you want.
>> >>
>> >> In the _very_ short term, though, I'd just use the existing fixed-rate
>> >> and floating-rate bond classes and use those until you see that the
>> >> thing works.  It will save you some development time which I'd rather
>> >> use for getting to a first working version.
>> >>
>> >> Which brings me to the second part, i.e., the engine class.  It will
>> >> probably need to contain a discount curve and your loss distribution.
>> >> Any idea about how you'll use them?
>> >>
>> >> Later,
>> >>     Luigi
>> >>
>> >>
>> >> On Fri, Aug 24, 2012 at 5:08 PM, Grześ Andruszkiewicz
>> >> <gan...@gm...> wrote:
>> >>> Hi Luigi,
>> >>>
>> >>> Thanks for your reply! I personally can't claim to be proficient with
>> >>> Quantlib, but my colleague Lorenzo (CC'd) did the 3-day course in
>> >>> London with yourself, so he must be an expert ;)
>> >>>
>> >>> I don't think there are any established models for CAT bonds. We are
>> >>> actually part of one of these academic-industry projects and one of
>> >>> the goals is to come up with a model and implementation for these
>> >>> instruments. We thought it might be a good idea to make this
>> >>> implementation part of quantlib, to make it potentially useful for
>> >>> someone.
>> >>>
>> >>> To start with, I would be grateful for any hints on where to start,
>> >>> e.g. what would be your first guess on the place in the class
>> >>> hierarchy where this instrument would fit?
>>
>
>

[Quantlib-dev] [ quantlib-Patches-3599230 ] Fixed a forward looking bias issue in Garch11::calculate

[SourceForge.net <no...@so...>]

Patches item #3599230, was opened at 2013-01-02 09:02
Message generated for change (Tracker Item Submitted) made by shlagbaum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3599230&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Slava Mazur (shlagbaum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fixed a forward looking bias issue in Garch11::calculate 

Initial Comment:
Garch11::calculate re-implemented so that the current volatility estimate depends on a prior return and a prior volatility estimator. A corresponding test case is added to the test suite.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3599230&group_id=12740

[Quantlib-dev] [ quantlib-Patches-3599229 ] Precision issue in calculation of autocovariances fixed

[SourceForge.net <no...@so...>]

Patches item #3599229, was opened at 2013-01-02 08:22
Message generated for change (Tracker Item Submitted) made by shlagbaum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3599229&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Slava Mazur (shlagbaum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Precision issue in calculation of autocovariances fixed

Initial Comment:
On Win32 platform when input data vector is sufficiently long there is an issue with final calculation of autocovariances. The proposed patch fixes it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3599229&group_id=12740

[Quantlib-dev] [ quantlib-Bugs-3598835 ] RQuantLib EuropeanOption with Expiry = 0

[SourceForge.net <no...@so...>]

Bugs item #3598835, was opened at 2012-12-28 23:59
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3598835&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: RQuantLib EuropeanOption with Expiry = 0

Initial Comment:
Hi,

This is an error I have come across in the R version of QuantLib (RQuantLib).  I emailed Dirk Eddelbuettel and he tells me it is an issue he cannot fix and I should submit a bug report.  The error is this:

I have been using your RQuantLib package to price options and I noticed a bug when pricing an option with time to expiry = 0.  An option with spot price at 80, strike price of 100 and time to expiry of 1 day correctly returns a price of 20:

> EuropeanOption("put", 80, 100, 0, 0, 1/252, .3)$value
[1] 20

But if the option now has 0 time to expiry, it returns 0:

> EuropeanOption("put", 80, 100, 0, 0, 0/252, .3)$value
[1] 0

I think it should return the intrinsic value of 20 instead of 0.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3598835&group_id=12740

Re: [Quantlib-dev] MF1F NTL Support

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

thanks, Klaus. I tried to make the 80 bit double run on msvc, that 
wasn't fun (and did not work / I gave up at some point). gcc quad 
precision sounds good, is it fast ? NTL seems attractive in that it runs 
on many platforms without customization and with (to be tested) 
identical results, and you can push the precision even higher (actually 
I can run a (rather extreme) calibration test case which fails with 113 
bit mantissa, but runs fine with 150 bit). MPFR seems to be another 
possible solution, also with support in boost as a user defined float 
type, however I did not try.
Peter

Am 27.12.2012 17:57, schrieb Klaus Spanderen:
>
> Hi Peter,
>
> I've used gcc's type __float128 to calculate high precision reference 
> prices for some stoch vol models but I'd to change multiple parts of 
> QuantLib to get it working. Just changing the typedef for Real in 
> types.hpp was not enough.
>
> regards
>
> Klaus
>
> On Thursday, December 27, 2012 02:26:55 PM Peter Caspers wrote:
>
> > Hi,
>
> >
>
> > I added high precision floating point support to the markov functional
>
> > model making use of NTL (and supplementary boost functions). This allows
>
> > for a better numeraire fit to long term (like say 50y) constant maturity
>
> > calibration sets. NTL is only used for some intermediate results, the
>
> > interface does not change. While there are other, faster yet dirty ways
>
> > to stabilize the calibration (like the AdjustYts option) this is
>
> > probably a good way to produce benchmark results and check convergence
>
> > in the numerical parameters. I updated the code on my github as well as
>
> > the doc on ssrn giving an example.
>
> >
>
> > More generally, is high precision arithmetic a topic anyone came across
>
> > in some context he or she wants to share ?
>
> >
>
> > Peter
>
> >
>
> > 
> ----------------------------------------------------------------------------
>
> > -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, 
> CSS, MVC,
>
> > Windows 8 Apps, JavaScript and much more. Keep your skills current with
>
> > LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and
>
> > experts. ON SALE this month only -- learn more at:
>
> > http://p.sf.net/sfu/learnmore_122712
>
> > _______________________________________________
>
> > QuantLib-dev mailing list
>
> > Qua...@li...
>
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>