You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(17) 

2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(23) 
2002 
_{Jan}
(18) 
_{Feb}
(20) 
_{Mar}
(22) 
_{Apr}
(41) 
_{May}
(28) 
_{Jun}
(25) 
_{Jul}
(10) 
_{Aug}
(7) 
_{Sep}
(5) 
_{Oct}
(20) 
_{Nov}
(13) 
_{Dec}
(11) 
2003 
_{Jan}
(28) 
_{Feb}
(5) 
_{Mar}
(6) 
_{Apr}
(5) 
_{May}
(17) 
_{Jun}
(6) 
_{Jul}
(45) 
_{Aug}
(35) 
_{Sep}
(24) 
_{Oct}
(50) 
_{Nov}
(53) 
_{Dec}
(6) 
2004 
_{Jan}
(4) 
_{Feb}
(10) 
_{Mar}
(52) 
_{Apr}
(46) 
_{May}
(8) 
_{Jun}
(25) 
_{Jul}
(12) 
_{Aug}
(6) 
_{Sep}
(8) 
_{Oct}
(8) 
_{Nov}
(9) 
_{Dec}
(7) 
2005 
_{Jan}
(18) 
_{Feb}
(60) 
_{Mar}
(19) 
_{Apr}
(26) 
_{May}
(14) 
_{Jun}
(27) 
_{Jul}
(8) 
_{Aug}
(15) 
_{Sep}
(19) 
_{Oct}
(53) 
_{Nov}
(20) 
_{Dec}
(23) 
2006 
_{Jan}
(16) 
_{Feb}
(27) 
_{Mar}
(33) 
_{Apr}
(51) 
_{May}
(36) 
_{Jun}
(25) 
_{Jul}
(54) 
_{Aug}
(30) 
_{Sep}
(25) 
_{Oct}
(67) 
_{Nov}
(43) 
_{Dec}
(13) 
2007 
_{Jan}
(23) 
_{Feb}
(27) 
_{Mar}
(55) 
_{Apr}
(79) 
_{May}
(60) 
_{Jun}
(66) 
_{Jul}
(46) 
_{Aug}
(30) 
_{Sep}
(90) 
_{Oct}
(49) 
_{Nov}
(85) 
_{Dec}
(74) 
2008 
_{Jan}
(68) 
_{Feb}
(59) 
_{Mar}
(64) 
_{Apr}
(28) 
_{May}
(66) 
_{Jun}
(35) 
_{Jul}
(73) 
_{Aug}
(76) 
_{Sep}
(65) 
_{Oct}
(46) 
_{Nov}
(41) 
_{Dec}
(19) 
2009 
_{Jan}
(46) 
_{Feb}
(90) 
_{Mar}
(51) 
_{Apr}
(104) 
_{May}
(13) 
_{Jun}
(24) 
_{Jul}
(20) 
_{Aug}
(39) 
_{Sep}
(109) 
_{Oct}
(101) 
_{Nov}
(117) 
_{Dec}
(57) 
2010 
_{Jan}
(55) 
_{Feb}
(42) 
_{Mar}
(39) 
_{Apr}
(22) 
_{May}
(33) 
_{Jun}
(41) 
_{Jul}
(25) 
_{Aug}
(52) 
_{Sep}
(75) 
_{Oct}
(60) 
_{Nov}
(62) 
_{Dec}
(52) 
2011 
_{Jan}
(70) 
_{Feb}
(31) 
_{Mar}
(26) 
_{Apr}
(28) 
_{May}
(17) 
_{Jun}
(38) 
_{Jul}
(51) 
_{Aug}
(35) 
_{Sep}
(27) 
_{Oct}
(35) 
_{Nov}
(10) 
_{Dec}
(20) 
2012 
_{Jan}
(21) 
_{Feb}
(29) 
_{Mar}
(13) 
_{Apr}
(37) 
_{May}
(33) 
_{Jun}
(12) 
_{Jul}
(34) 
_{Aug}
(27) 
_{Sep}
(29) 
_{Oct}
(35) 
_{Nov}
(58) 
_{Dec}
(27) 
2013 
_{Jan}
(27) 
_{Feb}
(16) 
_{Mar}
(40) 
_{Apr}
(16) 
_{May}
(34) 
_{Jun}
(37) 
_{Jul}
(6) 
_{Aug}
(3) 
_{Sep}
(4) 
_{Oct}
(49) 
_{Nov}
(13) 
_{Dec}
(12) 
2014 
_{Jan}
(15) 
_{Feb}
(21) 
_{Mar}
(11) 
_{Apr}
(13) 
_{May}
(27) 
_{Jun}
(60) 
_{Jul}
(19) 
_{Aug}
(29) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(15) 
2015 
_{Jan}
(33) 
_{Feb}
(29) 
_{Mar}
(26) 
_{Apr}
(17) 
_{May}
(2) 
_{Jun}
(13) 
_{Jul}
(21) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2

3

4

5
(1) 
6

7
(3) 
8

9

10
(1) 
11
(3) 
12
(1) 
13
(2) 
14
(3) 
15

16
(1) 
17

18
(2) 
19
(1) 
20

21
(1) 
22

23
(2) 
24
(3) 
25

26

27
(6) 
28
(3) 
29

30

31






From: Jorge Nieves <jorge.nieves@mo...>  20100528 14:24:33

Ok.. I will take a look in detail tonight. Jorge Nieves Moore Capital Telephone 212.782.7083 Fax 212.642.7644 Original Message From: Joseph Wang [mailto:joequant@...] Sent: Friday, May 28, 2010 10:01 AM To: Jorge Nieves Cc: quantlibdev@...; Dirk Eddelbuettel; Jeff Ryan; rsigfinance@...; balakrishnan.ilango@... Subject: Re: [RSIGFinance] talib & quantlib libraries for R The first thing is to check out QuantlibSWIG from https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk/QuantLibSWIG/ and build the R bindings. There are build instructions in the distribution and test examples. Once you have that done it's a matter of looking at the .hpp file of the objects you want to bind. Find a similar object in the SWIG directory and then transform the .hpp declaration adding it to the file SWIG/inflation.i For example what I did to create the inflation collar instruments is that I cut and paste the noninflation collar instruments and then modified the signatures to match the .hpp files. The one thing that I might have to rework is how Seasonality is written so that it gets passed around using boost shared pointers. On Fri, May 28, 2010 at 9:48 AM, Jorge Nieves <jorge.nieves@...> wrote: > If you explain me the process, I think I can help. > > > Jorge Nieves > > > Original Message > From: Joseph Wang [mailto:joequant@...] > Sent: Friday, May 28, 2010 09:47 AM > To: Jorge Nieves > Cc: quantlibdevel@...; Dirk Eddelbuettel; Jeff > Ryan; rsigfinance@...; > balakrishnan.ilango@... > Subject: Re: [RSIGFinance] talib & quantlib libraries for R > > I just checked in a file inflation.i into QuantlibSWIG which provides > bindings for some of the inflation based instruments. It's very sparse. > I'll try to add the other instruments over time, but it's likely to be > slow to add (i.e. a few weeks), but if there are any volunteers that > would want to add to the file, let me know and I'll check in any > additions. > > What needs to be done is pretty mechanical (cut and paste) things. > 
From: Joseph Wang <joequant@gm...>  20100528 14:01:09

