European Option that comes due "this" month

[Robert F. Hoffman]

I am interested in using the Black Scholes calculation on an option
which comes due in the current month.

By editing the example to hard-code the current month in the today,
settlement, and exercise date fields I get the following error in
blackvariancesurface.cpp:55:

QuantLib::BlackVarianceSurface::BlackVarianceSurface(const
QuantLib::Date&, const std::vector<QuantLib::Date,
std::allocator<QuantLib::Date> >&, const std::vector<Time,
std::allocator<Time> >&, const QuantLib::Matrix&,
QuantLib::BlackVarianceSurface::Extrapolation,
QuantLib::BlackVarianceSurface::Extrapolation, const
QuantLib::DayCounter&): dates must be sorted unique!

I get the same error even if I change this:
dates[0] = settlementDate.plusMonths(1);
to this:
dates[0] = settlementDate;

Is this just some documentation insufficiency or something  missing in
the interface?  Can a Black Scholes calculation be done on this month,
and if so, how?

(Note: Is there any more comprehensive documentation on how to use this
feature other than the example and the class description?)

Thanks in advance.
Robert Hoffman

[Luigi Ballabio-2]

At 16:41 03/11/2004, Robert F. Hoffman wrote:

>I am interested in using the Black Scholes calculation on an option
>which comes due in the current month.
>
>By editing the example to hard-code the current month in the today,
>settlement, and exercise date fields I get the following error in
>blackvariancesurface.cpp:55:
>
>QuantLib::BlackVarianceSurface::BlackVarianceSurface(const
>QuantLib::Date&, const std::vector<QuantLib::Date,
>std::allocator<QuantLib::Date> >&, const std::vector<Time,
>std::allocator<Time> >&, const QuantLib::Matrix&,
>QuantLib::BlackVarianceSurface::Extrapolation,
>QuantLib::BlackVarianceSurface::Extrapolation, const
>QuantLib::DayCounter&): dates must be sorted unique!

Robert,
         the error is raised during the instantiation of the
BlackVarianceSurface. If you're not using it (i.e., if you're using a flat
volatility as in the example) you can safely comment its construction out.

If you want to keep it, the problem is the one reported---"dates must be
sorted unique", i.e., must be sorted and without duplicates. You can try
and print out the dates you're passing to the surface to see whether they
satisfy the requirement. For instance,

dates[0] = settlementDate.plusMonths(1);
dates[1] = exerciseDate;

are guaranteed to be unsorted if the exercise is closer than one month.
Also, I think that dates[0] must be strictly later than the settlement.

But really, if a flat volatility is enough for you, just comment out the
BlackVarianceSurface thing. It is there only because Nando is a pack rat :)

Later,
         Luigi

[Robert F. Hoffman]

Sorry to take so long to respond, diverted with other obligations.
Works for me.  Thanks,
Robert

On Thu, 2004-11-04 at 07:38, Luigi Ballabio wrote:

> At 16:41 03/11/2004, Robert F. Hoffman wrote:
> >I am interested in using the Black Scholes calculation on an option
> >which comes due in the current month.
> >
> >By editing the example to hard-code the current month in the today,
> >settlement, and exercise date fields I get the following error in
> >blackvariancesurface.cpp:55:
> >
> >QuantLib::BlackVarianceSurface::BlackVarianceSurface(const
> >QuantLib::Date&, const std::vector<QuantLib::Date,
> >std::allocator<QuantLib::Date> >&, const std::vector<Time,
> >std::allocator<Time> >&, const QuantLib::Matrix&,
> >QuantLib::BlackVarianceSurface::Extrapolation,
> >QuantLib::BlackVarianceSurface::Extrapolation, const
> >QuantLib::DayCounter&): dates must be sorted unique!
>
> Robert,
>          the error is raised during the instantiation of the
> BlackVarianceSurface. If you're not using it (i.e., if you're using a flat
> volatility as in the example) you can safely comment its construction out.
>
> If you want to keep it, the problem is the one reported---"dates must be
> sorted unique", i.e., must be sorted and without duplicates. You can try
> and print out the dates you're passing to the surface to see whether they
> satisfy the requirement. For instance,
>
> dates[0] = settlementDate.plusMonths(1);
> dates[1] = exerciseDate;
>
> are guaranteed to be unsorted if the exercise is closer than one month.
> Also, I think that dates[0] must be strictly later than the settlement.
>
> But really, if a flat volatility is enough for you, just comment out the
> BlackVarianceSurface thing. It is there only because Nando is a pack rat :)
>
> Later,
>          Luigi
>