quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] [ quantlib-Bugs-1904433 ] complie bug or misunderstood?

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

Bugs item #1904433, was opened at 2008-02-28 20:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1904433&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: complie bug or misunderstood?

Initial Comment:
everytime I compile the example in the quontlib, the following message I've seen. Is this misunderstood or complie bug or something different?

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

cannot find -lQuoantlib-mgw-0_9_0
Id returned 1 exit status
[Build Error] [bin/FRA-mwg.exe] Error 1

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

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

Re: [Quantlib-dev] Handle & type casting

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

On Thu, 2008-02-28 at 13:49 +0000, Simon Ibbotson wrote:
> If the new object is of type T3 (not inherited from type T2, but is
> inherited from type T1), then the dynamic cast to type T2 fails and the
> pointer is set to NULL.

I see. I still fail to see a use case, but no doubt you have one.
Ok, send me the implementation if you have it---I'll have a look at it.

Luigi


-- 

All parts should go together without forcing. You must remember that 
the parts you are reassembling were disassembled by you. Therefore, if 
you can't get them together again, there must be a reason. By all 
means, do not use a hammer. 
-- IBM maintenance manual, 1925 

Re: [Quantlib-dev] Handle & type casting

[Simon I. <Sim...@st...>]

If the new object is of type T3 (not inherited from type T2, but is
inherited from type T1), then the dynamic cast to type T2 fails and the
pointer is set to NULL.
The accessor functions in Handle already check for this scenario (NULL
pointer) and throw exceptions in this case: so unless a function tries
to use the dereferenced NULL pointer, there is no problem. It would be
as if the typecast occurred at the time the Handle<T2> was dereferenced
and would be "as if" the original Handle<T1> was passed, dereferenced
and typecast.

Simon


-----Original Message-----
From: Luigi Ballabio [mailto:lui...@gm...] 
Sent: 28 February 2008 13:31
To: Simon Ibbotson
Cc: qua...@li...
Subject: RE: [Quantlib-dev] Handle & type casting

On Thu, 2008-02-28 at 13:06 +0000, Simon Ibbotson wrote:
> If you have a handle to any Observable -  Handle<T1> but you need a
> handle to a derived type Handle<T2>, I can find no way of currently
> doing this without going through the process of 
> a) Getting the underlying boost::shared_ptr<T1>
> b) Using boost::dynamic_pointer_cast to get a boost::shared_ptr<T2>
> c) Creating a Handle<T2> using the new shared_ptr<T2>.
> 
> Unfortunately, this means that if the original Handle<T1> points to a
> new object, the Handle<T2> does not point to this updated object.

Ok. Let's say you keep the Handle<T2> connected to the original Handle.
What happens if the new object is not a T2?

Luigi


-- 

Better to have an approximate answer to the right question than a 
precise answer to the wrong question. 
-- John Tukey as quoted by John Chambers 

Re: [Quantlib-dev] Handle & type casting

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

On Thu, 2008-02-28 at 13:06 +0000, Simon Ibbotson wrote:
> If you have a handle to any Observable -  Handle<T1> but you need a
> handle to a derived type Handle<T2>, I can find no way of currently
> doing this without going through the process of 
> a) Getting the underlying boost::shared_ptr<T1>
> b) Using boost::dynamic_pointer_cast to get a boost::shared_ptr<T2>
> c) Creating a Handle<T2> using the new shared_ptr<T2>.
> 
> Unfortunately, this means that if the original Handle<T1> points to a
> new object, the Handle<T2> does not point to this updated object.

Ok. Let's say you keep the Handle<T2> connected to the original Handle.
What happens if the new object is not a T2?

Luigi


-- 

Better to have an approximate answer to the right question than a 
precise answer to the wrong question. 
-- John Tukey as quoted by John Chambers 

Re: [Quantlib-dev] Handle & type casting

[Simon I. <Sim...@st...>]

If you have a handle to any Observable -  Handle<T1> but you need a
handle to a derived type Handle<T2>, I can find no way of currently
doing this without going through the process of 
a) Getting the underlying boost::shared_ptr<T1>
b) Using boost::dynamic_pointer_cast to get a boost::shared_ptr<T2>
c) Creating a Handle<T2> using the new shared_ptr<T2>.