The first thing is to check out QuantlibSWIG from https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk/QuantLibSWIG/ and build the R bindings. There are build instructions in the distribution and test examples. Once you have that done it's a matter of looking at the .hpp file of the objects you want to bind. Find a similar object in the SWIG directory and then transform the .hpp declaration adding it to the file SWIG/inflation.i For example what I did to create the inflation collar instruments is that I cut and paste the noninflation collar instruments and then modified the signatures to match the .hpp files. The one thing that I might have to rework is how Seasonality is written so that it gets passed around using boost shared pointers. On Fri, May 28, 2010 at 9:48 AM, Jorge Nieves <jorge.nieves@...> wrote: > If you explain me the process, I think I can help. > > > Jorge Nieves > > > Original Message > From: Joseph Wang [mailto:joequant@...] > Sent: Friday, May 28, 2010 09:47 AM > To: Jorge Nieves > Cc: quantlibdevel@...; Dirk Eddelbuettel; Jeff Ryan; > rsigfinance@...; balakrishnan.ilango@... > Subject: Re: [RSIGFinance] talib & quantlib libraries for R > > I just checked in a file inflation.i into QuantlibSWIG which provides > bindings for some of the inflation based instruments. It's very sparse. > I'll try to add the other instruments over time, but it's likely to be > slow to add (i.e. a few weeks), but if there are any volunteers that > would want to add to the file, let me know and I'll check in any > additions. > > What needs to be done is pretty mechanical (cut and paste) things. > 
From: Luigi Ballabio <luigi.ballabio@gm...>  20100528 08:55:26

On Thu, 20100527 at 10:04 0700, Javit Hafizoglu wrote: > I believe Luigi forgot to change the generalized HW code when he made the > change in the parameter class to include the positive constraint. Yes, possibly. > Your point for the "size()" vs "size()+1" is valid. > Luigi, please let me know if you would like me to get involved also. Yes, please. If you could correct the size issue and check that the trunk version calibrates correctly, that would be great. Thanks, Luigi  Ogden's Law: The sooner you fall behind, the more time you have to catch up. 
From: Alexander Lotter <alexander.lotter@go...>  20100527 17:56:56

Hello Javit, I used this setting: TimeGrid grid(times.begin(), times.end(), 1); // defining the models boost::shared_ptr<G2> modelG2(new G2(rhTermStructure)); boost::shared_ptr<HullWhite> modelHW(new HullWhite(rhTermStructure)); boost::shared_ptr<HullWhite> modelHW2(new HullWhite(rhTermStructure)); boost::shared_ptr<BlackKarasinski> modelBK( new BlackKarasinski(rhTermStructure)); // GHW model  std::vector<Date> GHWdates; GHWdates.push_back(calendar.advance(settlementDate,0,Years)); GHWdates.push_back(calendar.advance(settlementDate,12,Months,floatingLegConvention)); GHWdates.push_back(calendar.advance(settlementDate,73,Months,floatingLegConvention)); std::vector<Real> a(3, 0.04); std::vector<Real> sigma(3, 0.1); boost::shared_ptr<GeneralizedHullWhite> generalizedHWmodel( new GeneralizedHullWhite(rhTermStructure, GHWdates, GHWdates, a, sigma)); Please correct me, if I've forgotten something. Cheers Alexander Javit Hafizoglu wrote: > > Alexander, > > I believe Luigi forgot to change the generalized HW code when he made the > change in the parameter class to include the positive constraint. Your > point for the "size()" vs "size()+1" is valid. > > I didn't notice anything because I still use the older version of GHW with > quantlib 9.7. > > Per the tests, I tested the GHW code and it worked when I submitted. I ran > my tests by adding couple of lines into BermudanSwaption.cpp I used only > two timepoints for the volatility and the reversion parameters. It takes > significantly long if you include more time points. I would suggest both > decreasing the timegrid and the timepoints (let me know if you don't > understand what I meant here by timepoints) to decrease the optimization > time. And once optimized, initiate your next search with the most recent > model parameters. > > Luigi, please let me know if you would like me to get involved also. > > Thank you, > Javit > > > > Alexander Lotter wrote: >> >> Hello Luigi, >> >> thanks for the quick reply. >> >>>The PiecewiseConstantParameter class was modified in revision 17224 to >>>take an optional constraint, so that's taken care of; the code in the >>>trunk instantiates it with a PositiveConstraint. >> >> I am not sure this is enough. This peace of code in QL causes problems: >> >>  >> PiecewiseConstantParameter(const std::vector<Time>& times, >> const Constraint& constraint = >> >> NoConstraint()) >> : Parameter(times.size()+1, >> boost::shared_ptr<Parameter::Impl>( >> new >> PiecewiseConstantParameter::Impl(times)), >> constraint) >> {} >>  >> >> should be >> >>  >> public: >> PiecewiseConstantParameter(const std::vector<Time>& times, >> const Constraint& constraint = >> >> NoConstraint()) >> : Parameter(times.size(), >>  >> >> times.size() not times.size() + 1, in this case I get run time exception >> in the following functions >> >>  >> >> boost::function<Real (Time)> GeneralizedHullWhite::speed() const { >> >> std::vector<Real> speedvals; >> speedvals.push_back(a_(0.0001)); >> for (Size i=0;i<a_.size()1;i++) >> speedvals.push_back( >> a_( >> (speedstructure_[i+1]speedstructure_[0])/365.0 >>  0.00001)); >> >> return PiecewiseLinearCurve(speedperiods_, speedvals); >> } >> >> boost::function<Real (Time)> GeneralizedHullWhite::vol() const { >> >> std::vector<Real> volvals; >> volvals.push_back(sigma_(0.0001)); >> for (Size i=0;i<sigma_.size()1;i++) >> volvals.push_back( >> sigma_( >> (speedstructure_[i+1]speedstructure_[0])/365.0 >>  0.00001)); >> >> return PiecewiseLinearCurve(volperiods_, volvals); >> } >>  >> >> vector subscript out of range >> >> a_.size()  1 and sigma_.size()  1 are bigger than speedstructure_[i+1] >> >> > >  View this message in context: http://old.nabble.com/GeneralizedHullWhitemodelproblemstp28647789p28697741.html Sent from the quantlibdev mailing list archive at Nabble.com. 
From: Javit Hafizoglu <ch5kd@vi...>  20100527 17:04:10

