|
From: Klaus S. <kl...@sp...> - 2007-12-02 17:20:46
|
Hi Gary, Luigi, the dependency of the test case on today's date is introduced by the day counter Act360. In addition I used only 500 antithetic samplings to keep the runtime short... seems that it was too short for a valid error calculation;-) Everything is okay using e.g. gcc 4.0.1 and a 4 (or even 100) times larger statistics. The dependency on the gcc compiler version is more subtle. I get the same error messages using 500 samples and 4.0.1 whereas gcc 4.2.1 gives no error at all. The root of the difference is the routine rankReducedSqrt(Matrix& m, ...) which is needed to calculate the Monte-Carlo paths. The solution is not unique, e.g. the sign of the result might differ. Both results for gcc 4.0.1 and 4.2.1 are numerically correct but differ with respect to the sign. Therefore one gets different MC paths and by accident 4.0.1 is failing today to fulfill the error bounds when using only 500 paths. Luigi, I have relaxed the error bounds for some of the tests to avoid bothersome error logs. Should we put this into 0.9 (?). On Saturday 01 December 2007 21:58:12 Luigi Ballabio wrote: > On Dec 1, 2007, at 8:58 PM, Gary Kennedy wrote: > > I am also seeing some test fails relating HybridHestonHullWhiteProcess. > > I'm using Suse10.0 with boost 1.33.1, gcc 4.0.2 > > Gary, > did you run them today (Saturday?) If so, it might have to do with > today being a holiday. I'll look into this in the next days. > > Thanks, > Luigi > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > QuantLib-dev mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev -- Klaus Spanderen Ludwig Erhard Str. 12 48734 Reken (Germany) EMail: kl...@NO... (remove NOSPAM from the address) |