Unfortunately, this means that if the original Handle<T1> points to a
new object, the Handle<T2> does not point to this updated object.

Implementing this part of the functionality is easy... using the
Observer/Observable pattern to create a helper class. However, cleaning
up after the original Handle::Link object has been deleted requires that
the helper class is notified upon deletion of the Handle::Link object
(and can delete itself). 

If this has already been discussed and a solution reached, let me know.

Hope this makes sense,

Simon
 

-----Original Message-----
From: Luigi Ballabio [mailto:lui...@gm...] 
Sent: 28 February 2008 12:50
To: Simon Ibbotson
Cc: qua...@li...
Subject: Re: [Quantlib-dev] Handle & type casting

On Thu, 2008-02-28 at 12:43 +0000, Simon Ibbotson wrote:
> Would anyone mind if I changed the Handle::Link class to allow dynamic
> typecasting of Handles / RelinkableHandles? It would mean adding a
> shared pointer for a helper class that would be notified when the
> Handle::Link class was deleted (only if a typecast had occurred).

Simon,
	I'm afraid I'm not getting what you mean. Do you have an
example?

Luigi


-- 

Debugging is twice as hard as writing the code in the first place. 
Therefore, if you write the code as cleverly as possible, you are, 
by definition, not smart enough to debug it. 
-- Brian W. Kernighan 

Re: [Quantlib-dev] Handle & type casting

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

On Thu, 2008-02-28 at 12:43 +0000, Simon Ibbotson wrote:
> Would anyone mind if I changed the Handle::Link class to allow dynamic
> typecasting of Handles / RelinkableHandles? It would mean adding a
> shared pointer for a helper class that would be notified when the
> Handle::Link class was deleted (only if a typecast had occurred).

Simon,
	I'm afraid I'm not getting what you mean. Do you have an example?

Luigi


-- 

Debugging is twice as hard as writing the code in the first place. 
Therefore, if you write the code as cleverly as possible, you are, 
by definition, not smart enough to debug it. 
-- Brian W. Kernighan 

[Quantlib-dev] Handle & type casting

[Simon I. <Sim...@st...>]

Hi guys,

 

Would anyone mind if I changed the Handle::Link class to allow dynamic
typecasting of Handles / RelinkableHandles? It would mean adding a
shared pointer for a helper class that would be notified when the
Handle::Link class was deleted (only if a typecast had occurred).

 

The performance overhead should be negligible and would allow
typecasting of the underlying pointer while maintaining the link to the
underlying object.

 

Cheers,

 

Simon

 

 

Simon Ibbotson

Head of Quantitative Analytics

Capital Markets

Straumur

 

Re: [Quantlib-dev] Visual Studio warning C4819

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

On Mon, February 25, 2008 4:53 pm, Luigi Ballabio wrote:
> On Sun, 2008-02-24 at 23:38 +0000, Eric Ehlers wrote:
>> At present, non-ASCII characters (>128, aka extended ASCII)
>> appear in various comments and literal strings in the source code
>>
>> Some possible courses of action:
>> 1) Restrict ourselves to the ASCII character set
>> 2) Convert all source code files to Unicode format
>> 3) Disable C4819
>> 4) Do nothing and as today leave affected parties to work around the
>> problem by implementing one of the above as a local hack
>
> Hmm. (3) seems strangely appealing...

Done.

Regards,
Eric

Re: [Quantlib-dev] Bond redemption, face value and amortising bonds

[FORNAROLA C. <chi...@ba...>]

Hi Simon,

Bloomberg does help if you don't consider ASW function, but SWPM
function.
Using SWPM you can construct your bond leg and your floating leg,
inputing the amotization schedule for each leg as given in the bond
prospectus.
I think this can help for a check.

Chiara