Alexander, I believe Luigi forgot to change the generalized HW code when he made the change in the parameter class to include the positive constraint. Your point for the "size()" vs "size()+1" is valid. I didn't notice anything because I still use the older version of GHW with quantlib 9.7. Per the tests, I tested the GHW code and it worked when I submitted. I ran my tests by adding couple of lines into BermudanSwaption.cpp I used only two timepoints for the volatility and the reversion parameters. It takes significantly long if you include more time points. I would suggest both decreasing the timegrid and the timepoints (let me know if you don't understand what I meant here by timepoints) to decrease the optimization time. And once optimized, initiate your next search with the most recent model parameters. Luigi, please let me know if you would like me to get involved also. Thank you, Javit Alexander Lotter wrote: > > Hello Luigi, > > thanks for the quick reply. > >>The PiecewiseConstantParameter class was modified in revision 17224 to >>take an optional constraint, so that's taken care of; the code in the >>trunk instantiates it with a PositiveConstraint. > > I am not sure this is enough. This peace of code in QL causes problems: > >  > PiecewiseConstantParameter(const std::vector<Time>& times, > const Constraint& constraint = > > NoConstraint()) > : Parameter(times.size()+1, > boost::shared_ptr<Parameter::Impl>( > new > PiecewiseConstantParameter::Impl(times)), > constraint) > {} >  > > should be > >  > public: > PiecewiseConstantParameter(const std::vector<Time>& times, > const Constraint& constraint = > > NoConstraint()) > : Parameter(times.size(), >  > > times.size() not times.size() + 1, in this case I get run time exception > in the following functions > >  > > boost::function<Real (Time)> GeneralizedHullWhite::speed() const { > > std::vector<Real> speedvals; > speedvals.push_back(a_(0.0001)); > for (Size i=0;i<a_.size()1;i++) > speedvals.push_back( > a_( > (speedstructure_[i+1]speedstructure_[0])/365.0 >  0.00001)); > > return PiecewiseLinearCurve(speedperiods_, speedvals); > } > > boost::function<Real (Time)> GeneralizedHullWhite::vol() const { > > std::vector<Real> volvals; > volvals.push_back(sigma_(0.0001)); > for (Size i=0;i<sigma_.size()1;i++) > volvals.push_back( > sigma_( > (speedstructure_[i+1]speedstructure_[0])/365.0 >  0.00001)); > > return PiecewiseLinearCurve(volperiods_, volvals); > } >  > > vector subscript out of range > > a_.size()  1 and sigma_.size()  1 are bigger than speedstructure_[i+1] > >  View this message in context: http://old.nabble.com/GeneralizedHullWhitemodelproblemstp28647789p28697165.html Sent from the quantlibdev mailing list archive at Nabble.com. 
From: Allen Kuo <allen_kuo@ya...>  20100527 16:26:39

