Re: [Quantlib-dev] Fwd: Re: [Quantlib-users] CreditDefaultSwap throws RuntimeError

[Jose Aparicio-N. <ja...@fr...>]

Sorry I left this behind. I gave it another thought and I was missing the
situation where the yieldRef date is within one period and the probRef on a
later one.

As a reminder the problem might arise on certain ordering combinations of the
yield and default probability curves reference dates within a schedule.
Intermediate times are defined in a way that might lead to request
probabilities or DFs before the ref dates.

In the midpoint we request probs at the end points of the coupon and DFs at
those plus the default time (midpoint). In the integral we request probs and DFs
at integrations points.

So the midpoint needs:
1.- T_midP  >= refYield
2.- T_effStart >= refYield  <-guaranteed by hasOccurred and def. of effStart
3.- T_end   >= refYield  <-guaranteed by the hasOccurred on the coupon
4.- T_effstart >= refProb
5.- T_end   >= refProb

1.- If today >=refYield this point is guaranteed. It is the mid-point within
the fraction of the interval in the future ('future' defined by the yield ref
date). So it could be before the proba curve ref date. This does not pose a
technical problem since we do not request probabilities at that mid point.
Might pose conscientiousness problems having the default time before prob=1
though. The probRef might be a few coupon periods ahead.

So redefinging:
   87     Date effectiveStartDate =
   88         (startDate <= settlementDate && settlementDate <= endDate) ?
                     settlementDate : startDate;
does the trick.

In general, rather than defining a few extra times as I was saying in previous
posts we could have require arguments_.leg[i]->hasOccurred(refProbDate) on top
of the settlement.....which might leave behind coupons that have not yet
occurred from the Yield point of view.

Or we can require refYield >= refProb to hold; I can make sense of this
situation in terms of the meaning of the probabilities but not of the reverse.
This would seem to address the new CDS convention definitions where
one has partial information today on whether the name has defaulated already,
but thats not what I want to solve now. This inforces 4 & 5 with the current
code.

I would go for this last one, at least is simple, what do you think?

Things are similar for the integration engine.

All this logic might need to be reviewed when the new conventions for the CDS
contracts (the lookback protection in this case) are implemented but thats a
different problem.

Regards
Pepe

PS: I admit you woke me up with the previous mail, but this does not
mean I am sending this for any particular version.

Quoting Luigi Ballabio <lui...@gm...>:

> On Mon, 2009-10-05 at 11:31 +0200, Jose Aparicio-Navarro wrote:
> > Quoting Luigi Ballabio <lui...@gm...>:
> > Yep, lets make it the TS ref date. Moving this
> >
> > Date effectiveStartDate =
> >    (startDate <= today && today <= endDate) ? today : startDate;
> >
> > into:
> >
> > Date effectiveStartDate =
> >     (startDate <= settlementDate && settlementDate <= endDate) ?
> >         settlementDate : startDate;
> >
> > works for both cds engines.
>
> Except I'd leave the start date alone and correct the default date
> instead, if possible. No?
>
> Luigi
>
>
> --
>
> There is no opinion so absurd that some philosopher will not
> express it.
> -- Marcus Tullius Cicero, "Ad familiares"
>
>
>