quantlib-dev — Discussion of QuantLib development

RE: [Quantlib-dev] default daycounter

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

At 1:44 PM -0500 8/6/02, Vadim Ogranovich wrote:
>I think the global default is good as long as there is a way for a
>programmer to take over should a need arise. I wouldn't however give this a
>high priority. One thing that IS important is the ability to reset the
>default (from say Act/365 to any other day counter).

Hi Vadim,
	not that I'm biased towards either possibility, but do you 
mean "reset the default" as in "change the global default" or on a 
per-instance basis?

Later,
	Luigi

RE: [Quantlib-dev] default daycounter

[Vadim O. <vo...@ar...>]

The inconsistency is sometimes desirable. For example in option vols. it is
sometimes the number of business days till expiration that matters, whereas
the corresponding interest rate or dividend timing are based on calendar
days.

I think the global default is good as long as there is a way for a
programmer to take over should a need arise. I wouldn't however give this a
high priority. One thing that IS important is the ability to reset the
default (from say Act/365 to any other day counter).

Thanks, Vadim



-----Original Message-----
From: Ferdinando Ametrano [mailto:fer...@am...]
Sent: Tuesday, August 06, 2002 9:58 AM
To: QuantLib-dev
Subject: [Quantlib-dev] default daycounter


Hi all

while working on extending the pricing engines to time dependant parameters 
(yields, vol, etc.) I stumbled across the problem of possible 
inconsistencies between different day count conventions used by the 
different term structures, vol surfaces, etc.

So I would like to define a default daycounter for all the yield/vol term 
structures, probably Act/365 as global variable.
Then I would remove the dayCounter() inspector method from the interested 
classes.

Any objection/suggestion?

ciao -- Nando



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Quantlib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-------------------------------------------------- 
DISCLAIMER 
This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information.  If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof. 

E-mail transmission cannot be guaranteed to be secure or error-free.  The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.

NOTICE REGARDING PRIVACY AND CONFIDENTIALITY 

Knight Trading Group may, at its discretion, monitor and review the content
of all e-mail communications. 

Re: [Quantlib-dev] default daycounter

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

forgot to add that I see this in the same way as we have continuos 
compounding enforced for zero yields, that is just an _internal_ convention 
for time measurement.

ciao -- Nando

At 06:57 PM 8/6/2002 +0200, I wrote:
>Hi all
>
>while working on extending the pricing engines to time dependant 
>parameters (yields, vol, etc.) I stumbled across the problem of possible 
>inconsistencies between different day count conventions used by the 
>different term structures, vol surfaces, etc.
>
>So I would like to define a default daycounter for all the yield/vol term 
>structures, probably Act/365 as global variable.
>Then I would remove the dayCounter() inspector method from the interested 
>classes.
>
>Any objection/suggestion?
>
>ciao -- Nando
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] default daycounter

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

Hi all

while working on extending the pricing engines to time dependant parameters 
(yields, vol, etc.) I stumbled across the problem of possible 
inconsistencies between different day count conventions used by the 
different term structures, vol surfaces, etc.

So I would like to define a default daycounter for all the yield/vol term 
structures, probably Act/365 as global variable.
Then I would remove the dayCounter() inspector method from the interested 
classes.

Any objection/suggestion?

ciao -- Nando

[Quantlib-dev] off-line

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

Hi all,
	I'll be in vacation and off-line for a week starting tomorrow.

See you all later,
		Luigi

[Quantlib-dev] QL.NET installer

[Jens T. <jen...@st...>]

Hi,

I produced an installer for the QuantLib.NET preview this week. You'll need
the .NET redistributable (which I left out of the installer) from:

>
http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/001/829/m
sdncompositedoc.xml

or the windows update site.

After the installation, you can open Excel (VBE=Alt-F11), VB6 or any other
COM-enabled application, and add a reference to QuantLib.NET to your empty
project. Please run the following test to make sure that QuantLib.dll and
COM interop have been succesfully registered:

Sub test()
  Dim dc As New Actual365
  MsgBox dc
End Sub

Using any .NET language should also work (and is the preferred way). More
documentation on this will follow.

Jens.

ps: This is only a test for the installer: the included library is in an
undefined state ;-)