>-----Original Message-----
>From: qua...@li... [mailto:quantlib-dev-
>bo...@li...] On Behalf Of Simon Ibbotson
>Sent: 25 February 2008 19:45
>To: Ferdinando Ametrano
>Cc: qua...@li...
>Subject: Re: [Quantlib-dev] Bond redemption, face value and amortising
>bonds
>
>Hmmm, interesting point. I'd guess that an asset swap on an amortising
>bond swaps only the interest payments, not the notional repayments.
>Bloomberg doesn't help either - it simply ignores the sinking fund in
>ASW. Can anyone confirm this?
>
>I will - of course - make sure it passes the current QuantLib tests.
>
>Simon
>
>-----Original Message-----
>From: fer...@gm...
>[mailto:fer...@gm...] On Behalf Of Ferdinando Ametrano
>Sent: 25 February 2008 18:19
>To: Simon Ibbotson
>Subject: Re: [Quantlib-dev] Bond redemption, face value and amortising
>bonds
>
>Hi Simon
>
>your proposal makes sense to me, my only warning being to pay
>attention to (not mess up) asset swap. I'm not sure what is the asset
>swap mechanics for amortizing bonds
>
>You might find that in some place cashflows are assumed to be sorted,
>in other place they aren't. E.g. the redemption is assumed to be the
>last cashflow.
>Would be nice to settle this issue
>
>ciao -- Nando
>
>On Mon, Feb 25, 2008 at 6:43 PM, Simon Ibbotson
><Sim...@st...> wrote:
>>
>>
>>
>>
>> Toyin (and all others interested),
>>
>>
>>
>> I want to implement amortising bonds within QuantLib. I think this
>should be
>> part of the base Bond class, as all the functions in the base class
>use the
>> face amount and the redemption in calculations of yield. Before I do,
>can I
>> clarify the usage of certain terms?
>>
>>
>>
>> To clarify:
>>
>> The face amount is the listed bond notional - used with the rate to
>> calculate the cashflow for a given period. The redemption(s) are
>usually
>> termed the notional repayment schedule and the (redemption value)/100
>*
>> (initial face amount) is the associated payment.
>>
>> The bond quoting convention for the dirty price is (Settlement
>Payment) =
>> (Current Bond Notional) * (Dirty Price) / 100.
>>
>> The clean price is (Clean Price) = (Dirty Price) - Accrued, where the
>> Accrued is based upon a notional of 100.
>>
>> Anyone disagree?
>>
>>
>>
>> Note that the redemption value on any given date usually (but not
>always)
>> equals the change in the bond notional.
>>
>>
>>
>> This would mean making the redemption and face value into vectors (in
>the
>> constructor, similar to the rate) and the faceAmount() function into
>> faceAmount(const Date&). Any objections, comments?
>>
>>
>>
>> Cheers,
>>
>> Simon
>>
>>
>>
>>
>>
>> Simon Ibbotson
>>
>> Head of Quantitative Analytics
>>
>> Capital Markets
>>
>> Straumur
>>
>>
>>
>-----------------------------------------------------------------------
-
>-
>>  This SF.net email is sponsored by: Microsoft
>>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>>  QuantLib-dev mailing list
>>  Qua...@li...
>>  https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>
>-----------------------------------------------------------------------
--
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2008.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>QuantLib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Bond redemption, face value and amortising bonds

[Simon I. <Sim...@st...>]

For the asset swap, this would mean having an amortizing floating leg:
which would usually mean that the floating leg has a compatible schedule
(with matching notional paydown dates). That could be very tricky to
implement: I think the best resolution would be to verify that the
floating leg schedule has a coupon payment date within 2 days of the
notional payment date (and thus can be said to have a constant notional
for the coupon).

For the AssetSwap, we would need a Bond accessor function for the
redemption dates and an accessor function for the notional changes.

Simon


-----Original Message-----
From: fer...@gm...
[mailto:fer...@gm...] On Behalf Of Ferdinando Ametrano
Sent: 26 February 2008 09:27
To: Simon Ibbotson
Cc: qua...@li...
Subject: Re: [Quantlib-dev] Bond redemption, face value and amortising
bonds

On Mon, Feb 25, 2008 at 7:44 PM, Simon Ibbotson
<Sim...@st...> wrote:
>  I'd guess that an asset swap on an amortising
>  bond swaps only the interest payments, not the notional repayments.
I agree for par asset swap, in the sense that exchanging the notional
repayments would result in zero net flow, since the repayments should
be identical on the floating leg. This is in accord with what happen
with the final traditional redemption, when only the difference to par
is exchanged. The guideline here is that the bond price as evaluated
discounting all its cashflows on the yield curve should be identical
to the asset swap price when the floating leg spread is set to zero.

When it comes to market asset swap, things changes slightly and might
require further attention.

