quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] call for void constructors

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

Hi Vadim,

At 7:16 PM -0500 10/25/02, Vadim Ogranovich wrote:
>I find it inconvenient that FdDividendAmericanOption, etc. have no void
>constructor. I was working around the problem of zero dividend time and
>wanted to overload FdDividendAmericanOption with a new class,
>FdDividendAmericanOption2, that will chop off the zero time dividend and
>pass only the remaining dividends to FdDividendAmericanOption.
>
>However the problem in actually writing
>FdDividendAmericanOption2::FdDividendAmericanOption2 is that I have very
>limited "coding space" to check whether I need to chop off the first element
>and, if yes, to actually chop it off. Indeed, all these calculations need to
>happen before the base class, FdDividendAmericanOption, gets initialized by
>its constructor.

Well, not really. The constructor of FdDividendAmericanOption doesn't 
perform any calculation---it just stores the input data. Calculations 
are done when first asked for and take place inside 
FdDividendAmericanOption::calculate().
You can override the latter in your derived pricer and write:

class FdDividendAmericanOption2 : public FdDividendAmericanOption {
public:
   // constructor
   FdDividendAmericanOption2(Option::Type type, double underlying,
			    double strike, Spread dividendYield,
                             Rate riskFreeRate,
			    Time residualTime, double volatility,
			    const std::vector<double>& dividends =
                                 std::vector<double>(),
			    const std::vector<Time>& exdivdates =
                                 std::vector<Time>(),
			    int timeSteps = 100, int gridPoints = 100);
   void calculate() const;
};

FdDividendAmericanOption2::FdDividendAmericanOption2(
     Option::Type type, double underlying,double strike, Spread dividendYield,
     Rate riskFreeRate, Time residualTime, double volatility,
     const std::vector<double>& dividends, const std::vector<Time>& exdivdates,
     int timeSteps, int gridPoints)
: FdDividendAmericanOption(type,underlying,strike,dividendYield,riskFreeRate,
                            residualTime,volatility,dividends,exdivdates,
                            timeSteps,gridPoints)
{}

void FdDividendAmericanOption2::calculate() const {
    if (we need to discard the first element) {
        chop it off;
    }
    FdDividendAmericanOption::calculate();
}

You might need to add "mutable" to the data members you'll modify in 
the above method.

As for the default constructor issue, the only problem I see is that 
a constructor should leave the instance in a useable state, or at 
least in a state in which the instance knows it wasn't properly 
initialized so that it will raise an exception instead of choking 
when asked its value. As for me, I found that most of the times, the 
hassle of having to introduce an initialization flag and checking it 
in every method is not worth the added addvantage of having a void 
constructor. But that's just my opinion.

Hope this helped,
		Luigi

[Quantlib-dev] call for void constructors

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

Hi,

I find it inconvenient that FdDividendAmericanOption, etc. have no void
constructor. I was working around the problem of zero dividend time and
wanted to overload FdDividendAmericanOption with a new class,
FdDividendAmericanOption2, that will chop off the zero time dividend and
pass only the remaining dividends to FdDividendAmericanOption. Something
like this:

class FdDividendAmericanOption2 : public FdDividendAmericanOption {
public:
  // constructor
  FdDividendAmericanOption2(Option::Type type, double underlying,
			    double strike, Spread dividendYield, Rate
riskFreeRate,
			    Time residualTime, double volatility,
			    const std::vector<double>& dividends =
std::vector<double>(),
			    const std::vector<Time>& exdivdates =
std::vector<Time>(),
			    int timeSteps = 100, int gridPoints = 100);
  
};


However the problem in actually writing
FdDividendAmericanOption2::FdDividendAmericanOption2 is that I have very
limited "coding space" to check whether I need to chop off the first element
and, if yes, to actually chop it off. Indeed, all these calculations need to
happen before the base class, FdDividendAmericanOption, gets initialized by
its constructor.