Re: [Quantlib-dev] FloatingRateCoupon::amount()

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

At 10:04 PM 7/21/02 +0200, Ferdinando Ametrano wrote:
>At 04:50 PM 7/17/2002 +0200, Jens Thiel wrote:
>>I think the whole code might be replaced by
>>
>>     return (index_->fixing(fixingDate) + spread_) *
>>            accrualPeriod() * nominal();

This is a point I made mself in the past (see my post at
http://www.geocrawler.com/archives/3/6863/2002/3/0/8235251/ ).

However, the thread that followed (and which can be read at
http://www.geocrawler.com/mail/thread.php3?subject=%5BQuantlib-users%5D+Floating+Coupons&list=6863 
) deemed me wrong.


>>I also suspect that their might be some confusion in the usage of fixingDate
>>and fixingValueDate in this method. Maybe the original author can have a
>>look at this?
>Luigi? Are you alive? ;-)

There might be some confusion, I agree.
Nando, your smileys notwithstanding, I thought you were looking at it as 
part of your whole term structure/today's date/settlement date 
reorganization, weren't you?

Later,
         Luigi

Re: AW: [Quantlib-dev] Re: Some questions

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

Hi all

Sad wrote:
>Another thing, I noticed that a .NET module, which appears to
>be a re-implementation of QuantLib in C#, has been created. I
>would like to
>know what are the goals of this project and how the collaboration
>between the
>two development efforts is going to work.

and Jens replied:
>Initially, QuantLib.NET will be a proof-of-concept, a replacement for our
>existing COM wrappers around the C++ version, and a personal dive into .NET
>technology and also the existing QuantLib.
Well I think the majority here would be more confident to have wrappers of 
the existing C++ code, but Jens pointed out his reasons for C# and I see no 
problem in allowing QuantLib.NET as long as Jens is committed to it.

>  # Use C# instead of managed C++
>
>    - a test implementation in managed C++ was not so "nice"
>      (don't know if I should check this in)
I was surprised nobody asked you about this. Jens, could you elaborate more?

>  # syncing C++ and .NET development will be the hardest
>    part, but having unit tests can help a lot
if the development speed of QuantLib will be the same as in the last weeks 
it won't be really a problem ;-)
Jokes aside, it will be really hard. We would need a C++ unit test 
framework. any Boost user here?

>I think I will ask Nando to announce the .NET module at the beginning of
>next week, but early feedback is always welcome! If there is sufficient
>interest I'll also try to update the CVS more frequently (but don't
>complain, it's currently mostly untested code...).
Jens, please keep us updated

>With the beginning of next week, current snapshots will be available for
>download, so you can start using .NET instantly with eg. Excel.
please provide us a quick intro ...

ciao -- Nando

Re: [Quantlib-dev] Re: Some questions

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

Hi Sad

>Remember the changes to the instrument and pricing engine stuff we talked
>about a few weeks ago? Well, I finally have some time now to implement them
>so I just want to make sure that nobody else has started doing the job.
I am the only one working on them. Unfortunately I haven't had free time in 
the last 3 weeks. I revised the european engine, and added generic 
quanto/forward engine.
High priorities in my task list are (almost in order):
- create 2 different vol term structure classes: Black vol and Local vol, 
the former simply being the market quoted vol (prices) surface, while the 
latter should be the local vol used for the underlying stochastic process. 
The latter is the one to be used by the pricing engines
- substitute doubles with term structures in engine's parameters where 
appropriate, so to allow for time dependent parameters (e.g. time varying 
vols and yields for asian options)
- use your Exercise class in the engines
- write a forward quanto engine combining the existing forward and quanto 
engines
- write the Finite Difference engine for european/american option
- write the Monte Carlo engine for european options
- move as many Pricers as possible from the old Pricer framework to the 
engine framework
- release QuantLib 0.4

I would be glad if you join me on these tasks. Please don't consider my 
late reply as a sign of disinterest. BTW since my feedback time is getting 
higher consider also working on your own branch if this allow you to write 
faster without having to worry about my timely feedback

ciao -- Nando

Re: [Quantlib-dev] FloatingRateCoupon::amount()

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

At 04:50 PM 7/17/2002 +0200, Jens Thiel wrote:
>I think the whole code might be replaced by
>
>     return (index_->fixing(fixingDate) + spread_) *
>            accrualPeriod() * nominal();
>
>I also suspect that their might be some confusion in the usage of fixingDate
>and fixingValueDate in this method. Maybe the original author can have a
>look at this?
Luigi? Are you alive? ;-)

