[Quantlib-dev] heterogeneous stcdo engine

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

Hi all,
Someone was asking for this a few weeks ago. Can anyone please
upload it to experimental?
Roland, I also need help on how to modify the copula, can we look into this?

The engine can be used in two ways, with a single correlation number and only
one copula for all the name pairs or with a name to name correlation matrix.

The code I am sending corresponds to the single number case as it is.
If you want the name to name correlation case you need to patch the existing
copula and add a method to change the correlation. This method is just a
dirty trick to make it work and cannot be a final solution since it breaks
the handle and the registration mechanism to all observers of the handle.
aybe we should have an overloaded interface (conditionalProbability, etc)
that receives a correlation value (Real).
Also you should enable the call to this patch in the pricer; this is,
uncomment the line (#130):

                copula_->resetCorrelation(oneFactorCorrels_[iName]);

in method : RecursiveCdoEngine::expectedConditionalLoss(const Date& date,
                                     Real mktFactor) const

and use the matrix constructor.

patch then the base one factor copula class with this dreadful code:

        void resetCorrelation(Real newCorrel) {
            unregisterWith(correlation_);
            correlation_.linkTo(boost::shared_ptr<Quote>(new
                SimpleQuote(newCorrel)));
            registerWith(correlation_);
            // problem: on BC pricings I am going to call ths often
            //          and theres a new
            // problem: I have just broken the update mechanism with
            //          the original handle
        }

Ill wait to get this point clear to decide wether the first constructor needs
to register the object with the copula. Typically a single factor correlation
would be coming from an index tranche quote and in that case changes would
need propagation.

--

There is one more question with the initialize method coming from the
base engine, it is explained in a code comment.

I am sorry I am not provinding test client code this time; since the amount
of data for this engine is quite large I have been driving it from a
worksheet. In the limit of uniform curves and RRs it converges quite well
to Rolands LHP implementation.

Another point is I have patched the tranche base engines where they compute
the NPV of flows ( calculate() ) once we have the ELs, I might be wrong but
it looks like the sense of the legs are both receiving the flows so we end
up with the same sign.

The integral in the expected tranche loss method calls a boost::bind that
needs a fairly recent version of the library. I jumped three versions and
have 1.37.0...eer, I do not remeber which one I had before... it did not
work for that one. It has to be the one able to bind to member functions.

Regards
Pepe