Chris: At the time we had this idea (see email below), but then we nixed it and went for the longer version, with the idea we'd eventually try to relook at the problem. If you do refactor, I think you'll need to create a DiscretizedFixedRateBond (just like the DiscretizedSwap) and the structures would be parallel. At the time, Luigi noted that knowing the underlying was a Bond was not enough, since fixed and floating rate legs get discounted differently on tree engines. ( I later thought to myself is there really a need for a floating rate callable bond, with little or no interest rate risk ? ) The idea of deriving from option rather than bond is more elegant from the interface perspective (as you know, options are naturally on some sort of underlying and it would be nice to wrap callability around fixed rate bonds and converts and/or whatever instruments) but I think at the time we figured out it would not be feasible underneath it all (I forget why now, perhaps its because of the need to create pretty customized discretized instruments to be rolled back on trees). Maybe you can figure out a way forward now ? I think options on fixed and floating rate Legs are pretty general classes. Also easy ways to transform from Instruments to "DiscretizedInstruments" may help (assuming we're still talking about the tree engines) but I assume that would be deep refactoring of Instrument. Allen On 08/01/2006 09:03:20 AM, Allen Kuo wrote: > I'm trying to build a callable bond class and was wondering what a > QL preferred design would be. Two possibilities are below. I liked > the economy of the first method but the ConvertibleBond class is > designed the second way, so was not sure how to proceed. > > (1) > class CallableBond : public Bond { > public: > CallableBond(const boost::shared_ptr<Bond> bond& > const boost::shared_ptr<PricingEngine>& engine, > const CallabilitySchedule& callability, > ); > etc. > } I like this one, but the problem is that the engine should know what kind of bond it's being passedor at least what kind of coupons it contains. I.e., if you choose a tree engine, fixedrate and floatingrate coupons will be discounted in a different way on the tree. Therefore, the above mightn't be as generic as it seems. > (2) > Analogous to the ConvertibleBond class, we would have three > explicit constructors for each of three types of bonds ( > CallableZeroCouponBond , CallableFloatingRateBond , > CallableFixedCouponBond ). This might be less nice, but it has the advantage of specifying the kind of bond to be called. I would go for this one first; after the code is done, we might try some refactoring to bring it closer to the first design. > Doing it this way, in the future though, we > might need three more constructors for convertible bonds: No, convertible bonds manage callability already. (By the way, you can look at the relevant classesCallability and suchso that you can reuse them.) Later, Luigi ________________________________ From: Chris Kenyon <chris.kenyon@...> To: quantlibdev@...; quantlibusers@... Sent: Thu, May 27, 2010 10:06:38 PM Subject: [Quantlibusers] callable bonds & bond options vs swaptions? Hi, the setup for callable bonds is rather different from swaptions, and maybe it can be improved. Swaption (const boost::shared_ptr< VanillaSwap > &swap, const boost::shared_ptr< Exercise > &exercise, Settlement::Type delivery=Settlement::Physical) ... the Swaption takes a Swap and some data. Swaption is descendant of Option. A callable bond: CallableFixedRateBond (Natural settlementDays, Real faceAmount, const Schedule &schedule, const std::vector< Rate > &coupons, const DayCounter &accrualDayCounter, BusinessDayConvention paymentConvention=Following, Real redemption=100.0, const Date &issueDate=Date(), const CallabilitySchedule &putCallSchedule=CallabilitySchedule()) ... has a complete description and is a descendant of Bond, via CallableBond, not Option. Now, granted, a swaption is an option on a swap and nothing happens before exercise whereas a bond may be paying coupons. However, it would be more parsimonious to copy the swaption definition idea for callable bonds and bond options, e.g. CallableBond(const boost::shared_ptr< Bond > &bond, const CallabilitySchedule &putCallSchedule=CallabilitySchedule()) ... descendant of Bond  and can define Puttable and Callable versions from the Callability vector. N.B. a CallabilitySchedule is a typedef for std::vector<boost::shared_ptr< Callability > > BondOption(const boost::shared_ptr< Bond > &bond, const CallabilitySchedule &putCallSchedule=CallabilitySchedule(), Settlement::Type delivery=Settlement::Physical) ... descendant of Option. N.B. we need a Callability not an Exercise because we need the strike (in a swaption the strike is the fixed rate in the swap). Any comments? This approach could be applied to ConvertibleBond as well. Regards, Chris 
From: Chris Kenyon <chris.kenyon@ya...>  20100527 14:06:45

Hi, the setup for callable bonds is rather different from swaptions, and maybe it can be improved. Swaption (const boost::shared_ptr< VanillaSwap > &swap, const boost::shared_ptr< Exercise > &exercise, Settlement::Type delivery=Settlement::Physical) ... the Swaption takes a Swap and some data. Swaption is descendant of Option. A callable bond: CallableFixedRateBond (Natural settlementDays, Real faceAmount, const Schedule &schedule, const std::vector< Rate > &coupons, const DayCounter &accrualDayCounter, BusinessDayConvention paymentConvention=Following, Real redemption=100.0, const Date &issueDate=Date(), const CallabilitySchedule &putCallSchedule=CallabilitySchedule()) ... has a complete description and is a descendant of Bond, via CallableBond, not Option. Now, granted, a swaption is an option on a swap and nothing happens before exercise whereas a bond may be paying coupons. However, it would be more parsimonious to copy the swaption definition idea for callable bonds and bond options, e.g. CallableBond(const boost::shared_ptr< Bond > &bond, const CallabilitySchedule &putCallSchedule=CallabilitySchedule()) ... descendant of Bond  and can define Puttable and Callable versions from the Callability vector. N.B. a CallabilitySchedule is a typedef for std::vector<boost::shared_ptr< Callability > > BondOption(const boost::shared_ptr< Bond > &bond, const CallabilitySchedule &putCallSchedule=CallabilitySchedule(), Settlement::Type delivery=Settlement::Physical) ... descendant of Option. N.B. we need a Callability not an Exercise because we need the strike (in a swaption the strike is the fixed rate in the swap). Any comments? This approach could be applied to ConvertibleBond as well. Regards, Chris 
From: Nicolai Lassesen <nla.fi@cb...>  20100527 09:30:19

Kakhkhor Abdijalilov <kabdijalilov <at> gmail.com> writes: > > Bug Report: > > Where: In "normaldistribution.cpp". > What: Undefined behavior or floating point exception. > Severity: Subtle. > Burden: Easy to fix. See below. > > Description. > If the argument x is close to 0.0 or 1.0, the implementation sets it > exactly to 0.0 or 1.0. > This leads to an attempt to evaluate std::log(0.0) or std::log(1.0). > I propose that we cut it at x=1E12 and x = 1  1E12, which covers > all draws between > plus/minus 7 standard deviations. Any argument value beyond that range > should be considered > as either erroneous or astronomically improbable. > > Regards, > Kakhkhor Abdijalilov. I am currently looking into replacing the Quantlib implementation of statistical distributions with the implementation provided by Boost. The best solution (in my opinion anyway) would be to get totally rid of the Quantlib distribution folder and rely totally on Boost  this would eliminate a layer of indirection but it would break backward compatibility. Therefore I have currently just replaced the internal parts of the Quantlib normaldistribution.xpp with the Boost implementation. Unfortunately these makes some testcases fail, and I am currently looking into why this can be. If someone is interested I can post my modified normaldistribution.xpp files here. Br, Nicolai 
From: Kakhkhor Abdijalilov <kabdijalilov@gm...>  20100527 06:59:17

Bug Report: Where: In "normaldistribution.cpp". What: Undefined behavior or floating point exception. Severity: Subtle. Burden: Easy to fix. See below. Description. If the argument x is close to 0.0 or 1.0, the implementation sets it exactly to 0.0 or 1.0. This leads to an attempt to evaluate std::log(0.0) or std::log(1.0). I propose that we cut it at x=1E12 and x = 1  1E12, which covers all draws between plus/minus 7 standard deviations. Any argument value beyond that range should be considered as either erroneous or astronomically improbable. Regards, Kakhkhor Abdijalilov. ============================================================= // current implementation Real InverseCumulativeNormal::operator()(Real x) const { if (x < 0.0  x > 1.0) { // try to recover if due to numerical error if (close_enough(x, 1.0)) { x = 1.0; } else if (std::fabs(x) < QL_EPSILON) { x = 0.0; } else { QL_FAIL("InverseCumulativeNormal(" << x << ") undefined: must be 0 < x < 1"); } } ......................................... } // new implementation Real InverseCumulativeNormal::operator()(Real x) const { if (x < 1e12  x > (1.0  1e12)) { // try to recover if due to numerical error if (close_enough(x, 1.0)) { x = 1.0  1e12; } else if (std::fabs(x) < QL_EPSILON) { x = 1e12; } else { QL_FAIL("InverseCumulativeNormal(" << x << ") undefined: must be 0 < x < 1"); } } ......................................... } 
From: Alexander Lotter <alexander.lotter@go...>  20100524 18:22:54

After this changes I get the project run, but calibration never returns... Playing with TimeGrid didn't help.  View this message in context: http://old.nabble.com/GeneralizedHullWhitemodelproblemstp28647789p28659989.html Sent from the quantlibdev mailing list archive at Nabble.com. 
From: Alexander Lotter <alexander.lotter@go...>  20100524 18:20:23

Hello Luigi, thanks for the quick reply. >The PiecewiseConstantParameter class was modified in revision 17224 to >take an optional constraint, so that's taken care of; the code in the >trunk instantiates it with a PositiveConstraint. I am not sure this is enough. This peace of code in QL causes problems:  PiecewiseConstantParameter(const std::vector<Time>& times, const Constraint& constraint = NoConstraint()) : Parameter(times.size()+1, boost::shared_ptr<Parameter::Impl>( new PiecewiseConstantParameter::Impl(times)), constraint) {}  should be  public: PiecewiseConstantParameter(const std::vector<Time>& times, const Constraint& constraint = NoConstraint()) : Parameter(times.size(),  times.size() not times.size() + 1, in this case I get run time exception in the following functions  boost::function<Real (Time)> GeneralizedHullWhite::speed() const { std::vector<Real> speedvals; speedvals.push_back(a_(0.0001)); for (Size i=0;i<a_.size()1;i++) speedvals.push_back( a_( (speedstructure_[i+1]speedstructure_[0])/365.0  0.00001)); return PiecewiseLinearCurve(speedperiods_, speedvals); } boost::function<Real (Time)> GeneralizedHullWhite::vol() const { std::vector<Real> volvals; volvals.push_back(sigma_(0.0001)); for (Size i=0;i<sigma_.size()1;i++) volvals.push_back( sigma_( (speedstructure_[i+1]speedstructure_[0])/365.0  0.00001)); return PiecewiseLinearCurve(volperiods_, volvals); }  vector subscript out of range a_.size()  1 and sigma_.size()  1 are bigger than speedstructure_[i+1]  View this message in context: http://old.nabble.com/GeneralizedHullWhitemodelproblemstp28647789p28659965.html Sent from the quantlibdev mailing list archive at Nabble.com. 
From: Luigi Ballabio <luigi.ballabio@gm...>  20100524 16:05:22

On Sun, 20100523 at 01:27 0700, Alexander Lotter wrote: > Hello Javit, > > I found the Generalized HullWhite model checked by Luigi into the trunk a > couple of months ago. > > As you told me, the newest version was (see .zip file): > http://old.nabble.com/GeneralizedHullWhitemodelwithnonconstantparameterstd26287370.html#a26635940 > > The last version in trunk on sourceforge as far as I know 17226. This > version have some differences to the version you posted in that archive in > december 2009. Yes. The differences are meant to be. > There is also no examples in the current trunk of the QuantLib, which > contains your version of BermudanSwaptions or some code for the testsuite. True, for some reason the example didn't make into the commit. I remember it working, though. > There is no a version of PiecewiseConstantParameter2 as you proposed to > implement. So, without this change, I couldn't get the current trunk version > to run without runtime error (vector subscript out of range). As I added > this class, I got the current version to run, but calibration took me too > long to wait. The PiecewiseConstantParameter class was modified in revision 17224 to take an optional constraint, so that's taken care of; the code in the trunk instantiates it with a PositiveConstraint. Anyway, I'll try to get the example working and get back. Luigi  Don't let school get in the way of your education.  Mark Twain 
From: Luigi Ballabio <luigi.ballabio@gm...>  20100523 18:03:22

On May 21, 2010, at 5:54 PM, Irakli Machabeli wrote: > Sorry for stupid question but what is the link for ql swig? From the download page on Sourceforge (<http://sourceforge.net/projects/quantlib/files/ >) expand the "QuantLib" folder, then "1.0", then "bindings". Luigi 
From: Alexander Lotter <alexander.lotter@go...>  20100523 08:27:52

Hello Javit, I found the Generalized HullWhite model checked by Luigi into the trunk a couple of months ago. As you told me, the newest version was (see .zip file): http://old.nabble.com/GeneralizedHullWhitemodelwithnonconstantparameterstd26287370.html#a26635940 The last version in trunk on sourceforge as far as I know 17226. This version have some differences to the version you posted in that archive in december 2009. There is also no examples in the current trunk of the QuantLib, which contains your version of BermudanSwaptions or some code for the testsuite. There is no a version of PiecewiseConstantParameter2 as you proposed to implement. So, without this change, I couldn't get the current trunk version to run without runtime error (vector subscript out of range). As I added this class, I got the current version to run, but calibration took me too long to wait. To be simple: trunk version (quick check http://quantlib.svn.sourceforge.net/viewvc/quantlib/trunk/QuantLib/ql/experimental/shortrate/) generalizedhullwhite.cpp ... a_ = PiecewiseConstantParameter(speedperiods_, PositiveConstraint()); ... your version in the zip file a_ = PiecewiseConstantParameter2(speedperiods_, PositiveConstraint()); I reduced the TimeGrid from 30 to 1 as you proposed (see your BermudanSwaption example): // Building timegrid TimeGrid grid(times.begin(), times.end(), 1); The calibration still take too long, never comes back. I get stuck here on calibrateModel:  std::cout << "Generalized HullWhite calibration" << std::endl; for (i=0; i<swaptions.size(); i++) swaptions[i]>setPricingEngine(boost::shared_ptr<PricingEngine>( new TreeSwaptionEngine(generalizedHWmodel, grid))); calibrateModel(generalizedHWmodel, swaptions);  I tried // Building timegrid TimeGrid grid(times.begin(), times.end(), 30); as well as // Building timegrid TimeGrid grid(times.begin(), times.end(), 1); Any suggestions? I would like to assist on this issues and get the trunk version to work properly. We could also add the sample to the BermudanSwaption and testsuite as well. Please correct me if I missed something. Take care Alex  View this message in context: http://old.nabble.com/GeneralizedHullWhitemodelproblemstp28647789p28647789.html Sent from the quantlibdev mailing list archive at Nabble.com. 
From: Irakli Machabeli <imatchabelli@ho...>  20100521 15:54:35

Sorry for stupid question but what is the link for ql swig? 
From: SourceForge.net <noreply@so...>  20100519 11:28:31

Bugs item #3004009, was opened at 20100519 13:28 Message generated for change (Tracker Item Submitted) made by wasix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3004009&group_id=12740 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wasi (wasix) Assigned to: Nobody/Anonymous (nobody) Summary: Excel function qlFixedRateBondHelper is deprecated Initial Comment: Problem: The Excel function qlFixedRateBondHelper in QuantlibXL Version 1.0b3 produces an error messsage: "qlFixedRateBondHelper  Boost assertion failed: px != 0" which is due to an uninitialized bond parameter in the BondHelper constructor. Solution: The function qlfixedratebondhelper is deprecated and will or should be removed in the coming version. The new function is qlBondHelper. One can create a fixed rate bond using qlFixedRateBond and forward this object to qlBondHelper. This should be the same financial construct.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3004009&group_id=12740 
From: SourceForge.net <noreply@so...>  20100518 08:15:01

Patches item #3003152, was opened at 20100518 10:15 Message generated for change (Tracker Item Submitted) made by kimtang You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3003152&group_id=12740 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kim Tang (kimtang) Assigned to: Nobody/Anonymous (nobody) Summary: Array.hpp extension with a typedef for size_type Initial Comment: Hi all, since class Array is there to model a sequence, it should also provide a size_type to indicate the return_type of the member function size(). This is also often needed to write generic algorithm with sequences as input.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3003152&group_id=12740 
From: SourceForge.net <noreply@so...>  20100518 07:01:09

Patches item #3003124, was opened at 20100518 09:01 Message generated for change (Tracker Item Submitted) made by kimtang You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3003124&group_id=12740 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kim Tang (kimtang) Assigned to: Nobody/Anonymous (nobody) Summary: Array.hpp extension with a typedef for size_type Initial Comment: Hi all, since class Array is there to model a sequence, it should also provide a size_type to indicate the return_type of the member function size(). This is also often needed to write generic algorithm with sequences as input.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3003124&group_id=12740 
From: Kakhkhor Abdijalilov <kabdijalilov@gm...>  20100516 22:05:42

Both versions are equivalent, because default constractor for numeric types is equivalent to setting to 0. But in the final version of the code it doesn't matter, since x is overwritten through assignment inside the nested loop. On Sat, May 15, 2010 at 5:10 PM, Klaus Spanderen <klaus@...> wrote: > Hi > > short question, shouldn't it be > std::vector<Size> x(dim, 0u); > instead of > std::vector<Size> x(dim); > > I guess C++ vector aren't initialized by zero by default(?) > > regards > Klaus > > On Friday 14 May 2010 03:30:19 Kakhkhor Abdijalilov wrote: >> It seems that increasing the threshold in std::find_if algorithm >> doesn't solve the problem. I tried it with very high threshold and >> there are still many more basis functions than needed. The basis set >> size is the same as it is reported in my original message. I guess >> "removeozap" works correctly, but something else goes wrong. The >> correct number of basis functions should be (Dim+Order1)! / [ >> (Dim1)! * Order!] and it shouldn't depend on polynomial type. >> >> To fix the problem I implemented different basis generation algorithm >> which is described below. >> >> The idea is to build multifactor basis set by multiplying together >> single factor basis functions. >> Let's say we have the single factor basis: >> >> F_0(.), F_1(.), F_2(.),... >> >> and we want to build a 3dimensional basis set. In order to build the >> order N basis set, we need all terms of the type >> F_i(x)*F_j*(y)*F_k(z) such that i+j+k <= N. We first compute all >> tuples (i, j, k) such that i+j+k <= N and then generate the basis set >> from those tuples. This would avoid duplicates if the tuple set >> contains only unique elements. The required tuple set can be generated >> by the following induction algorithm: >> >> Assume that we have all order N (i.e. i+j+k = N) tuples. In order to >> build order N+1 tuples do the following: >> 1) Start with the set: (N+1, 0, 0), (0, N+1, 0), (0, 0, N+1). >> 2) For each tuple (i, j, k) from the order N set add the tuples (i+1, >> j, k), (i, j+1, k+2) to the order N+1 set. >> 3) Remove the duplicates from the order N+1 set. >> >> The resulting order N+1 set will contain all order N+1 tuples. The >> function next_order_tuples implements the induction algorithm. >> Duplicates can be avoided if we use STL container std::set to store >> the tuples. >> >> The code is below. Please feel free to ask any question you might have. >> >> ================================================== >> >> // lsmbasissystem.hpp >> >> #ifndef quantlib_lsm_basis_system_hpp >> #define quantlib_lsm_basis_system_hpp >> >> #include <ql/qldefines.hpp> >> #include <ql/math/array.hpp> >> #include <boost/function.hpp> >> #include <vector> >> >> namespace QuantLib { >> >> class LsmBasisSystem { >> public: >> enum PolynomType { Monomial, Laguerre, Hermite, Hyperbolic, >> Legendre, Chebyshev, Chebyshev2nd }; >> >> static std::vector<boost::function1<Real, Real> > >> pathBasisSystem(Size order, PolynomType polyType); >> >> static std::vector<boost::function1<Real, Array> > >> multiPathBasisSystem(Size dim, Size order, PolynomType polyType); >> }; >> >> >> } // namespace QuantLib >> >> #endif >> >> ================================================== >> >> // lsmbasissystem.hpp >> >> #include <ql/methods/montecarlo/lsmbasissystem.hpp> >> #include <ql/math/functional.hpp> >> #include <ql/math/integrals/gaussianquadratures.hpp> >> #include <boost/bind.hpp> >> #include <set> >> #include <numeric> >> >> namespace QuantLib { >> namespace { >> >> // makes typing a little easier >> typedef std::vector<boost::function1<Real, Real> > VF_R; >> typedef std::vector<boost::function1<Real, Array> > VF_A; >> typedef std::vector<std::vector<Size> > VV; >> Real (GaussianOrthogonalPolynomial::*ptr_w)(Size, Real) const = >> &GaussianOrthogonalPolynomial::weightedValue; >> >> // pow(x, order) >> class MonomialFct : public std::unary_function<Real, Real> { >> public: >> MonomialFct(Size order): order_(order) {} >> inline Real operator()(const Real x) const { >> Real ret = 1.0; >> for(Size i=0; i<order_; ++i) >> ret *= x; >> return ret; >> } >> private: >> const Size order_; >> }; >> >> /* multiplies [Real > Real] functors >> to create [Array > Real] functor */ >> class MultiDimFct : public std::unary_function<Real, Array> { >> public: >> MultiDimFct(const VF_R b): b_(b) { >> QL_REQUIRE(b_.size()>0, "zero size basis"); >> } >> inline Real operator()(const Array& a) const { >> #if defined(QL_EXTRA_SAFETY_CHECKS) >> QL_REQUIRE(b_.size()==a.size(), "wrong argument size"); >> #endif >> Real ret = b_[0].operator()(a[0]); >> for(Size i=1; i<b_.size(); ++i) >> ret *= b_[i].operator()(a[i]); >> return ret; >> } >> private: >> const VF_R b_; >> }; >> >> // constant functor [Real > Real] (returns 1.0) >> class MultiDimConstFct : public std::unary_function<Real, Array> { >> public: >> MultiDimConstFct(Size dim): dim_(dim) { >> QL_REQUIRE(dim>0, "zero dimension"); >> } >> inline Real operator()(const Array& a) const { >> #if defined(QL_EXTRA_SAFETY_CHECKS) >> QL_REQUIRE(dim_==a.size(), "wrong argument size"); >> #endif >> return 1.0; >> } >> private: >> const Size dim_; >> }; >> >> // check size and order of tuples >> void check_tuples(const VV& v, Size dim, Size order) { >> for(Size i=0; i<v.size(); ++i) { >> QL_REQUIRE(dim==v[i].size(), "wrong tuple size"); >> QL_REQUIRE(order==std::accumulate(v[i].begin(), v[i].end(), 0), >> "wrong tuple order"); >> } >> } >> >> // build order N+1 tuples from order N tuples >> VV next_order_tuples(const VV& v) { >> const Size order = std::accumulate(v[0].begin(), v[0].end(), 0); >> const Size dim = v[0].size(); >> >> check_tuples(v, dim, order); >> >> // the set of unique tuples >> std::set<std::vector<Size> > tuples; >> >> for(Size i=0; i<dim; ++i) { >> // order+1 for ith dimension, the rest is 0 >> std::vector<Size> x(dim); >> x[i] += order+1; >> tuples.insert(x); >> // increase ith value in every tuple by 1 >> for(Size j=0; j<v.size(); ++j) { >> x = v[j]; >> x[i] += 1; >> tuples.insert(x); >> } >> } >> >> VV ret(tuples.begin(), tuples.end()); >> return ret; >> } >> >> } // unnamed namespace >> >> // LsmBasisSystem static methods >> >> VF_R LsmBasisSystem::pathBasisSystem(Size order, PolynomType polyType) >> { VF_R ret(order+1); >> for (Size i=0; i<=order; ++i) { >> switch (polyType) { >> case Monomial: >> ret[i] = MonomialFct(i); >> break; >> case Laguerre: >> ret[i] = boost::bind(ptr_w, GaussLaguerrePolynomial(), i, >> _1); break; >> case Hermite: >> ret[i] = boost::bind(ptr_w, GaussHermitePolynomial(), i, >> _1); break; >> case Hyperbolic: >> ret[i] = boost::bind(ptr_w, GaussHyperbolicPolynomial(), i, >> _1); break; >> case Legendre: >> ret[i] = boost::bind(ptr_w, GaussLegendrePolynomial(), i, >> _1); break; >> case Chebyshev: >> ret[i] = boost::bind(ptr_w, GaussChebyshevPolynomial(), i, >> _1); break; >> case Chebyshev2nd: >> ret[i] = boost::bind(ptr_w, >> GaussChebyshev2ndPolynomial(), i, _1); >> break; >> default: >> QL_FAIL("unknown regression type"); >> } >> } >> return ret; >> } >> >> VF_A LsmBasisSystem::multiPathBasisSystem(Size dim, Size order, >> PolynomType polyType) { >> QL_REQUIRE(dim>0, "zero dimension"); >> // constant function >> VF_A ret(1, MultiDimConstFct(dim)); >> // get single factor basis >> VF_R pathBasis = pathBasisSystem(order, polyType); >> // start with all 0 tuple >> VV tuples(1, std::vector<Size>(dim)); >> // add multifactor terms >> for(Size i=1; i<=order; ++i) { >> tuples = next_order_tuples(tuples); >> // now we have all tuples of order i >> // for each tuple add the corresponding term >> for(Size j=0; j<tuples.size(); ++j) { >> VF_R term(dim); >> for(Size k=0; k<dim; ++k) >> term[k] = pathBasis[tuples[j][k]]; >> ret.push_back(MultiDimFct(term)); >> } >> } >> return ret; >> } >> >> } // namespace QuantLib >> >> ============================================================= >> >> On Thu, May 13, 2010 at 6:22 PM, Klaus Spanderen <klaus@...> wrote: >> > Hi >> > >> >> ..The size of basis is not the same for different >> >> polynomial types. >> > >> > I've fixed one issue in the SVN. >> > >> >> .. I reworked the >> >> implementation, so that basis sizes are the same for all polynomial >> >> types and no duplicates are created during the process. I would like >> >> to submit my code to QuantLib, but not sure how to do it. >> > >> > Please submit the code to this mailing list or via email. I'm going to >> > merge it into the SVN. >> > >> > thanks in advance >> > Klaus >> >>  >> >> >> _______________________________________________ >> QuantLibdev mailing list >> QuantLibdev@... >> https://lists.sourceforge.net/lists/listinfo/quantlibdev > > > 
From: Klaus Spanderen <klaus@sp...>  20100514 08:38:21