ciao -- Nando

[Quantlib-dev] FloatingRateCoupon::amount()

[Jens T. <jen...@st...>]

Hello,

while porting to C#, a few questions came up regarding
FloatingRateCoupon::amount(). First of all, I think the whole code might be
replaced by

    return (index_->fixing(fixingDate) + spread_) *
           accrualPeriod() * nominal();

I also suspect that their might be some confusion in the usage of fixingDate
and fixingValueDate in this method. Maybe the original author can have a
look at this?


Jens.

AW: [Quantlib-dev] Re: Some questions

[Jens T. <jen...@st...>]

> Another thing, I noticed that a .NET module, which appears to
> be a re-implementation of QuantLib in C#, has been created. I
> would like to
> know what are the goals of this project and how the collaboration
> between the
> two development efforts is going to work.

I also have some time available now, and I started the .NET project last
week, and continued yesterday. I agreed with Nando to be ahead a week or so
before officially announcing the availability of the module.

Initially, QuantLib.NET will be a proof-of-concept, a replacement for our
existing COM wrappers around the C++ version, and a personal dive into .NET
technology and also the existing QuantLib.

I collected the following items as "goals" (see references at end):

 # deliver a working QuantLib implementation targeted to the
   CLR in platform-independent code

   - support CLRs on different platforms (eg mono[1], rotor[2][3])
   - maybe supply native optimizations after profiling since
     you can easily merge namespaces from multiple assemblies

 # Use C# instead of managed C++

   - a test implementation in managed C++ was not so "nice"
     (don't know if I should check this in)
   - I personally find C# more productive for .NET development
   - better .NET and VS.NET integration than C++
   - forced to write plattform-independent code
   - free implementations available from MS[4], mono[1] and
     rotor[3]. You can use Emacs+make or alternative free
     IDEs like SharpDevelop[5]

 # follow .NET guidelines for class libraries and integrate
   smoothly in the .NET world

   - bring in experiences from COM development
   - use common interfaces, events and delegates
   - allow to easily access data from different sources
   - supply parameterless ctors and factories for COM
     (also come doesn't like overloads)

 # Support COM interop to make QuantLib.NET available in eg.
   Excel (97+), Access (97+), VB6 and others

 # Intensive unit-testing and examples

 # For the future:

   - Generate web services and support XML


I can generally see some problems here

 # we have to give up templates for now (but generics
   will be available in a future .NET release (see
   papers at m$ research)

 # syncing C++ and .NET development will be the hardest
   part, but having unit tests can help a lot

 # performance; but we can substitute critical code
   with native implementations. We may also see improved
   JIT compilers in the future.


I think I will ask Nando to announce the .NET module at the beginning of
next week, but early feedback is always welcome! If there is sufficient
interest I'll also try to update the CVS more frequently (but don't
complain, it's currently mostly untested code...).

With the beginning of next week, current snapshots will be available for
download, so you can start using .NET instantly with eg. Excel.


Please post your questions or comments. I would also like to discuss some
architectural issues like mixing of managed/unmanaged code, since I am new
to .NET for myself.


Jens.

References (as usual, must be on one line)

[1] http://www.go-mono.com/
[2] http://www.oreillynet.com/pub/a/dotnet/2001/06/27/dotnet.html
[3]
http://msdn.microsoft.com/downloads/sample.asp?url=/MSDN-FILES/027/001/901/m
sdncompositedoc.xml
[4]
http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/000/976/m
sdncompositedoc.xml
[5] http://www.icsharpcode.net/OpenSource/SD/default.asp

[Quantlib-dev] Re: Some questions

[Sadruddin R. <sad...@gm...>]

Hi guys,
Remember the changes to the instrument and pricing engine stuff we talked 
about a few weeks ago? Well, I finally have some time now to implement them 
so I just want to make sure that nobody else has started doing the job. 
Another thing, I noticed that a .NET module, which appears to 
be a re-implementation of QuantLib in C#, has been created. I would like to 
know what are the goals of this project and how the collaboration between the 
two development efforts is going to work.
Thanks and best regards,
Sad

[Quantlib-dev] Termstructure changes

[Andre L. <An...@de...>]

Hi,

I have some changes on TermStructure that I wish to run by you:

	1) Add zeroCoupon() and zeroCouponImpl() methods.
	2) Add ZeroCouponStructure to implement defaults for the above.
	2) Add a discreteForwardImpl() method, instead of calculating it
