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

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

Luigi, forget this, its wrong. I am breaking the test suite. I'll try to give it
another look when I find the time. Too bad is going to 1.0 like that.
Regards
Pepe

Quoting Jose Aparicio-Navarro <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"
> >
> >
> >
>
>
>