I can probably find a workaround (and as I am writing this letter I've come
to realize that I probably don't need it at all), but I thought it might be
interesting to bring this up and get other's opinions about it.

Specifically, I suggest addition of a new function 
virtual void FdDividendOption::init(...) that would do what the constructor
now does. The non-void constructor will then call init() to ensure backward
compatability. The difference is that now I can easily implement my staff by
calling init().

IMHO, it is generally good when classes have a void constructor since much
of STL expects them to be available.

Thanks, Vadim

-------------------------------------------------- 
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] Basis point sensitivity

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

Luigi,

Thanx, found the code in Instruments::Swap, what I'm actually looking for is
a bit more complicated. 
I'm basically looking at doing 2 things:

1) Splitting up the allocation of the sensitivity to the start, end, and
payment dates of the cashflow.
2) Having the option of expressing this sensitivity in terms of some other
basis (such as semi-annual), which makes comparison on different instruments
a walk in the park!

Is there anything like this in QuantLib, or, can I go ahead and do it? I
would prefer to impliment this on the Coupon/CashFlow, the accumulation
being handled inside the individual instruments?

I realise this is very sketchy, please yell if you need more info.

Andre

> -----Original Message-----
> From: Luigi Ballabio [mailto:lui...@fa...]
> Sent: 22 October 2002 12:04
> To: Andre Louw; QuantLibDev (E-mail)
> Subject: Re: [Quantlib-dev] Basis point sensitivity
> 
> 
> At 10:17 AM 10/22/02 +0200, Andre Louw wrote:
> >I'm looking at the CashFlow/Coupon/Instrument structure in 
> QuantLib and
> >missing something, sensitivity to the underlying termstructure?
> 
> Hi Andre,
>          there's an example in Instruments::Swap (or 
> SimpleSwap, I don't 
> remember). It could be made a method of Coupon or CashFlow 
> (but then you'd 
> still miss the accumulation part), or a function operating on 
> a vector of 
> CashFlows (but then one would have to rely on dynamic_cast), 
> or both (but 
> that would be a variation of the Visitor pattern [see QuEP 
> 7], so we might 
> be better off implementing it explicitly).
> 
> Thoughts, anyone?
> 
> Bye,
>          Luigi
> 
> 
 
-------------------------------------------------------------------------
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] Conclusions of the First QuantLib Conference

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

At 05:45 PM 10/24/2002 +0200, Luigi Ballabio wrote:
>>Marco, I would only suggest a more somber style, what do you think?
>
>And spoil Marco's fun? :)
Ok I step back.

So my only remaining point is to remove "major sponsor"

ciao -- Nando

Re: [Quantlib-dev] Conclusions of the First QuantLib Conference

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

At 03:45 PM 10/24/02 +0200, Ferdinando Ametrano wrote:
>At 01:29 PM 10/23/2002 +0100, Marco Marchioro wrote:
>>Any last-minute change?
>sorry for being late. Marco, I would only suggest a more somber style, 
>what do you think?

And spoil Marco's fun? :)

[Quantlib-dev] VCG

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

FYI: I wrote to the "Visual Code Generator" guys asking them if they would
be willing to donate a license for QL-XML development, but do not have a
reply yet.

Jens.

Re: [Quantlib-dev] Conclusions of the First QuantLib Conference

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

At 01:29 PM 10/23/2002 +0100, Marco Marchioro wrote:
>Any last-minute change?
sorry for being late. Marco, I would only suggest a more somber style, what 
do you think?

>it is with great pleasure that I will report the conclusions of
>the First QuantLib Conference in Milan, held on October 20th, 2002.
what about "First QuantLib Afternoon"?. No way it was a conference ;-)

>There were participants from the major European countries.
"The participants were me, Luigi, and Nando from Milan, Sad from 
Switzerland and Jens from Germany"

>The meeting started with a visit to the facilities of RiskMap,
>the major sponsor of QuantLib, where coffee and water were served.
I would leave it at "The meeting was hosted in RiskMap's office, where 
coffee and water were served." "Major sponsor" would confirm the impression 
that QuantLib is just a RiskMap marketing tool, something few people 
already complained about in private messages.