inside forward(t1,t2). Makes life a lot easier when implementing
compoundforward. 

Any objections?

Thanx,

Andre

 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

Re: [Quantlib-dev] Re: LogLinear interpolation

[Luigi B. <bal...@ma...>]

At 01:29 PM 6/27/02 +0200, Ferdinando Ametrano wrote:
>Not quite the same thing indeed. I might be wrong but your formula is 
>quite similar to "geometric interpolation"
>     dfx = (df1^((t2-tx)/(t2-t1)))*(df2^((tx-t1)/(t2-t1))).

Which is exactly the same as your loglinear formula.


Playing the devil's advocate and loving it,

                 Luigi

[Quantlib-dev] RE: LogLinear interpolation

[Luigi B. <bal...@ma...>]

At 3:12 PM +0200 6/27/02, Andre Louw wrote:
>Nando,
>
>>  I might be wrong but your formula is quite similar to "geometric
>interpolation"
>dfx = (df1^((t2-tx)/(t2-t1)))*(df2^((tx-t1)/(t2-t1))).
>I think you're right, I actually got this from some existing code and
>implemented it as is. Will delve a bit deeper to get to it's origin!

(posting it again since the mail didn't seem to go through...)

Nando, you can call the above "geometric interpolation" if you want, 
but it's actually the same formula you used for loglinear 
interpolation :)

(not very surprising, actually. I think "geometric" means 
interpolating y vs exp(x), while "loglinear" means interpolating 
log(y) vs x...)

Bye,
	Luigi (which doesn't feel like reusing the closing quip he 
already put into the mail that sourceforge is holding. Computers. Bah)

[Quantlib-dev] Re: LogLinear Interpolation

[Luigi B. <bal...@ma...>]

At 01:05 PM 6/27/02 +0200, Andre Louw wrote:
>Disregard my previous rant. I got my facts a bit mixed up.

I know the feeling. And vacations are still sooo far away...


>Could you give me a bit more on how one would go about giving DiscountCurve
>the ability to distinguish which to use?

Sure. Modifying DiscountCurve so that it can use different interpolations 
in easy enough: you just have to declare it as:

     template <class DfInterpolation>
     class DiscountCurve : public DiscountStructure {
         ... blah blah ...
         // typedef Math::LogLinearInterpolation <     remove this typedef!!
         // std::vector < Time >::const_iterator,
         // std::vector < double >::const_iterator > DfInterpolation;
         Handle < DfInterpolation > interpolation_;
     };

on the other hand, the instantiation would be kind of clumsy as one would 
be forced to write:

     DiscountCurve<LogLinearInterpolation <
         std::vector<Time>::const_iterator,
         std::vector<double>::const_iterator > > curve(...);

Then again, we could provide a few typedefs such as:

     typedef DiscountCurve<LogLinearInterpolation <
         std::vector<Time>::const_iterator,
         std::vector<double>::const_iterator > > LogLinearDiscountCurve;

so that the instantiation would be written as:

     LogLinearDiscountCurve curve(...);


Also, I'm sure that there's some other syntax one could use so that one 
could instantiate the curve as

     DiscountCurve<LogLinearInterpolation> curve(...);

but a) I don't remember it so I have to dig it out and b) I'm not sure that 
all compiler will allow it.

I'll do my homework and come back.

Later,
         Luigi

[Quantlib-dev] RE: LogLinear interpolation

[Andre L. <An...@de...>]

Nando,

> I might be wrong but your formula is quite similar to "geometric
interpolation"
dfx = (df1^((t2-tx)/(t2-t1)))*(df2^((tx-t1)/(t2-t1))).
I think you're right, I actually got this from some existing code and
implemented it as is. Will delve a bit deeper to get to it's origin!