On a related issue: I haven't taught about it carefully but it might
be worth to have different accessors for interest payments and
redemptions, besides the old all-inclusive cashflows accessor

ciao -- Nando

Re: [Quantlib-dev] Bond redemption, face value and amortising bonds

[Ferdinando A. <na...@am...>]

On Mon, Feb 25, 2008 at 7:44 PM, Simon Ibbotson
<Sim...@st...> wrote:
>  I'd guess that an asset swap on an amortising
>  bond swaps only the interest payments, not the notional repayments.
I agree for par asset swap, in the sense that exchanging the notional
repayments would result in zero net flow, since the repayments should
be identical on the floating leg. This is in accord with what happen
with the final traditional redemption, when only the difference to par
is exchanged. The guideline here is that the bond price as evaluated
discounting all its cashflows on the yield curve should be identical
to the asset swap price when the floating leg spread is set to zero.

When it comes to market asset swap, things changes slightly and might
require further attention.

On a related issue: I haven't taught about it carefully but it might
be worth to have different accessors for interest payments and
redemptions, besides the old all-inclusive cashflows accessor

ciao -- Nando

Re: [Quantlib-dev] Feller Constraint for Heston calibration

[Klaus S. <kl...@sp...>]

commit...done;-)

On Monday 25 February 2008 10:56:39 Ferdinando Ametrano wrote:
> On Fri, Feb 22, 2008 at 9:44 PM, Klaus Spanderen <kl...@sp...> wrote:
> >  the Feller constraint is already in QuantLib .. well hidden as an inner
> > class of the class HestonModel and called
> > HestonModel::VolatilityConstraint (okay, the name wasn't that clever;-)
>
> why don't you rename it? ;-)
>
> ciao -- Nando
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev



-- 
Klaus Spanderen
Ludwig Erhard Str. 12
48734 Reken (Germany)
EMail: kl...@NO... (remove NOSPAM from the address)

Re: [Quantlib-dev] Bond redemption, face value and amortising bonds

[Simon I. <Sim...@st...>]

Hmmm, interesting point. I'd guess that an asset swap on an amortising
bond swaps only the interest payments, not the notional repayments.
Bloomberg doesn't help either - it simply ignores the sinking fund in
ASW. Can anyone confirm this?

I will - of course - make sure it passes the current QuantLib tests.

Simon

-----Original Message-----
From: fer...@gm...
[mailto:fer...@gm...] On Behalf Of Ferdinando Ametrano
Sent: 25 February 2008 18:19
To: Simon Ibbotson
Subject: Re: [Quantlib-dev] Bond redemption, face value and amortising
bonds

Hi Simon

your proposal makes sense to me, my only warning being to pay
attention to (not mess up) asset swap. I'm not sure what is the asset
swap mechanics for amortizing bonds

You might find that in some place cashflows are assumed to be sorted,
in other place they aren't. E.g. the redemption is assumed to be the
last cashflow.
Would be nice to settle this issue

ciao -- Nando

On Mon, Feb 25, 2008 at 6:43 PM, Simon Ibbotson
<Sim...@st...> wrote:
>
>
>
>
> Toyin (and all others interested),
>
>
>
> I want to implement amortising bonds within QuantLib. I think this
should be
> part of the base Bond class, as all the functions in the base class
use the
> face amount and the redemption in calculations of yield. Before I do,
can I
> clarify the usage of certain terms?
>
>
>
> To clarify:
>
> The face amount is the listed bond notional - used with the rate to
> calculate the cashflow for a given period. The redemption(s) are
usually
> termed the notional repayment schedule and the (redemption value)/100
*
> (initial face amount) is the associated payment.
>
> The bond quoting convention for the dirty price is (Settlement
Payment) =
> (Current Bond Notional) * (Dirty Price) / 100.
>
> The clean price is (Clean Price) = (Dirty Price) - Accrued, where the
> Accrued is based upon a notional of 100.
>
> Anyone disagree?
>
>
>
> Note that the redemption value on any given date usually (but not
always)
> equals the change in the bond notional.
>
>
>
> This would mean making the redemption and face value into vectors (in
the
> constructor, similar to the rate) and the faceAmount() function into
> faceAmount(const Date&). Any objections, comments?
>
>
>
> Cheers,
>
> Simon
>
>
>
>
>
> Simon Ibbotson
>
> Head of Quantitative Analytics
>
> Capital Markets
>
> Straumur
>
>
>
------------------------------------------------------------------------
-
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
>  QuantLib-dev mailing list
>  Qua...@li...
>  https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

[Quantlib-dev] Bond redemption, face value and amortising bonds

[Simon I. <Sim...@st...>]

Toyin (and all others interested),

 

I want to implement amortising bonds within QuantLib. I think this
should be part of the base Bond class, as all the functions in the base
class use the face amount and the redemption in calculations of yield.
Before I do, can I clarify the usage of certain terms?

 

To clarify:

The face amount is the listed bond notional - used with the rate to
calculate the cashflow for a given period. The redemption(s) are usually
termed the notional repayment schedule and the (redemption value)/100 *
(initial face amount) is the associated payment.

The bond quoting convention for the dirty price is (Settlement Payment)
= (Current Bond Notional) * (Dirty Price) / 100.

The clean price is (Clean Price) = (Dirty Price) - Accrued, where the
Accrued is based upon a notional of 100.

Anyone disagree?

 

Note that the redemption value on any given date usually (but not
always) equals the change in the bond notional.

 

This would mean making the redemption and face value into vectors (in
the constructor, similar to the rate) and the faceAmount() function into
faceAmount(const Date&). Any objections, comments?

 

Cheers,

Simon

 

 

Simon Ibbotson

Head of Quantitative Analytics

Capital Markets

Straumur

 

Re: [Quantlib-dev] Curve interpolation

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

Hi Simon,

On Mon, 2008-02-25 at 16:51 +0000, Simon Ibbotson wrote:
> On a separate note, do you know who is currently working on the curve
> interface? I'd like to contribute a different Bootstrap to the library
> (for localized approximations of global interpolations) but want to
> check the current state of development: what interface(s) the Bootstrap
> class needs to implement.

Nando has been working on it for the last few days (Nando, is it done?)
Then I'll want to make a few minor changes myself. I'll send you a line
when I'm done.

Later,
	Luigi


-- 

Innovation is hard to schedule. 
-- Dan Fylstra 

Re: [Quantlib-dev] what are the most computation intensive algorithms in Quantlib

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

Hi G.E.,

On Sun, 2008-02-03 at 11:27 +0530, G E Naganna wrote:
> what are the most computation intensive algorithms in Quantlib?
> I want to accelerate algorithms which takes lot of time.

That would probably be the Monte Carlo framework, but it's probably more
a matter of design than of code optimization.

> what is best book to understand finance mathematics?

My personal pick would be Mark Joshi's (and not because he's a
contributor...) but I'm sure others can suggest other books. What is
your background?

