call for void constructors

[Vadim Ogranovich-3]

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.

[Luigi Ballabio-2]

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

[Vadim Ogranovich-3]

                From: Luigi Ballabio [mailto:[hidden email]]

                ...

                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.

[Luigi Ballabio-2]

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

[Vadim Ogranovich-3]

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