thank you for summarizing the conclusions in such an effective way.

ciao -- Nando

[Quantlib-dev] Conclusions of the First QuantLib Conference

[Marco M. <Mar...@ri...>]

Hi developers,
	this is the final version that I will submit to
quantlib-users in a couple of days.

Any last-minute change?

Marco

===============================================
Dear QuantLib user,
it is with great pleasure that I will report the conclusions of
the First QuantLib Conference in Milan, held on October 20th, 2002.

There were participants from the major European countries.
The meeting started with a visit to the facilities of RiskMap,
the major sponsor of QuantLib, where coffee and water were served.

Soon afterwards the discussion begun in a single session with
all the participants very active in the debate. Here's
a list of all the major conclusions.

+Changes to the Web Site
   * Improve documentation, maybe add a weblog where QL developers can
     leave short progress notes
   * Update the "to do" list
   * Draw a road map of future works

+Importance of Unit Testing
   The idea is to certify the quality of QuantLib using a unit-test framework.
   The tests would also serve as concrete examples on how the library should
   be used.
   QuantLib would be defined by what is tested, all the major features should
   be tested. In this way it will also be possible to maintain the 
synchronization
   of QuantLib with QuantLib.NET.
   All the tests done in python will be copied to corresponding tests 
written in C++.

+Changes to the Library
   * Improve the documentation
   * Move to the Instrument/pricing engine framework
   * Refactor of the Finite-Difference framework merging with
     the Tree/Lattice framework
   * Develop a framework for stochastic processes
   * Build basic Bond classes

In particular the last point, build basic Bond classes, needs volunteers.

Afterwards, the meeting moved to a more mundane venue where pizza was 
eventually served.
Distinghishing himself for his class, the representative of the Helvetic 
QuantLib
community asked for a Martini Bianco to drink with his pizza. The other 
developers
enjoyed their pizza with a beer.
Later in the evening the chief architect of QuantLib astonished everybody
winning the competition of eating the biggest(they say size doesn't matter)
slice of cake.

The evening ended late at night after many more discussion about life, the
universe, everything and, of course, QuantLib.

Marco Marchioro, Milan, October 21st, 2002.

Re: [Quantlib-dev] Basis point sensitivity

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

At 10:17 AM 10/22/02 +0200, Andre Louw wrote:
>I'm looking at the CashFlow/Coupon/Instrument structure in QuantLib and
>missing something, sensitivity to the underlying termstructure?

Hi Andre,
         there's an example in Instruments::Swap (or SimpleSwap, I don't 
remember). It could be made a method of Coupon or CashFlow (but then you'd 
still miss the accumulation part), or a function operating on a vector of 
CashFlows (but then one would have to rely on dynamic_cast), or both (but 
that would be a variation of the Visitor pattern [see QuEP 7], so we might 
be better off implementing it explicitly).

Thoughts, anyone?

Bye,
         Luigi

[Quantlib-dev] Basis point sensitivity

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

Hi,

Please could someone clear this up for me.

I'm looking at the CashFlow/Coupon/Instrument structure in QuantLib and
missing something, sensitivity to the underlying termstructure?=20

Is this calculated somewhere else maybe?
	Inside the termstructure - this would make sense for calculating the
risk-factor on a specific discount factor,
	Inside the instruments specifically,
	Under another name/method, something else that can be manipulated to
give the same,
	Outside of Quantlib

I haven't seen anything and am quite willing to put some development =
effort
into this if needed.

Andr=E9 Louw
Decillion Limited - "Your Risk Is Our Domain"

Email:	an...@de...
Office:	+27 (11) 328 1256
Mobile:	+27 (83) 414 5785
Fax:	+27 (11) 442 4456

=20
------------------------------------------------------------------------=
-
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] Final report for the First QuantLib Conference in Milan, October 20th, 2002

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

At 02:51 PM 10/21/02 +0100, Marco Marchioro wrote:
>anybody has anything to add to this report?

Yes:


>+Changes to the Web Site
>   * Improve documentation, maybe add a web-log where web-surfer can leave
>     their remarks

Nope. I think the idea was:

>   * Improve documentation, maybe add a weblog where QL developers can
>     leave short progress notes

Also:

>   All the tests done in python will be moved to corresponding tests 
> written in C++.

Copied, not moved. The Python test suite will survive.

Bye,
         Luigi

[Quantlib-dev] Final report for the First QuantLib Conference in Milan, October 20th, 2002

[Marco M. <Mar...@ri...>]

Hi guys,
anybody has anything to add to this report?
Marco

-------------------------------
Dear QuantLib user,
it is with great pleasure that I will report the conclusions of
the First QuantLib Conference in Milan, held on October 20th, 2002.

There were participants from the major European countries.
The meeting started with a visit to the facilities of RiskMap,
the major sponsor of QuantLib, where coffee and water were served.

Soon afterwards the discussion begun in a single session with
all the participants very active in the debate. Here's
a list of the major conclusions.

+Changes to the Web Site
   * Improve documentation, maybe add a web-log where web-surfer can leave
     their remarks
   * Update the "to do" list
   * Draw a road map of future works

+Importance of Unit Testing
   The idea is to certify the quality of QuantLib using a unit-test framework.
   The tests would also serve as concrete examples on how the library should
   be used.
   QuantLib would be defined by what is tested, all the major features should
   be tested. In this way it will also be possible to maintain the 
synchronization
   of QuantLib with QuantLib.NET.
   All the tests done in python will be moved to corresponding tests 
written in C++.

+Changes to the Library
   * Improve the documentation
   * Move to the Instrument/pricing engine framework
   * Refactor of the Finite-Difference framework merging with
     the Tree/Lattice framework
   * Develop a framework for stochastic processes
   * Build basic Bond classes

In particular the last point, build basic Bond classes, needs volunteers.