Luigi


-- 

Barker's Proof: 
Proofreading is more effective after publication. 

Re: [Quantlib-dev] Visual Studio warning C4819

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

On Sun, 2008-02-24 at 23:38 +0000, Eric Ehlers wrote:
> At present, non-ASCII characters (>128, aka extended ASCII)
> appear in various comments and literal strings in the source code
> 
> Some possible courses of action:
> 1) Restrict ourselves to the ASCII character set
> 2) Convert all source code files to Unicode format
> 3) Disable C4819
> 4) Do nothing and as today leave affected parties to work around the
> problem by implementing one of the above as a local hack

Hmm. (3) seems strangely appealing...

Luigi


-- 

There is no such thing as public opinion. There is only published
opinion. 
-- Winston Churchill 

Re: [Quantlib-dev] Curve interpolation

[Simon I. <Sim...@st...>]

Hi Luigi,

Thanks for the reply: I did eventually find the document mentioned below
but found no way of replying to my own message on Sourceforge (so that I
could say that I'd found the answer).

On a separate note, do you know who is currently working on the curve
interface? I'd like to contribute a different Bootstrap to the library
(for localized approximations of global interpolations) but want to
check the current state of development: what interface(s) the Bootstrap
class needs to implement.

All the best,

Simon

-----Original Message-----
From: qua...@li...
[mailto:qua...@li...] On Behalf Of Luigi
Ballabio
Sent: 25 February 2008 16:44
To: Simon Ibbotson
Cc: qua...@li...
Subject: Re: [Quantlib-dev] Curve interpolation

Hi Simon,

On Fri, 2008-02-15 at 09:57 +0000, Simon Ibbotson wrote:
> I'm a little confused about the QuantLib curve classes ForwardCurve,
> DiscountCurve and ZeroCurve. 
>  
> In the three class definitions we have the member variable
> mutable Interpolation interpolation_; 
> 
> [...] often the object allocated is an object of a derived class e.g.
> CubicSpline.
> 
> Now, I know pointers and references can be polymorphic. But in this
> case a derived class is being allocated to a base class instance... 
> 
> I know most information required for interpolation is contained within
> the Interpolation::impl_ object but I'm wondering whether:
> 
> a) my C++ knowledge is lacking and the base class instance (e.g.
> ForwardCurve::interpolation_) can be polymorphic somehow. Or...