Hi Using your version I'm getting the following sizes of the basis system. dim = 1: order Mnm Lgr Hrm Hpr Lgn Chb Chb2 0 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 dim = 2: order Mnm Lgr Hrm Hpr Lgn Chb Chb2 0 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 2 6 6 6 6 6 6 6 3 10 10 10 10 10 10 10 4 15 15 15 15 15 15 15 I guess this is what you intended. The smaller basis sets should increase the run time efficiency of the algorithm. best regards Klaus 
From: Kakhkhor Abdijalilov <kabdijalilov@gm...>  20100514 01:52:13

It seems that increasing the threshold in std::find_if algorithm doesn't solve the problem. I tried it with very high threshold and there are still many more basis functions than needed. The basis set size is the same as it is reported in my original message. I guess "removeozap" works correctly, but something else goes wrong. The correct number of basis functions should be (Dim+Order1)! / [ (Dim1)! * Order!] and it shouldn't depend on polynomial type. To fix the problem I implemented different basis generation algorithm which is described below. The idea is to build multifactor basis set by multiplying together single factor basis functions. Let's say we have the single factor basis: F_0(.), F_1(.), F_2(.),... and we want to build a 3dimensional basis set. In order to build the order N basis set, we need all terms of the type F_i(x)*F_j*(y)*F_k(z) such that i+j+k <= N. We first compute all tuples (i, j, k) such that i+j+k <= N and then generate the basis set from those tuples. This would avoid duplicates if the tuple set contains only unique elements. The required tuple set can be generated by the following induction algorithm: Assume that we have all order N (i.e. i+j+k = N) tuples. In order to build order N+1 tuples do the following: 1) Start with the set: (N+1, 0, 0), (0, N+1, 0), (0, 0, N+1). 2) For each tuple (i, j, k) from the order N set add the tuples (i+1, j, k), (i, j+1, k+2) to the order N+1 set. 3) Remove the duplicates from the order N+1 set. The resulting order N+1 set will contain all order N+1 tuples. The function next_order_tuples implements the induction algorithm. Duplicates can be avoided if we use STL container std::set to store the tuples. The code is below. Please feel free to ask any question you might have. ================================================== // lsmbasissystem.hpp #ifndef quantlib_lsm_basis_system_hpp #define quantlib_lsm_basis_system_hpp #include <ql/qldefines.hpp> #include <ql/math/array.hpp> #include <boost/function.hpp> #include <vector> namespace QuantLib { class LsmBasisSystem { public: enum PolynomType { Monomial, Laguerre, Hermite, Hyperbolic, Legendre, Chebyshev, Chebyshev2nd }; static std::vector<boost::function1<Real, Real> > pathBasisSystem(Size order, PolynomType polyType); static std::vector<boost::function1<Real, Array> > multiPathBasisSystem(Size dim, Size order, PolynomType polyType); }; } // namespace QuantLib #endif ================================================== // lsmbasissystem.hpp #include <ql/methods/montecarlo/lsmbasissystem.hpp> #include <ql/math/functional.hpp> #include <ql/math/integrals/gaussianquadratures.hpp> #include <boost/bind.hpp> #include <set> #include <numeric> namespace QuantLib { namespace { // makes typing a little easier typedef std::vector<boost::function1<Real, Real> > VF_R; typedef std::vector<boost::function1<Real, Array> > VF_A; typedef std::vector<std::vector<Size> > VV; Real (GaussianOrthogonalPolynomial::*ptr_w)(Size, Real) const = &GaussianOrthogonalPolynomial::weightedValue; // pow(x, order) class MonomialFct : public std::unary_function<Real, Real> { public: MonomialFct(Size order): order_(order) {} inline Real operator()(const Real x) const { Real ret = 1.0; for(Size i=0; i<order_; ++i) ret *= x; return ret; } private: const Size order_; }; /* multiplies [Real > Real] functors to create [Array > Real] functor */ class MultiDimFct : public std::unary_function<Real, Array> { public: MultiDimFct(const VF_R b): b_(b) { QL_REQUIRE(b_.size()>0, "zero size basis"); } inline Real operator()(const Array& a) const { #if defined(QL_EXTRA_SAFETY_CHECKS) QL_REQUIRE(b_.size()==a.size(), "wrong argument size"); #endif Real ret = b_[0].operator()(a[0]); for(Size i=1; i<b_.size(); ++i) ret *= b_[i].operator()(a[i]); return ret; } private: const VF_R b_; }; // constant functor [Real > Real] (returns 1.0) class MultiDimConstFct : public std::unary_function<Real, Array> { public: MultiDimConstFct(Size dim): dim_(dim) { QL_REQUIRE(dim>0, "zero dimension"); } inline Real operator()(const Array& a) const { #if defined(QL_EXTRA_SAFETY_CHECKS) QL_REQUIRE(dim_==a.size(), "wrong argument size"); #endif return 1.0; } private: const Size dim_; }; // check size and order of tuples void check_tuples(const VV& v, Size dim, Size order) { for(Size i=0; i<v.size(); ++i) { QL_REQUIRE(dim==v[i].size(), "wrong tuple size"); QL_REQUIRE(order==std::accumulate(v[i].begin(), v[i].end(), 0), "wrong tuple order"); } } // build order N+1 tuples from order N tuples VV next_order_tuples(const VV& v) { const Size order = std::accumulate(v[0].begin(), v[0].end(), 0); const Size dim = v[0].size(); check_tuples(v, dim, order); // the set of unique tuples std::set<std::vector<Size> > tuples; for(Size i=0; i<dim; ++i) { // order+1 for ith dimension, the rest is 0 std::vector<Size> x(dim); x[i] += order+1; tuples.insert(x); // increase ith value in every tuple by 1 for(Size j=0; j<v.size(); ++j) { x = v[j]; x[i] += 1; tuples.insert(x); } } VV ret(tuples.begin(), tuples.end()); return ret; } } // unnamed namespace // LsmBasisSystem static methods VF_R LsmBasisSystem::pathBasisSystem(Size order, PolynomType polyType) { VF_R ret(order+1); for (Size i=0; i<=order; ++i) { switch (polyType) { case Monomial: ret[i] = MonomialFct(i); break; case Laguerre: ret[i] = boost::bind(ptr_w, GaussLaguerrePolynomial(), i, _1); break; case Hermite: ret[i] = boost::bind(ptr_w, GaussHermitePolynomial(), i, _1); break; case Hyperbolic: ret[i] = boost::bind(ptr_w, GaussHyperbolicPolynomial(), i, _1); break; case Legendre: ret[i] = boost::bind(ptr_w, GaussLegendrePolynomial(), i, _1); break; case Chebyshev: ret[i] = boost::bind(ptr_w, GaussChebyshevPolynomial(), i, _1); break; case Chebyshev2nd: ret[i] = boost::bind(ptr_w, GaussChebyshev2ndPolynomial(), i, _1); break; default: QL_FAIL("unknown regression type"); } } return ret; } VF_A LsmBasisSystem::multiPathBasisSystem(Size dim, Size order, PolynomType polyType) { QL_REQUIRE(dim>0, "zero dimension"); // constant function VF_A ret(1, MultiDimConstFct(dim)); // get single factor basis VF_R pathBasis = pathBasisSystem(order, polyType); // start with all 0 tuple VV tuples(1, std::vector<Size>(dim)); // add multifactor terms for(Size i=1; i<=order; ++i) { tuples = next_order_tuples(tuples); // now we have all tuples of order i // for each tuple add the corresponding term for(Size j=0; j<tuples.size(); ++j) { VF_R term(dim); for(Size k=0; k<dim; ++k) term[k] = pathBasis[tuples[j][k]]; ret.push_back(MultiDimFct(term)); } } return ret; } } // namespace QuantLib ============================================================= On Thu, May 13, 2010 at 6:22 PM, Klaus Spanderen <klaus@...> wrote: > Hi > >> ..The size of basis is not the same for different >> polynomial types. > > I've fixed one issue in the SVN. > >> .. I reworked the >> implementation, so that basis sizes are the same for all polynomial >> types and no duplicates are created during the process. I would like >> to submit my code to QuantLib, but not sure how to do it. > > Please submit the code to this mailing list or via email. I'm going to merge > it into the SVN. > > thanks in advance > Klaus > 
From: Kakhkhor Abdijalilov <kabdijalilov@gm...>  20100514 01:47:27