Afterwards, the meeting moved to a more mundane venue where pizza was 
eventually served.
Distinghishing himself for his class the representative of the Helvetic 
QuantLib
community asked for a Martini Bianco to drink with his pizza. The other 
developers
enjoyed their pizza with a beer.
Later in the evening the chief architect of QuantLib astonished everybody
winning the competition of eating the biggest(they say size doesn't matter)
slice of cake.

The evening ended late at night after many more discussion about life, the
universe, everything and, of course, QuantLib.

Marco Marchioro, Milan, October 21st, 2002.

[Quantlib-dev] QuantLib afternoon

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

Hi all

if you read the messages last week you know that a few of us are going to 
meet this Sunday.
Here's the details just in case anyone wants to join.

QuantLib Afternoon
Sunday October 20 2002, 4PM
at RiskMap office
Via G. B. Vico 4
(underground stop: S. Ambrogio)
Milan - Italy

the QuantLib afternoon will be followed by a QuantLib Pizza or something 
similar.

ciao -- Nando

Re: [Quantlib-dev] Milan October 17-21

[Sad <sad...@gm...>]

Hi guys,
Sunday 20 or Monday 21 would be fine for me.

See you,
Sad

On Friday 11 October 2002 16:15, Luigi Ballabio wrote:
> At 03:21 PM 10/11/02 +0200, Jens Thiel wrote:
> >is anyone interested in a personal or informal "QuantLib-Developers/User=
s"
> >meeting in Milan during October 17-21?
>
> Hi Jens,
>          what brings you South of the Alps?
>
> I won't be there Friday 18 afternoon and Saturday 19. Any other time, it'=
ll
> be great to meet you.
>
> Bye,
>          Luigi
>
>
>

Re: [Quantlib-dev] Milan October 17-21

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

At 03:21 PM 10/11/02 +0200, Jens Thiel wrote:
>is anyone interested in a personal or informal "QuantLib-Developers/Users"
>meeting in Milan during October 17-21?

Hi Jens,
         what brings you South of the Alps?

I won't be there Friday 18 afternoon and Saturday 19. Any other time, it'll 
be great to meet you.

Bye,
         Luigi

[Quantlib-dev] Milan October 17-21

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

Hi all,

is anyone interested in a personal or informal "QuantLib-Developers/Users"
meeting in Milan during October 17-21?

Regards,

Jens.


--
/* Jens Thiel - Stochastix GmbH - +49-700-STOCHASTIX */

[Quantlib-dev] Delta on CapFloor

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

Hi,

I'm in a bit of a fix. 
I need to NUMERICALLY calculate the delta on a Black-type capfloor.
Calculating said on a specific caplet (in terms of the forward and in terms
of spot) the way I have it is:

	Delta(Forward) = eta * Normdist(d1)
	Delta(Spot) = eta * NormDist(d1) * df(Maturity) * yearFraction

However getting a total for the full strip of caplets is an unknown to me?
Do you base it on an average of all the caplets, I presume not?

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.

[Quantlib-dev] [ quantlib-Bugs-613469 ] negative vega in FdDividendAmericanOptio

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

Bugs item #613469, was opened at 2002-09-23 15:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=613469&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vadim Ogranovich (vograno)
Assigned to: Nobody/Anonymous (nobody)
Summary: negative vega in FdDividendAmericanOptio

Initial Comment:
When an american option is deeply in-the-money (close to 
being exercised) FdDividendAmericanOption sometimes 
yields negative vega, see the attached C++ program to 
reproduce the bug

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

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

[Quantlib-dev] Re: FpML integration - some thoughts

[Toyin A. <toy...@nt...>]

Hi,

Reuters are defining a XML format called MDDI.

I haven't played with it yet, but it seems to handles all types of realtime
market data.

However I don't think this is in QuantLib's mandate.

Regards,
Toy.

[Quantlib-dev] AW: FpML integration - some thoughts

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

All the X/Q/M/S...ML stuff looks like some work todo and I'm not sure where
to start.

SML will be more like a .config file, I guess, but could equally get fetched
from a DB. First step (and already planned) is to write some string-based
factories for the various object types, so I can get eg. a 'GB', 'London' or
'GBP' calendar. Same with the other business conventions. Some of these can
not be effectively "created" from a text file and need a class to supply the
business logic, thats why I already wrote the "FactoryItemAttribute" (see
Utilies) which should be applied to all classes that can be added at
runtime. So adding new business logic would mean to add another assembly and
register its "factory items". The SML approach will be more flexible and
preferable though.

MML looks too complex... maybe even too big for Reuters, Bloomberg and
Datastream. A certain priority would be the ability to define (and pass)
term structures, either with a named handle or direcly "by value".


Things do do after holidays, I guess....


Jens.

> -----Ursprüngliche Nachricht-----
> Von: Toyin Akin [mailto:toy...@nt...]
> Gesendet: Montag, 2. September 2002 19:40
> An: Jens Thiel; qua...@li...
> Cc: anw...@ti...; jam...@ir...
> Betreff: Re: FpML integration - some thoughts
>
>
>
> I agree,
>
> The FpML engine should only really know about holding deal data
> (with enums
> corresponding to various market conventions) and knowing how to
> serialise/deserialise this to XML.
>
> In fact I would like to have 4 schemas defined.
>
> 1) Product based - FpML
> 2) Results based - QML
> 3) Market information MML (curves of various kinds, yield curves, vols
> curves, matrices, cubes, correlations etc...)
> 4) Static data - SML
>
> Thus a user will be able to not only store a deal, but also be
> able to store
> the market parameter for the pricing of that deal or all deals.
>
> Regarding SML (for the lack of a better word), it does not make sense to
> hard code all the business rules for a particular currency in C++/C# code.
> We should really store this within a file. A user should be able to simply
> pick "euribor" to price a leg and not have to figure out all the various
> conventions that apply, especially what holiday centers are specific to a
> particular reference rate both for fixing and payment dates. There are
> hundreds of reference rates floating around and most Traders/Marketers
> certainly know the ISDA definition and would like to simply pick
> from a list
> and not construct one from scratch.
>
> Also adding a new reference rate definition should not involve
> recompling a
> trading system.
>
> Also, a lot of the deals within QuantLib cannot be represented
> within FpML.
> (Equities are weakly represented, and I'm not too impressed with what's
> there already).
>
> I agree with James, we need to at least price a regular swap, with all the
> various market conventions.
> In the case of structured deals (Xccy Swap, Basis swaps, capped floaters
> etc...) you can probably use the productstrategy
> object and just store multiple trades within this object, each trade
> represents a single swapstream object. This way we know it's a structured
> deal and the pricing system can simply iterate across legs and price.
>
> Regards,
> Toy.
>
>
>
>