No, you're right---it's not polymorphic. As you surmised, the
polymorphic behavior is delegated to the inner Interpolation::impl_
object, which is copied by pointer and continues to have the correct
type even when the containing Interpolation object is sliced.


> b) why a pointer to the derived Interpolation object isn't returned by
> the factory class (e.g. Cubic::interpolate) - to obviate the need for
> a polymorphic Interpolation::impl_ member variable?

I confess that it's a while since we coded it, so I might be wrong. But
I think it's the same reason why we coded, say, the Calendar and
DayCounter classes in the same way---to avoid writing the shared_ptr
part. See <http://quantlib.org/quep/quep001.html> for the full rationale
(the code samples are outdated, but the reasoning still holds.)

Luigi


-- 

Olmstead's Law: 
After all is said and done, a hell of a lot more is said 
than done. 



------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Variance Gamma models

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

Hi Adrian,

On Mon, 2008-02-18 at 20:35 +0000, Adrian O' Neill wrote:
> I was wondering if anyone had done any work in integrating Variance Gamma
> models (such as CGMY) in to QuantLib yet, or if it was on the roadmap?

No, nothing yet.

> If not, I understand I'd have to solve numerically using FFT - I know there was
> a FFT engine going in to QL, but I wasn't sure if that was complete yet?

Last I knew, there were a few stub files in the repository (you'll see
them in ql/math if you check out the trunk from Subversion) but the
implementation was not complete.  Joe, do you have any comment on this?

Later,
	Luigi


-- 

The wisdom of the wise and the experience of the ages are perpetuated 
by quotations. 
-- Benjamin Disraeli 

Re: [Quantlib-dev] problems with localVolImpl

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

Hi Paulius,

On Mon, 2008-02-18 at 13:01 +0000, Paulius Jakubenas wrote:
> When getting a local volatility from implied volatility via
> localVolImpl() (for example using a Monte Carlo simulation),
> from time to time one is given a negative local volatility (which
> generates an exception - as expected). 
> The problem often arises  from small numerical inaccuracies which get 
> augmented when numerically calculating the second derivative.
> 
> Has anyone  already encountered and resolved the problem? 
> If not, I'd like to contribute a fix to the library. This would mean
> changing the interface s.t. the 
> LocalVolTermStructure::localVolImpl method returns a discretized vol -
> not an instantaneous vol. 

I'm not sure that I'm following. What would the discretized vol be?

Later,
	Luigi


-- 

Don't let school get in the way of your education. 
-- Mark Twain 

Re: [Quantlib-dev] Road to 1.0

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

On Mon, 2008-02-18 at 10:00 +0800, Max wrote:
> I just have one addition:
> - modify the interfaces of finite difference pricing engines (like
> FDEuropeanEngine class) so that users can specifiy different solver
> (Explicit, Implicit or Crank-Nicolson) and different asset price
> range. Currently the solver is fixed to Crank-Nicolson.
> 
> Does this change make sense to you? and any advice?

Hmm, you're right. I'll have to look into it...

Luigi


-- 

Things should be made as simple as possible, but no simpler. 
-- Albert Einstein 

Re: [Quantlib-dev] Curve interpolation

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

Hi Simon,