Sorry, in my previous message the formula for size of basis was wrong. (Dim+Order1)! / [(Dim1)! * Order!] is the number of terms of a given order, not the basis size. 
From: Klaus Spanderen <klaus@sp...>  20100513 23:48:12

Hi > ..The size of basis is not the same for different > polynomial types. I've fixed one issue in the SVN. > .. I reworked the > implementation, so that basis sizes are the same for all polynomial > types and no duplicates are created during the process. I would like > to submit my code to QuantLib, but not sure how to do it. Please submit the code to this mailing list or via email. I'm going to merge it into the SVN. thanks in advance Klaus 
From: Ferdinando Ametrano <nando@am...>  20100513 09:58:36

On Fri, May 7, 2010 at 5:22 PM, SourceForge.net <noreply@...> wrote: > https://sourceforge.net/tracker/?func=detail&atid=312740&aid=2998216&group_id=12740 > > Submitted By: Hachemi Benyahia (hachemidxp) > Summary: Assetornothing option > > Initial Comment: > Digital assetornothing option with an analytic engine. > see:E.G. Haug p.175 cashornothing, assetornothing, and gap options are all available in AnalyticEuropeanEngine, and Haug values are reproduced in the testsuite. Am I missing something about your contribution ? ciao  Nando 
From: SourceForge.net <noreply@so...>  20100512 15:02:45

Patches item #3000492, was opened at 20100512 11:02 Message generated for change (Tracker Item Submitted) made by shlagbaum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3000492&group_id=12740 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Slava Mazur (shlagbaum) Assigned to: Nobody/Anonymous (nobody) Summary: Enhancements to TimeSeries class Initial Comment: I propose the following changes to TimeSeries class:  to add an extra template parameter Time with default to Date  this will allow for use of alternative data/time types (e.g. time_t);  to add time and value projection iterators so that one would be able to iterate through time and values independently  this feature would allow for treatment of a TimeSeries object as a simple sequence of time and/or value elemnets;  to add time and value iterator generating members: begin_time(), end_time(), begin_values(), end_values() The diff of proposed changes is attached  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3000492&group_id=12740 