[Quantlib-dev] Re: FpML integration - some thoughts

[Toyin A. <toy...@nt...>]

I agree,

The FpML engine should only really know about holding deal data (with enums
corresponding to various market conventions) and knowing how to
serialise/deserialise this to XML.

In fact I would like to have 4 schemas defined.

1) Product based - FpML
2) Results based - QML
3) Market information MML (curves of various kinds, yield curves, vols
curves, matrices, cubes, correlations etc...)
4) Static data - SML

Thus a user will be able to not only store a deal, but also be able to store
the market parameter for the pricing of that deal or all deals.

Regarding SML (for the lack of a better word), it does not make sense to
hard code all the business rules for a particular currency in C++/C# code.
We should really store this within a file. A user should be able to simply
pick "euribor" to price a leg and not have to figure out all the various
conventions that apply, especially what holiday centers are specific to a
particular reference rate both for fixing and payment dates. There are
hundreds of reference rates floating around and most Traders/Marketers
certainly know the ISDA definition and would like to simply pick from a list
and not construct one from scratch.

Also adding a new reference rate definition should not involve recompling a
trading system.

Also, a lot of the deals within QuantLib cannot be represented within FpML.
(Equities are weakly represented, and I'm not too impressed with what's
there already).

I agree with James, we need to at least price a regular swap, with all the
various market conventions.
In the case of structured deals (Xccy Swap, Basis swaps, capped floaters
etc...) you can probably use the productstrategy
object and just store multiple trades within this object, each trade
represents a single swapstream object. This way we know it's a structured
deal and the pricing system can simply iterate across legs and price.

Regards,
Toy.

[Quantlib-dev] FpML integration - some thoughts

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

Hi all,

I had some thoughts over FpML integration and would like to make my ideas
available for discussion:

FpML is a more product/business-oriented representation, whereas QuantLib
has its (current) strengths on the calculation side. Separating the business
rules from the calculation may even be favourable, so I would suggest to
define an XML schema solely for calculating and returning results: QML. On
top of that, we can re-implement the existing calculation engines and
validators.

This would allow us to write a very transparent and generic FpML (or
'structured product') to QML translation, where all business rule related
conversions and data access are handled by a separate layer. At the same
time, QML can also serve as a well-defined non-binary interface to QuantLib.

If you see any problems with this approach, or have further suggestions:
your feedback is always welcome!

Regards,

Jens.

[Quantlib-dev] Vacation

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

Hi all,
	I'll be on vacation and offline for a couple of weeks, so it 
won't be out of rudeness that I won't reply to email until September.

Have fun while I'm away,
			Luigi

RE: [Quantlib-dev] default daycounter

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

On a second thought I want to recall my comment that this inconsistency is
sometimes desirable. Sorry for the confusion, Vadim

P.S. Still, it is important to be able to reset the global day counter from
its default value.


=================================

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

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

Luigi,

Thank you, it was ambiguous indeed. To (hopefully) avoid further ambiguity
let me expand it this way: "at run-time change the value of the global day
counter from the default to whatever I need".

Thanks, Vadim

-----Original Message-----
From: Luigi Ballabio [mailto:lui...@fa...]
Sent: Tuesday, August 06, 2002 12:20 PM
To: Vadim Ogranovich; QuantLib-dev
Subject: RE: [Quantlib-dev] default daycounter


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

-------------------------------------------------- 
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.