On Fri, 2008-02-15 at 09:57 +0000, Simon Ibbotson wrote:
> I'm a little confused about the QuantLib curve classes ForwardCurve,
> DiscountCurve and ZeroCurve. 
>  
> In the three class definitions we have the member variable
> mutable Interpolation interpolation_; 
> 
> [...] often the object allocated is an object of a derived class e.g.
> CubicSpline.
> 
> Now, I know pointers and references can be polymorphic. But in this
> case a derived class is being allocated to a base class instance... 
> 
> I know most information required for interpolation is contained within
> the Interpolation::impl_ object but I'm wondering whether:
> 
> a) my C++ knowledge is lacking and the base class instance (e.g.
> ForwardCurve::interpolation_) can be polymorphic somehow. Or...

No, you're right---it's not polymorphic. As you surmised, the
polymorphic behavior is delegated to the inner Interpolation::impl_
object, which is copied by pointer and continues to have the correct
type even when the containing Interpolation object is sliced.


> b) why a pointer to the derived Interpolation object isn't returned by
> the factory class (e.g. Cubic::interpolate) - to obviate the need for
> a polymorphic Interpolation::impl_ member variable?

I confess that it's a while since we coded it, so I might be wrong. But
I think it's the same reason why we coded, say, the Calendar and
DayCounter classes in the same way---to avoid writing the shared_ptr
part. See <http://quantlib.org/quep/quep001.html> for the full rationale
(the code samples are outdated, but the reasoning still holds.)

Luigi


-- 

Olmstead's Law: 
After all is said and done, a hell of a lot more is said 
than done. 

Re: [Quantlib-dev] Feller Constraint for Heston calibration

[Ferdinando A. <na...@am...>]

On Fri, Feb 22, 2008 at 9:44 PM, Klaus Spanderen <kl...@sp...> wrote:
>  the Feller constraint is already in QuantLib .. well hidden as an inner class
>  of the class HestonModel and called HestonModel::VolatilityConstraint (okay,
>  the name wasn't that clever;-)

why don't you rename it? ;-)

ciao -- Nando

Re: [Quantlib-dev] Visual Studio warning C4819

[Ram M. <RMe...@ol...>]

Unicode, more standard and allows us to use more extended characters...


Ram


-----Original Message-----
From: qua...@li... on behalf of Eric Ehlers
Sent: Sun 2/24/2008 6:38 PM
To: qua...@li...
Subject: [Quantlib-dev] Visual Studio warning C4819
 
Hi All,

Would anyone object to a policy of using only ASCII characters in source
code files?  At present, non-ASCII characters (>128, aka extended ASCII)
appear in various comments and literal strings in the source code, for
example line 54 of file ql/currency.hpp:

        //! fraction symbol, e.g, "¢"

If the machine on which you're reading this message uses the same mapping
as mine for non-ASCII characters, then that line ends with a cent symbol
in double quotes.

On other machines, that character (162) is interpreted as some other
symbol, or is not recognized at all and is rendered as a question mark. 
When the code is compiled on such a machine, Visual Studio emits the
following:

    warning C4819: The file contains a character that cannot be
    represented in the current code page. Save the file in Unicode
    format to prevent data loss.

Some possible courses of action:
1) Restrict ourselves to the ASCII character set
2) Convert all source code files to Unicode format
3) Disable C4819
4) Do nothing and as today leave affected parties to work around the
problem by implementing one of the above as a local hack

Any thoughts?

Thanks,
Eric



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Visual Studio warning C4819

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

Hi All,

Would anyone object to a policy of using only ASCII characters in source
code files?  At present, non-ASCII characters (>128, aka extended ASCII)
appear in various comments and literal strings in the source code, for
example line 54 of file ql/currency.hpp:

        //! fraction symbol, e.g, "¢"

If the machine on which you're reading this message uses the same mapping
as mine for non-ASCII characters, then that line ends with a cent symbol
in double quotes.

On other machines, that character (162) is interpreted as some other
symbol, or is not recognized at all and is rendered as a question mark. 
When the code is compiled on such a machine, Visual Studio emits the
following:

    warning C4819: The file contains a character that cannot be
    represented in the current code page. Save the file in Unicode
    format to prevent data loss.

Some possible courses of action:
1) Restrict ourselves to the ASCII character set
2) Convert all source code files to Unicode format
3) Disable C4819
4) Do nothing and as today leave affected parties to work around the
problem by implementing one of the above as a local hack

Any thoughts?

Thanks,
Eric