> We could add to the CVS your original code as 
> XXXinterpolation.hpp, but I 
> would require to handle the t==0.0 case. 
Don't bother, I would prefer to use loglinear.

> I'm not happy about this approach since it will allow some really bad 
> interpolation choice, anyway since QuantLib users are 
> supposed to be smart 
> ... it's OK for me.
> If we go this way it should be clear here that it's a must for 
> geometricinterpolation to handle t==0.0, or the discount near 
> t=0.0 will be 
> screwed up.
O.K

> Andre, I'm sorry if my changes broke some functionality you 
> were relying 
> upon, but in a previous email last week-end I asked about it:

That's actually what sparked me to check out the latest version from CVS.

Sorry again for the confusion, check my other e-mail.

Andre
 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

[Quantlib-dev] Re: LogLinear interpolation

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

Hi all

Andre Louw wrote:
>Correct me if i'm wrong, but I see you are using linear interpolation on
>cont. compounded rates to get to the resulting discount factor
As Luigi pointed out I implemented a linear interpolation on the logarithm 
of the discounts. The logarithm of a discount is not the continuos 
compounded rate r, but -r*t.

Anyway for sake of clarity let's talk before about interpolation in 
general, with no reference to discount and rates. So the LogLinear 
interpolation I implemented is a linear interpolation on {Xi}, {LOG(Yi(Xi))}

>I implemented loglinear interpolation to get to the result i.o.w:
>
>         dfx = (df1^(tx/t1*(t2-tx)/(t2-t1)))*(df2^(tx/t2*(tx-t1)/(t2-t1)))
>
>Not quite the same thing.
Not quite the same thing indeed. I might be wrong but your formula is quite 
similar to "geometric interpolation" dfx = 
(df1^((t2-tx)/(t2-t1)))*(df2^((tx-t1)/(t2-t1))).
The problem with your original formula is that is undefined at t1==0.0 and 
t2==0.0
We could add to the CVS your original code as XXXinterpolation.hpp, but I 
would require to handle the t==0.0 case. When I decided to rewrite 
LogLinear interpolation I didn't got it was geometric interpolation, I just 
noticed that as interpolation it had problem at t=0.0

>>We could the implement a mechanism in DiscountCurve to distinguish which 
>>to use?
>
>Sure:
>
>template <class Interpolation>
>class DiscountCurve {
>    ...
>};
I'm not happy about this approach since it will allow some really bad 
interpolation choice, anyway since QuantLib users are supposed to be smart 
... it's OK for me.
If we go this way it should be clear here that it's a must for 
geometricinterpolation to handle t==0.0, or the discount near t=0.0 will be 
screwed up.

Andre, I'm sorry if my changes broke some functionality you were relying 
upon, but in a previous email last week-end I asked about it:
>3) I fixed 2 bugs in DiscountCurve, but I still have problems with 
>calculations between settlementDate and the first knot date, probably due 
>to some problem in LogLinearInterpolation. Have someone ever used this 
>classes? Do they work for you?
The bugs were pointed object lifetime issues, while I realized now that the 
problem with the LogLinearInterpolation was just that geometric 
interpolation was undefined at t=0.0

ciao -- Nando

[Quantlib-dev] Re: LogLinear Interpolation

[Andre L. <An...@de...>]

Luigi,

Disregard my previous rant. I got my facts a bit mixed up.

Nando's implementation of log-linear interpolation is quite correct. What
had me confused is that I remember it (parrot wise) as:
	dfx = df1*((df2/df1)^((t3-t1)/(t2-t1))), which, alas, as you pointed
out matches Nando's!

Sorry for the confusion, I will in any case implement a linear interpolation
on continuos compounding.

Could you give me a bit more on how one would go about giving DiscountCurve
the ability to distinguish which to use?

Andre



 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

Re: [Quantlib-dev] LogLinear interpolation

[Luigi B. <bal...@ma...>]

Hi Andre,
         forget me for jumping in, but I got interested...

At 01:25 PM 6/26/02 +0200, Andre Louw wrote:
>Correct me if i'm wrong, but I see you are using linear interpolation on
>cont. compounded rates to get to the resulting discount factor i.o.w:
>
>         cf1 = ln(df1), cf2 = ln(df2)
>         dfx = exp(cf1+((tx-t1)/(t2-t1))*(cf2-cf1)))

