quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] LocalVolCurve::localVolImpl

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

At 3:29 PM +0100 12/31/02, Jens Thiel wrote:
>Hi Luigi,
>
>
>         template<class Interpolator1D>
>         double LocalVolCurve<Interpolator1D>::localVolImpl(
>             Time t, double, bool extrapolate) const {
>
>             double dt = (1.0/365.0),
>                    var1 = blackVarianceCurve_->blackVariance(t,extrapolate),
>                    var2 = blackVarianceCurve_->blackVariance(t+dt,true),
>                    derivative = (var2-var1)/dt;
>             return QL_SQRT(derivative);
>         }
>
>in the calls to blackVarianceCurve_->blackVariance the only matching method
>signature I could find is:
>
>        //! Black present (a.k.a spot) variance
>         double BlackVolTermStructure::blackVariance(Time maturity,
>                              double strike,
>                              bool extrapolate = false) const;
>
>Is this, as I guess, a C++ type conversion "feature" (aka unnoticed error)

I hate C++ when it does this.
I'll fix it when I'm back to work.

Happy new year,
		Luigi

[Quantlib-dev] LocalVolCurve::localVolImpl

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

Hi Luigi,


        template<class Interpolator1D>
        double LocalVolCurve<Interpolator1D>::localVolImpl(
            Time t, double, bool extrapolate) const {

            double dt = (1.0/365.0),
                   var1 = blackVarianceCurve_->blackVariance(t,extrapolate),
                   var2 = blackVarianceCurve_->blackVariance(t+dt,true),
                   derivative = (var2-var1)/dt;
            return QL_SQRT(derivative);
        }

in the calls to blackVarianceCurve_->blackVariance the only matching method
signature I could find is:

       //! Black present (a.k.a spot) variance
        double BlackVolTermStructure::blackVariance(Time maturity,
                             double strike,
                             bool extrapolate = false) const;

Is this, as I guess, a C++ type conversion "feature" (aka unnoticed error)
or am I missing something?


Happy new year!!

Jens.

[Quantlib-dev] Some issues

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

Hi Luigi,

can you have a look at the following issues or delegate them to the original
authors?


A) Term Structures:

ZeroSpreadedTermStructure and ForwardSpreadedTermStructure BOTH
implement/override forwardImpl() AND zeroYieldImpl(), resulting in an
identical behaviour.


B) ShortFloatingRateCoupon vs. FloatingRateCoupon

Method amount(): Usage of Preceding for rolling back fixing dates is
different and has changed compared to earlier CVS version.



C) Calendars:

Johannesburg calendar class:

  Saturday not documented but implemented as holiday
  may need to add: Human Rights Day 21 March
	(see http://www.national-holidays.com/)
  (anyone from South Africa here?)


London calendar class:

  Some exceptions not properly documented but implemented


Budapest implementation:

  Nov 1st is "All Saints Day", not Labour day.


Sydney calendar

  Documentation from Wellington???
  New Years day possibly not moved?
	(see http://www.national-holidays.com/)
  (anyone from Australia?)


Toronto:

  Some forwards to Monday are not documented but implemented




Regards,

Jens.

[Quantlib-dev] Re: Release candidate

[Dirk E. <ed...@de...>]

> Hi all,
> 	I've just uploaded a golden master of release 0.3.1 on the QL site.
> Please download and play with it so that we can fix any last-minute bugs 
> that might have crept in. The files are:
> 
> http://quantlib.org/gm/QuantLib-0.3.1.tar.gz
> http://quantlib.org/gm/QuantLib-Python-0.3.1.tar.gz
> http://quantlib.org/gm/QuantLib-Ruby-0.3.1.tar.gz
> http://quantlib.org/gm/QuantLib-MzScheme-0.3.1.tar.gz
> http://quantlib.org/gm/QuantLib-Guile-0.3.1.tar.gz
> 
> In absence of corrections, the above are the very file which will get 
> released, so Nando and Dirk can use them to make their packages for Windows 
> and Debian, respectively.

Cool, thanks -- I'll try to get to them on Saturday. Not sure if I'll venture 
into Scheme and Guile, though. Maybe at a later point.

Do you want me to have these, or just QL itself, run through our autobuilders
to see if any of the (many) other architectures trip up something?  I could call
it 0.3.1-0pre which would be overwritten by 0.3.1-1. 

Dirk

-- 
According to the latest figures, 43% of all signatures are totally worthless.   

[Quantlib-dev] Release candidate

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

Hi all,
	I've just uploaded a golden master of release 0.3.1 on the QL site.
Please download and play with it so that we can fix any last-minute bugs 
that might have crept in. The files are:

http://quantlib.org/gm/QuantLib-0.3.1.tar.gz
http://quantlib.org/gm/QuantLib-Python-0.3.1.tar.gz
http://quantlib.org/gm/QuantLib-Ruby-0.3.1.tar.gz
http://quantlib.org/gm/QuantLib-MzScheme-0.3.1.tar.gz
http://quantlib.org/gm/QuantLib-Guile-0.3.1.tar.gz

In absence of corrections, the above are the very file which will get 
released, so Nando and Dirk can use them to make their packages for Windows 
and Debian, respectively.

Later,
	Luigi

Re: [Quantlib-dev] History

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

>Nando, I don't want to hear about positive constraints right now
you won't


------------
ciao -- Nando

Re: [Quantlib-dev] History

[Sad <sa...@qu...>]

Hi Luigi,=20
=20
> sounds good. Just don't do it right now since we're trying to =20
> freeze the library to branch out a release. As soon as the branch is ma=
de =20
> you can start working on it as far as I'm concerned.=20
Sure. Do you need any help for the release? I'm available until next=20
Friday (start of my long due holidays...).=20
 =20
> >We could then also use History<Rate> in the XiborManager class and thu=
s use=20
> >a custom Rate class to represent  interest rates.=20
> Do you mean that Rate is not satisfactory as a typedef to double? In wh=
ich=20
> way? (and Nando, I don't want to hear about positive constraints right=20
> now)=20
Ok, I should have said "and thus be able to use a custom Rate class if=20
needed". For me, double is fine, but I think it's nicer to enforce the us=
e of=20
the Rate type in these cases.

Sad

Re: [Quantlib-dev] History

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

At 11:02 PM 12/18/02 +0100, Sadruddin Rejeb wrote:
>I would like to suggest to make the History class a
>template on the kind of data we want to store. For example, instead of
>double, I would like to treat a historical time serie of stock data
>represented by a struct (high, low, close, volume).

Hi Sad,
         sounds good. Just don't do it right now since we're trying to 
freeze the library to branch out a release. As soon as the branch is made 
you can start working on it as far as I'm concerned.

>We could then also use History<Rate> in the XiborManager class and thus use a
>custom Rate class to represent  interest rates.

Do you mean that Rate is not satisfactory as a typedef to double? In which 
way? (and Nando, I don't want to hear about positive constraints right now)

Later,
         Luigi

[Quantlib-dev] History

[Sadruddin R. <sa...@qu...>]

Hello guys,

I'm currently working, among other stuff, on the implementation of technica=
l=20
analysis oscillators. I would like to suggest to make the History class a=20
template on the kind of data we want to store. For example, instead of=20
double, I would like to treat a historical time serie of stock data=20
represented by a struct (high, low, close, volume).=20
We could then also use History<Rate> in the XiborManager class and thus use=
 a=20
custom Rate class to represent  interest rates.
What do you think?

Sad

[Quantlib-dev] Autotools

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

Hi all,
	as you might have noticed from the flurry of mail from the cvs server, I 
merged the autotools-2-50 branch into the trunk. Now you'll need at least 
autoconf 2.5x and automake 1.6.x (I think). Let me know if something is broken.

Bye,
	Luigi

Re: [Quantlib-dev] Autotools

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

At 06:02 PM 11/27/02 +0100, Luigi Ballabio wrote:

>Hi all,
>         I've been migrating our autoconfiscation process to more recent 
> version of the autotools, namely, autoconf >= 2.50 and automake >= 1.6. 
> Right now the modifications are on a branch. Is it okay to merge them on 
> the trunk? Is there anyone who is stuck with old tools and cannot upgrade?
Go ahead Luigi!

Re: [Quantlib-dev] Autotools

[Sadruddin R. <sa...@qu...>]

Hi Luigi,
> 	I've been migrating our autoconfiscation process to more recent version =
of
> the autotools, namely, autoconf >=3D 2.50 and automake >=3D 1.6. Right no=
w the
> modifications are on a branch. Is it okay to merge them on the trunk? Is
> there anyone who is stuck with old tools and cannot upgrade?
Definitely yes! I'm getting tired of these warnings when running ./bootstrap

Sad

Re: [Quantlib-dev] Autotools

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

>         I've been migrating our autoconfiscation process to more recent 
> version of the autotools, namely, autoconf >= 2.50 and automake >= 1.6. 
> Right now the modifications are on a branch. Is it okay to merge them on 
> the trunk? Is there anyone who is stuck with old tools and cannot upgrade?
I for one would like to have them merged. Maybe this time things will work 
even with cygwin

ciao -- Nando

[Quantlib-dev] Autotools

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

Hi all,
	I've been migrating our autoconfiscation process to more recent version of 
the autotools, namely, autoconf >= 2.50 and automake >= 1.6. Right now the 
modifications are on a branch. Is it okay to merge them on the trunk? Is 
there anyone who is stuck with old tools and cannot upgrade?

Later,
	Luigi

Re: [Quantlib-dev] QuantLib-SWIG and Visual Studio

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

Hi,
the problem was fixed with the help of Luigi. On my computer everything
runs ok.
Unfortunatly, there are still many warnings that I was able to remove
only editing the swig.swg file.

wrap.bat was removed from cvs.

take care,
Marco.


At 12:03 PM 11/11/02 +0100, Marco Marchioro wrote:
>Hi All,
>I compiled QuantLib-SWIG/Python with VisualStudio, using SWIG 1.3.16:
>it seems to work.
>
>I've also added a win32 script wrap.bat to help the generation of the wrappers
>but I do not know how to do it automatically within VisualStudio.
>
>Anybody wants to try?
>
>Marco.

[Quantlib-dev] QuantLib-SWIG and Visual Studio

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

Hi All,
I compiled QuantLib-SWIG/Python with VisualStudio, using SWIG 1.3.16:
it seems to work.

I've also added a win32 script wrap.bat to help the generation of the wrappers
but I do not know how to do it automatically within VisualStudio.

Anybody wants to try?

Marco.

RE: [Quantlib-dev] decreasing discount factors

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

>They were including overnight rates, and the impedence mismatch between 
>the very-short and the short rate region caused a hump on the 
>discounts---a very real one, but not an arbitrage opportunity, mind you, 
>because they were on the same side. Combining a bid and an ask side would 
>not give increasing discounts, of course.
got it, thank you.

ciao -- Nando

RE: [Quantlib-dev] decreasing discount factors

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

At 03:09 PM 11/8/02 +0100, Ferdinando Ametrano wrote:
 > Negative forward rates would be an arbitrage opportunity.

Not if the two spot rates from which you bootstrap the curve are both on 
the bid side or both on the ask side.

>Which leads me back to my original argument. Marco, what kind of benefit 
>are you getting out of the "relaxed" constraints? What are you using the 
>discount curve for?

Why, to represent market data, of course :)
A customer using our libraries stumbled upon a legitimate case such as the 
one Andre' presented. They were including overnight rates, and the 
impedence mismatch between the very-short and the short rate region caused 
a hump on the discounts---a very real one, but not an arbitrage 
opportunity, mind you, because they were on the same side. Combining a bid 
and an ask side would not give increasing discounts, of course.

Bye,
         Luigi

RE: [Quantlib-dev] decreasing discount factors

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

>Using the discount factor formula, if the change in rates is big enough
>relative to the time period, it is quite possible for the discount factors
>to increase!
>
>E.g:
>
>                         Rate    Days            Df
>                 3M      2.30    90/365  0.99436
>                 6M      1.10    180/365 0.99460
>
>This is unlikely but of course not impossible
this is simply impossible in the real world, as it would imply
a forward 3x6 rate of -0.10%, that is a negative interest rate, way out of 
order with rates at a level of 1%-2%
It is not impossible to have negative interest rate, but this happened in 
Japan on very short spot rates (overnight, tom-next). Negative forward 
rates would be an arbitrage opportunity.

Which leads me back to my original argument. Marco, what kind of benefit 
are you getting out of the "relaxed" constraints? What are you using the 
discount curve for?
I'm not asking this out of curiosity, but since it would put a considerable 
burden on my applications I would prefer to revert your commit unless I do 
understand the real benefit of the change. Not that I'm in a hurry, since I 
will not need a new executable at work in the next few months.

Just in case you wonder what kind of burden I'm talking about: I receive a 
discount curve as input from another application that uses FinCAD 
libraries. When this application has problems it usually output a curve 
with non-decreasing discounts, and that QuantLib requirement help me 
immediately detect such problems. I've also investigated how it is possible 
for that application to output non-decreasing discounts and, you know what, 
the problem is with a flawed Reuters/Bloomberg feed that provides wrong 
market rates, of the kind Andre has given as example, and that are not 
possible for EUR/USD/YEN these days.

This said I'm not against checking the discounts in an intermediate layer, 
but I would like to understand which benefit we get in return.

cooperatively yours -- Nando

RE: [Quantlib-dev] decreasing discount factors

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

Hi,

Just my penny's worth. 

Using the discount factor formula, if the change in rates is big enough
relative to the time period, it is quite possible for the discount factors
to increase!

E.g:
			
			Rate	Days		Df
		3M	2.30	90/365	0.99436
		6M	1.10	180/365	0.99460

This is unlikely but of course not impossible - never ASS-U-ME, it makes an
ASS out of U and ME!
 
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] Re: decreasing discount factors

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

Hi,
I realized now that I should have consulted the mailing list first(sorry 
about that).
The only assumptions that we need in building the discount curve is to have
positive discounts, not that these should be decreasing. I should be able to
set my curve to my taste as long as that does not break the interpolation.
If you need a check on your input rates I think this should be done elsewhere.
Why should we prevent the use of negative rates(and they do exists in real 
life)
in one of the few places where we do not actually need to enforce them.

Marco.

At 03:19 PM 11/7/02 +0100, Ferdinando Ametrano wrote:
>Hi Marco
>
>in your commit described below you are removing a worthwhile check that 
>helped me detect many problems in my applications.
>
>Maybe I'm missing something but I can't see why we shouldn't require 
>decreasing discount factors. Decreasing discounts imply non-negative 
>interest rates, which should be a safe assumption. Are you really dealing 
>with negative interest rates?
>If this is the case I'm afraid discountcurve is not the only place where 
>we are assuming non-negative interest rates ....
>
>ciao -- Nando
>
>>From:   Marco Marchioro <ma...@us...>
>>Subject: [Quantlib-cvs] CVS: QuantLib/ql/TermStructures 
>>discountcurve.cpp,1.13,1.14
>>
>>Update of /cvsroot/quantlib/QuantLib/ql/TermStructures
>>In directory usw-pr-cvs1:/tmp/cvs-serv31653
>>
>>Modified Files:
>>         discountcurve.cpp
>>Log Message:
>>relaxed requirement on decreasing discounts
>>
>>Index: discountcurve.cpp
>>===================================================================
>>RCS file: /cvsroot/quantlib/QuantLib/ql/TermStructures/discountcurve.cpp,v
>>retrieving revision 1.13
>>retrieving revision 1.14
>>diff -C2 -r1.13 -r1.14
>>*** discountcurve.cpp   29 Oct 2002 14:14:18 -0000      1.13
>>--- discountcurve.cpp   7 Nov 2002 13:34:20 -0000       1.14
>>***************
>>*** 53,57 ****
>>                   QL_REQUIRE(dates_[i]>dates_[i-1],
>>                      "DiscountCurve::DiscountCurve : invalid date");
>>!                 QL_REQUIRE(discounts_[i]<=discounts_[i-1],
>>                      "DiscountCurve::DiscountCurve : invalid discount");
>>                   times_[i] = dayCounter_.yearFraction(dates_[0],
>>--- 53,57 ----
>>                   QL_REQUIRE(dates_[i]>dates_[i-1],
>>                      "DiscountCurve::DiscountCurve : invalid date");
>>!                 QL_REQUIRE(discounts_[i] > 0.0,
>>                      "DiscountCurve::DiscountCurve : invalid discount");
>>                   times_[i] = dayCounter_.yearFraction(dates_[0],
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: See the NEW Palm
>>Tungsten T handheld. Power & Color in a compact size!
>>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
>>_______________________________________________
>>Quantlib-cvs mailing list
>>Qua...@li...
>>https://lists.sourceforge.net/lists/listinfo/quantlib-cvs

[Quantlib-dev] decreasing discount factors

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

Hi Marco

in your commit described below you are removing a worthwhile check that 
helped me detect many problems in my applications.

Maybe I'm missing something but I can't see why we shouldn't require 
decreasing discount factors. Decreasing discounts imply non-negative 
interest rates, which should be a safe assumption. Are you really dealing 
with negative interest rates?
If this is the case I'm afraid discountcurve is not the only place where we 
are assuming non-negative interest rates ....

ciao -- Nando

>From:   Marco Marchioro <ma...@us...>
>Subject: [Quantlib-cvs] CVS: QuantLib/ql/TermStructures 
>discountcurve.cpp,1.13,1.14
>
>Update of /cvsroot/quantlib/QuantLib/ql/TermStructures
>In directory usw-pr-cvs1:/tmp/cvs-serv31653
>
>Modified Files:
>         discountcurve.cpp
>Log Message:
>relaxed requirement on decreasing discounts
>
>Index: discountcurve.cpp
>===================================================================
>RCS file: /cvsroot/quantlib/QuantLib/ql/TermStructures/discountcurve.cpp,v
>retrieving revision 1.13
>retrieving revision 1.14
>diff -C2 -r1.13 -r1.14
>*** discountcurve.cpp   29 Oct 2002 14:14:18 -0000      1.13
>--- discountcurve.cpp   7 Nov 2002 13:34:20 -0000       1.14
>***************
>*** 53,57 ****
>                   QL_REQUIRE(dates_[i]>dates_[i-1],
>                      "DiscountCurve::DiscountCurve : invalid date");
>!                 QL_REQUIRE(discounts_[i]<=discounts_[i-1],
>                      "DiscountCurve::DiscountCurve : invalid discount");
>                   times_[i] = dayCounter_.yearFraction(dates_[0],
>--- 53,57 ----
>                   QL_REQUIRE(dates_[i]>dates_[i-1],
>                      "DiscountCurve::DiscountCurve : invalid date");
>!                 QL_REQUIRE(discounts_[i] > 0.0,
>                      "DiscountCurve::DiscountCurve : invalid discount");
>                   times_[i] = dayCounter_.yearFraction(dates_[0],
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: See the NEW Palm
>Tungsten T handheld. Power & Color in a compact size!
>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
>_______________________________________________
>Quantlib-cvs mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-cvs

RE: [Quantlib-dev] call for void constructors

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

>too much :-)) consider writing a function which given option 
> characteristics
> >returns the most efficient pricer for that option, e.g.
> >
> >		SingleAssetOption * getMostEfficientPricer(...).
> >
> >		Without default constructors the argument list of the
> >function must include all parameters possibly needed by 
> actual constructors
> >(fat parameter list). This is certainly not good as this 
> list is likely to
> >change when you add new pricers or add parameters to the old 
> constructors.
> 
> I'm not entirely following you here. Won't you have the same problem 
> with init(), i.e., won't init() suffer from the same 
> fat-parameter-list problem? And if not, how will you know which kind 
> of pricer was returned so that you can pass the right parameter list 
> to init()? All you will get is a pointer to the base class...

Good point. Indeed, it is hard to imagine a scenario where one uses
getMostEfficientPricer() alone without immediately initializing the returned
pointer (using dynamic_cast, of course). After your comments I don't
consider the getMostEfficientPricer example very illustrative anymore.
Still, it would be nice to come up with a design that allows such a function
and any such design will probably require default constructors.


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] call for void constructors

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

At 1:58 PM -0500 10/26/02, Vadim Ogranovich wrote:
>		[Vadim] Well, this will work, but it's a HACK and ,worse, it
>breaks "encapsulation" of FdDividendAmericanOption since now I need to know
>that its constructor doesn't perform any calculation, and those people who
>modify FdDividendAmericanOption class need to know that too, otherwise they
>will break my new class.

Hmm. Yes, you're mostly right and I was mostly wrong, so I won't go 
and start dotting i's and j's. init() might just be the least of 
evils.

>		To make this discussion a little bit more concrete (but not
>too much :-)) consider writing a function which given option characteristics
>returns the most efficient pricer for that option, e.g.
>
>		SingleAssetOption * getMostEfficientPricer(...).
>
>		Without default constructors the argument list of the
>function must include all parameters possibly needed by actual constructors
>(fat parameter list). This is certainly not good as this list is likely to
>change when you add new pricers or add parameters to the old constructors.

I'm not entirely following you here. Won't you have the same problem 
with init(), i.e., won't init() suffer from the same 
fat-parameter-list problem? And if not, how will you know which kind 
of pricer was returned so that you can pass the right parameter list 
to init()? All you will get is a pointer to the base class...

Later,
	Luigi

RE: [Quantlib-dev] call for void constructors

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

		From:	Luigi Ballabio [mailto:lui...@fa...]

		...

		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. 

		[Vadim] Well, this will work, but it's a HACK and ,worse, it
breaks "encapsulation" of FdDividendAmericanOption since now I need to know
that its constructor doesn't perform any calculation, and those people who
modify FdDividendAmericanOption class need to know that too, otherwise they
will break my new class. Use of init() is free of these drawbacks since all
I need to know is to create an empty instance and then initialize it with
init, in other words I just need to know the interface.

		I agree that it would be desirable that default constructor
created a valid instance, but it's not of really high importance, especially
if an uninialized instance will crash the program. 


		To make this discussion a little bit more concrete (but not
too much :-)) consider writing a function which given option characteristics
returns the most efficient pricer for that option, e.g.

		SingleAssetOption * getMostEfficientPricer(...).

		Without default constructors the argument list of the
function must include all parameters possibly needed by actual constructors
(fat parameter list). This is certainly not good as this list is likely to
change when you add new pricers or add parameters to the old constructors.


		Again, lack of default constructors is not an
un-surmountable problem, it's just an inconvenience that precludes some good
programming techniques.
		

		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.