Personally, I didn't see the above as cont. compounded rates (shouldn't 
they be ln(df1)/t1 anyway?)
I had figured it as "linear interpolation on the logarithms of the discounts"
which, I assumed, was the definition Nando took of "loglinear".


>I implemented loglinear interpolation to get to the result i.o.w:
>
>         dfx = (df1^(tx/t1*(t2-tx)/(t2-t1)))*(df2^(tx/t2*(tx-t1)/(t2-t1)))
>
>Not quite the same thing.

Well, almost :)
Nando's formula can be transformed to

         dfx = (df1^((t2-tx)/(t2-t1)))*(df2^((tx-t1)/(t2-t1)))

Moreover, it can be transformed to

         dfx = df1*(df2/df1)^((tx-t1)/(t2-t1))

or

         ln(dfx)-ln(df1)   ln(df2)-ln(df1)
         --------------- = ---------------
              tx-t1             t2-t1

which is not a direct one but best expresses the intent...


>If that is your institution's standard, fine, but could I then rename your
>implementation as contcomplinearinterpolation.hpp (or some such name), as I
>see the original implementation being log-linear interpolation?

I think it's just a matter of deciding what's what.
<asking just out of ignorance>
What is your definition of "loglinear"? In plain english, I mean?
</asking just out of ignorance>


>We could the implement a mechanism in DiscountCurve to distinguish which 
>to use?

Sure:

template <class Interpolation>
class DiscountCurve {
    ...
};

Bye,
         Luigi

[Quantlib-dev] LogLinear interpolation

[Andre L. <An...@de...>]

Nando,

I just checked out loglinearinterpolation and noted the change you
implemented. I have a comment.

Correct me if i'm wrong, but I see you are using linear interpolation on
cont. compounded rates to get to the resulting discount factor i.o.w:

	cf1 = ln(df1), cf2 = ln(df2)
	dfx = exp(cf1+((tx-t1)/(t2-t1))*(cf2-cf1)))

I implemented loglinear interpolation to get to the result i.o.w:

	dfx = (df1^(tx/t1*(t2-tx)/(t2-t1)))*(df2^(tx/t2*(tx-t1)/(t2-t1)))

Not quite the same thing.

If that is your institution's standard, fine, but could I then rename your
implementation as contcomplinearinterpolation.hpp (or some such name), as I
see the original implementation being log-linear interpolation? We could the
implement a mechanism in DiscountCurve to distinguish which to use? 

I had a problem with the original implementation between t1 = 0 and some tx
which I solved by testing for this condition and calculating dfx:
	dfx = 1/1+((1/df2-1)/t2)*tx

Comments?

Andre


 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

Re: [Quantlib-dev] yield term structure again

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

At 11:34 AM 6/24/2002 +0200, enr...@ri... wrote:
>hi, we just checked for the currency() method, and it seems ok to
>remove it.
thank you

ciao -- Nando

Re: [Quantlib-dev] yield term structure again

[<enr...@ri...>]

>>>>> "nando" == Ferdinando Ametrano <fer...@am...> writes:

    nando> Hi all as you might have noticed I'm working on term
    nando> structures.  A few questions:

    nando> 1) Enrico, have you figured out if the currency() method is
    nando> really relevant for RiskMap's code? I would really like to
    nando> remove it.  2) I would also like to remove todaysDate(),

hi, we just checked for the currency() method, and it seems ok to
remove it. 
Bye,
enrico

-- 
Enrico Sirola <en...@us...>
gpg public key available from wwwkeys.pgp.net
Key fingerprint = B446 7332 ED55 BC68 5FE8  DE0F 98DF EC86 377F E07F

[Quantlib-dev] yield term structure again (2)

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

Hi all

while trying to experiment with the point I proposed in my last email I 
realized I have to step back as far as todaysDate() is concerned, since 
indexes and rate helpers rely on that method. While I'm still not sure 
about todaysDate(), I would skip this change for the time being

While there I also realized that we could remove minDate() since 
minDate()==settlementDate(). Is it OK?

ciao -- Nando