quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Possible solution to the forward pricing LMM via montecarlo

[Toyin A. <toy...@ho...>]

Hi all,

As you may or may not know, the LMM model within QuantLib can only handle 
forward rates of multiple periods from the spot date. Thus if you have a 3M 
index on a floating rate leg and your pricing structure starts in 6M, 12M 
etc... you are fine. If however, your structure starts in 11M, 56 days etc, 
you are out of luck.

One possible (quick, but I beleive accurate) solution to this would be to 
use the results returned from the discountBond() function from the LMM 
Process class (via Monte-Carlo).

Bascially this function takes in the rates from a simulated path and spits 
out a discount curve.

So why can't we do what we do today, which is to construct a discount curve 
from this and then compute the rate that we want via interpolated discount 
factors

rate = ((dcfs/dcfe) - 1 / coverage).

This would be a solution if one were using the LMM process class and 
computing rates and discounts via monte-carlo. Via the LMM MODEL class is 
something else...

This can be a temporary solution until this model is updated.
However, if it is believed that we should wait for a more accurate 
implementation I would like to know whether there are any major flaws in 
this approach (for the short term at least).

Thoughts...

Toy out.

>From: Klaus Spanderen <kla...@fr...>
>Reply-To: kla...@fr...
>To: "Toyin Akin" <toy...@ho...>
>Subject: Re: [Quantlib-users] Calibration for the LFM parameters?
>Date: Mon, 12 Jun 2006 08:56:20 +0200
>
>Hi Toy
>
>impressive stuff, give me some time to study the spread sheets (I have to 
>wait
>til tomorrow anyway as my OpenOffice can't handle them;-).
>
>The extra weights within the extended volatillity model get calibrated 
>during
>the calibration procedure.
>
>If you simply construct the object and then use it the weights are constant 
>at
>1.0  (If you want I can add a parameter array to the constructor to set 
>these
>parameters explicitly.). They are not adjusted during the pricing.
>
>you wrote
> > (I found some logic within your new calibration class that
> > require at least N calibration instruments where N is the number of
> > parameters to be calibrated.)
>
>The levenberg marquardt algorithm based on the MINPACK implementation needs
>this.
>
>In general I'm a little bit in worry that the calibration is so sentitive 
>to
>the start parameters. I added the levenberg marquardt algorithm to QL 
>because
>I've thought that the LM optimization is not the sensitive. I'm definitly
>interesting in your spread sheets as they allow to play around with the
>parameters.
>
>more later
>  Klaus
>
>
>On Monday 12 June 2006 7:38 pm, you wrote:
> > Okay,
> >
> > Again, assuming my coding is correct, I've played with various values
> > within the volatility models
> > and I find that if I set the values of a,b,c and d to 0.07 before
> > calibrating, I get a pretty good fit after calibration. However the 
>value
> > of the 'b' parameter is around 1.2 and 'd' close to 0. Is that pretty 
>high
> > for 'b'?
> >
> > If however I set the initial a,b,c,d values close to your initial 
>values, I
> > get a terrible fit. Thus it seems like you have to have pretty good
> > starting values. Do you find the same behaviour within your own tests?
> >
> > Also, one other question concerning the extended volatility model. 
>Because
> > you have these extra weights within the model, are these weights 
>calibrated
> > during the calibration procedure?
> >
> > If one were to simply construct the object and then use it, are the 
>weights
> > constant at 1.0 or are they adjusted internally?
> >
> > If they are adjusted during the pricing and do not need to be calibrated
> > then I do not think it's a good idea to add these to the params array
> > internally as this would require more calibration instruments to aid in 
>the
> > calibration (I found some logic within your new calibration class that
> > require at least N calibration instruments where N is the number of
> > parameters to be calibrated.) Thus if the LMM volatility weights are 
>added
> > to this array, but do not need to be calibrated, then we need a lot of
> > instruments...
> >
> > Toy out.
> >
> > From: Klaus Spanderen <kla...@fr...>
> >
> > >Reply-To: kla...@fr...
> > >To: "Toyin Akin" <toy...@ho...>
> > >CC: qua...@li...
> > >Subject: Re: [Quantlib-users] Calibration for the LFM parameters?
> > >Date: Sat, 10 Jun 2006 06:42:20 +0200
> > >
> > >Hi Toy,
> > >
> > >yes, I used swaptions to fix the correlation models. Please find the
> > > "const wrappers" enclosed in the attachments. Hope that works..
> > >
> > >cheers
> > >  Klaus
> > >
> > >On Wednesday 07 June 2006 11:41 pm, Toyin Akin wrote:
> > > > Hi,
> > > >
> > > > I like it, I like it a lot!!
> > > >
> > > > I do like the way that different volatility and correlation
> > >
> > >specifications
> > >
> > > > can be passed into the LFM model.
> > > >
> > > > Very nice.
> > > >
> > > > I assume that you require swaptions in order to calibrate the
> > >
> > >correlation
> > >
> > > > models...
> > > >
> > > > Toy out.
> > > >
> > > >
> > > > From: Klaus Spanderen <kla...@fr...>
> > > >
> > > > >Reply-To: kla...@fr...
> > > > >To: "Toyin Akin" <toy...@ho...>
> > > > >CC: qua...@li...
> > > > >Subject: Re: [Quantlib-users] Calibration for the LFM parameters?
> > > > >Date: Wed, 7 Jun 2006 09:25:24 +0200
> > > > >
> > > > >Hi Toy,
> > > > >
> > > > >can be implemented soon. What do you think about a "const" wrapper 
>for
> > >
> > >the
> > >
> > > > >LmVolatilityModel and LmCorrelationModel that hide the parameters 
>of
> > >
> > >the
> > >
> > > > >model and therefore avoid that either the correlation model or the
> > > > >volatility
> > > > >model get calibrated?
> > > > >
> > > > >would look like
> > > > >
> > > > >boost::shared_ptr<LmVolatilityModel> constModel(
> > > > >	new LmVolatilityModelConstWrapper(lmVolaModel));
> > > > >
> > > > >Klaus
> > > > >
> > > > >On Wednesday 07 June 2006 6:09 pm, you wrote:
> > > > > > Hi Klaus,
> > > > > >
> > > > > > I'm still playing with your new files.
> > > > > >
> > > > > > Should have something to report by Thursday.
> > > > > >
> > > > > > Question, is it possible to have, possibly an enumeration 
>variable,
> > > > > > that indicates different calibration choices for the LFM model. 
>At
> > >
> > >the
> > >
> > > > >moment,
> > > > >
> > > > > > the calibration routine will calibrate all the volatility and
> > > > >
> > > > >correlation
> > > > >
> > > > > > parameters in one go.
> > > > > >
> > > > > > It would be nice to have a method within the LFM model class 
>that
> > >
> > >can
> > >
> > > > > > indicate three types of calibration :
> > > > > >
> > > > > > calibration of the volatility parameters only
> > > > > > calibration of the correlation parameters only
> > > > > > calibration of the volatility and correlation parameters (as we
> > > > > > have
> > > > >
> > > > >today)
> > > > >
> > > > > > This would be perfect for the case where you are given the
> > >
> > >volatility
> > >
> > > > > > parameters, but need to calibrate the correlation parameters.
> > > > > >
> > > > > > Thoughts...?
> > > > > > Toy out.
> > > > > >
> > > > > > From: Klaus Spanderen <kla...@fr...>
> > > > > >
> > > > > > >To: "Toyin Akin" <toy...@ho...>
> > > > > > >CC: qua...@li...
> > > > > > >Subject: Re: [Quantlib-users] Calibration for the LFM 
>parameters?
> > > > > > >Date: Tue, 6 Jun 2006 08:20:59 -0700
> > > > > > >
> > > > > > >Hi Toy,
> > > > > > >
> > > > > > >can you do me a favour and try out the more complex
> > > > > > > parametizations enclosed
> > > > > > >in the attached tar ball? (haven't fully tested them, the tar 
>ball
> > > > > > > also contains the modified test case file.),  This should 
>improve
> > >
> > >the
> > >
> > > > > > > ratio values.
> > > > > > >
> > > > > > >And please send me the vols for your caplets. 0.92 is really 
>low.
> > >
> > >Is
> > >
> > > > > > > it the global minimum?
> > > > > > >
> > > > > > >cheers
> > > > > > >  Klaus
> > > > > > >
> > > > > > >On Tuesday 06 June 2006 11:52, you wrote:
> > > > > > > > Hi Klaus,
> > > > > > > >
> > > > > > > > What kind of success rate are you having after calibrating 
>for
> > >
> > >the
> > >
> > > > >a,
> > > > >
> > > > > > >b,c,
> > > > > > >
> > > > > > > > d and rho parameters of the LFM model?
> > > > > > > >
> > > > > > > > I'm finding that after calibrating to ITM
> > > > >
> > > > >caplets/floorlets/swaptions
> > > > >
> > > > > > >and
> > > > > > >
> > > > > > > > computing the ratio of the black (analytical) price over the
> > > > >
> > > > >calibrated
> > > > >
> > > > > > > > (LFM) price (basically using a modified version of your 
>sample
> > >
> > >code
> > >
> > > > > > >within
> > > > > > >
> > > > > > > > the test directory), I get ratio values of 0.92 or less for 
>the
> > > > > > > > caplets. Worst still for swaptions
> > > > > > > >
> > > > > > > > Are you finding the same ratio values or do you suspect I've
> > >
> > >done
> > >
> > > > > > >something
> > > > > > >
> > > > > > > > wrong?
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Toy out.
> > > > > > >
> > > > > > >--
> > > > > > >_______________________________________________________
> > > > > > >Klaus Spanderen
> > > > > > >Hubertustal 13f
> > > > > > >48734 Reken (Germany)
> > > > > > >Email: kla...@NO...
> > > > > > >(remove NOSPAM from the address)
> > > > > > >http://www.spanderen.de
> > > > > > >
> > > > > > >
> > > > > > ><< lfm.tgz >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >_______________________________________________
> > > > > > >QuantLib-users mailing list
> > > > > > >Qua...@li...
> > > > > > >https://lists.sourceforge.net/lists/listinfo/quantlib-users
> > > >
> > > > _______________________________________________
> > > > QuantLib-users mailing list
> > > > Qua...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/quantlib-users
> > >
> > ><< lmconstwrappervolmodel.hpp >>
> > >
> > >
> > ><< lmconstwrappercorrmodel.hpp >>
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >QuantLib-users mailing list
> > >Qua...@li...
> > >https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-dev] ConvertibleBond framework

[Luigi B. <lui...@gm...>]

On 06/06/2006 05:30:59 PM, TB...@ao... wrote:
> Yes I have a resolution and  with some code with examples. I am
> waiting for Luigi to come back from vacation to check the code.

I'm back.

Later,
     Luigi

Re: [Quantlib-dev] ConvertibleBond framework

[Toyin A. <toy...@ho...>]

Thanks,

I'll play with it tomorrow, need to finish testing some LFM stuff first...

Regards,
Toy out.


>From: TB...@ao...
>To: toy...@ho...
>CC: qua...@li...
>Subject: Re: [Quantlib-dev] ConvertibleBond framework
>Date: Wed, 7 Jun 2006 09:11:23 EDT
>
>Hi toyin,
>
>I have made some corrections but none have been committed.  The  versions 
>in
>cvs are current with version 3.12 of the release.
>
>Please find attached corrections.
>
>
>Regards
>
>Theo
>


><< test.zip >>

Re: [Quantlib-dev] ConvertibleBond framework

[<TB...@ao...>]

Hi toyin,
 
The option class was introduced to allow set up of arguments and pass  to
pricing engine.  At the time of design I thought the schedule object  would be
required.  I think its redundant but we just leave as it  is.  Being stored as
private is not an issue as all arguments to be set  up to be passed onto 
pricing
engine are all declared as private and not to be  inherited.  The same applies
to all option pricing engines in  QuantLib.
 
I will send you source code for latest changes in my next e-mail
 
 
Regards
 
Theo
 
 

Re: [Quantlib-dev] Running into problem with R-Swig wrappers

[Duncan T. L. <du...@wa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


So am I correct in saying that in this example a single
C++ routine gives rise to 6 separate calls to setMethod()
in R?

If so, there is no need for that.  If there is only
method/routine then it corresponds to only one
R function and the S4 dispatch is an unnecessary
distraction and overwhelming performance inhibitor.

If you have polymorphic C++ routines/methods
which have optional arguments that are used to determine
the dispatch, then the problem becomes slightly more complex.

 D.


Joseph Wang wrote:
> 在 Tuesday 06 June 2006 22:48，您写道：
> 
>>Can you show us some of the overloaded functions, please?
>>I don't know what you mean by a "large" number of arguments
>>and why you are generating functions with a large number of
>>parameters so it would be helpful to see what you are generating.
>>
> 
> 
> Sure thing the signature
> 
>         FixedCouponBondPtr(const Date& issueDate,
>                            const Date& datedDate,
>                            const Date& maturityDate,
>                            Integer settlementDays,
>                            const std::vector<Rate>& coupons,
>                            Frequency couponFrequency,
>                            const Calendar& calendar,
>                            const DayCounter& dayCounter,
>                            BusinessDayConvention accrualConvention
>                                                        = QuantLib::Following,
>                            BusinessDayConvention paymentConvention
>                                                        = QuantLib::Following,
>                            Real redemption = 100.0,
>                            const Handle<YieldTermStructure>& discountCurve
>                                               = Handle<YieldTermStructure>(),
>                            const Date& stub = Date(),
>                            bool fromEnd = true) 
> 
> generates six separate wrappers for each possible number of optional argument.
> (See below for the first few wrappers.)
> 
> Loading the wrappers into R seems to take about several meg of heap space.  
> Loading in about a hundred of these sorts of functions, kills the machine.
> 
> If I change the signature to make the optional arguments required, then an 
> ordinary non-generic function gets generated, and I don't get the huge memory 
> bloat.
> 
> 
> 
> setGeneric('FixedCouponBond', function(s_arg1, s_arg2, s_arg3, s_arg4, s_arg5, 
> s_arg6, s_arg7, s_arg8, s_arg9, s_arg10, s_arg11, s_arg12, s_arg13, s_arg14, 
> s_arg15, ...) standardGeneric('FixedCouponBond'))
> attr(FixedCouponBond, 'returnType') = '_p_FixedCouponBondPtr'
> setMethod('FixedCouponBond', 
> c('_p_Date', '_p_Date', '_p_Date', 'numeric', '_p_std__vectorTdouble_std__allocatorTdouble_t_t', 'character', '_p_Calendar', '_p_DayCounter', 'character', 'character', 'numeric', '_p_HandleTYieldTermStructure_t', '_p_Date', 'logical', 
> s_arg15 = "missing"), 
> function(s_arg1, s_arg2, s_arg3, s_arg4, s_arg5, s_arg6, s_arg7, s_arg8, 
> s_arg9, s_arg10, s_arg11, s_arg12, s_arg13, s_arg14)
> {
>   s_arg1 = coerceIfNotSubclass(s_arg1, "_p_Date") 
>   s_arg2 = coerceIfNotSubclass(s_arg2, "_p_Date") 
>   s_arg3 = coerceIfNotSubclass(s_arg3, "_p_Date") 
>   s_arg4 = as.integer(s_arg4) 
>   
>   if(length(s_arg4) > 1) {
>     warning("using only the first element of s_arg4")
>   }
>   
>   s_arg5 = 
> coerceIfNotSubclass(s_arg5, "_p_std__vectorTdouble_std__allocatorTdouble_t_t") 
>   s_arg6 = enumToInteger(s_arg6, "_Frequency") 
>   
>   if(length(s_arg6) > 1) {
>     warning("using only the first element of s_arg6")
>   }
>   
>   s_arg7 = coerceIfNotSubclass(s_arg7, "_p_Calendar") 
>   s_arg8 = coerceIfNotSubclass(s_arg8, "_p_DayCounter") 
>   s_arg9 = enumToInteger(s_arg9, "_BusinessDayConvention") 
>   
>   if(length(s_arg9) > 1) {
>     warning("using only the first element of s_arg9")
>   }
>   
>   s_arg10 = enumToInteger(s_arg10, "_BusinessDayConvention") 
>   
>   if(length(s_arg10) > 1) {
>     warning("using only the first element of s_arg10")
>   }
>   
>   s_arg11 = as.numeric(s_arg11) 
>   s_arg12 = coerceIfNotSubclass(s_arg12, "_p_HandleTYieldTermStructure_t") 
>   s_arg13 = coerceIfNotSubclass(s_arg13, "_p_Date") 
>   s_arg14 = as.logical(s_arg14) 
>   ans = .Call('R_swig_new_FixedCouponBond__SWIG_0', s_arg1, s_arg2, s_arg3, 
> s_arg4, s_arg5, s_arg6, s_arg7, s_arg8, s_arg9, s_arg10, s_arg11, s_arg12, 
> s_arg13, s_arg14, PACKAGE='QuantLib_wrap')
>   class(ans) <- "_p_FixedCouponBondPtr"
>   
>   ans
>   
> }
> 
> )
> setMethod('FixedCouponBond', 
> c('_p_Date', '_p_Date', '_p_Date', 'numeric', '_p_std__vectorTdouble_std__allocatorTdouble_t_t', 'character', '_p_Calendar', '_p_DayCounter', 'character', 'character', 'numeric', '_p_HandleTYieldTermStructure_t', '_p_Date', 
> s_arg14 = "missing", s_arg15 = "missing"), 
> function(s_arg1, s_arg2, s_arg3, s_arg4, s_arg5, s_arg6, s_arg7, s_arg8, 
> s_arg9, s_arg10, s_arg11, s_arg12, s_arg13)
> {
>   s_arg1 = coerceIfNotSubclass(s_arg1, "_p_Date") 
>   s_arg2 = coerceIfNotSubclass(s_arg2, "_p_Date") 
>   s_arg3 = coerceIfNotSubclass(s_arg3, "_p_Date") 
>   s_arg4 = as.integer(s_arg4) 
>   
>   if(length(s_arg4) > 1) {
>     warning("using only the first element of s_arg4")
>   }
>   
>   s_arg5 = 
> coerceIfNotSubclass(s_arg5, "_p_std__vectorTdouble_std__allocatorTdouble_t_t") 
>   s_arg6 = enumToInteger(s_arg6, "_Frequency") 
>   
>   if(length(s_arg6) > 1) {
>     warning("using only the first element of s_arg6")
>   }
>   
>   s_arg7 = coerceIfNotSubclass(s_arg7, "_p_Calendar") 
>   s_arg8 = coerceIfNotSubclass(s_arg8, "_p_DayCounter") 
>   s_arg9 = enumToInteger(s_arg9, "_BusinessDayConvention") 
>   
>   if(length(s_arg9) > 1) {
>     warning("using only the first element of s_arg9")
>   }
>   
>   s_arg10 = enumToInteger(s_arg10, "_BusinessDayConvention") 
>   
>   if(length(s_arg10) > 1) {
>     warning("using only the first element of s_arg10")
>   }
>   
>   s_arg11 = as.numeric(s_arg11) 
>   s_arg12 = coerceIfNotSubclass(s_arg12, "_p_HandleTYieldTermStructure_t") 
>   s_arg13 = coerceIfNotSubclass(s_arg13, "_p_Date") 
>   ans = .Call('R_swig_new_FixedCouponBond__SWIG_1', s_arg1, s_arg2, s_arg3, 
> s_arg4, s_arg5, s_arg6, s_arg7, s_arg8, s_arg9, s_arg10, s_arg11, s_arg12, 
> s_arg13, PACKAGE='QuantLib_wrap')
>   class(ans) <- "_p_FixedCouponBondPtr"
>   
>   ans
>   
> }
> 
> )

- --
Duncan Temple Lang                    du...@wa...
Department of Statistics              work:  (530) 752-4782
4210 Mathematical Sciences Building   fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis,
CA 95616,
USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFEhlUk9p/Jzwa2QP4RAv59AJ4s8CvIfa1TZIt9sGy8BL7sEF7l4wCdFSER
Mh7uiv4AY6HzRgxoC+1B6/U=
=GlVj
-----END PGP SIGNATURE-----

Re: [Quantlib-dev] Running into problem with R-Swig wrappers

[Joseph W. <jo...@gn...>]

=E5=9C=A8 Tuesday 06 June 2006 22:48=EF=BC=8C=E6=82=A8=E5=86=99=E9=81=93=EF=
=BC=9A
> Can you show us some of the overloaded functions, please?
> I don't know what you mean by a "large" number of arguments
> and why you are generating functions with a large number of
> parameters so it would be helpful to see what you are generating.
>

Sure thing the signature

        FixedCouponBondPtr(const Date& issueDate,
                           const Date& datedDate,
                           const Date& maturityDate,
                           Integer settlementDays,
                           const std::vector<Rate>& coupons,
                           Frequency couponFrequency,
                           const Calendar& calendar,
                           const DayCounter& dayCounter,
                           BusinessDayConvention accrualConvention
                                                       =3D QuantLib::Follow=
ing,
                           BusinessDayConvention paymentConvention
                                                       =3D QuantLib::Follow=
ing,
                           Real redemption =3D 100.0,
                           const Handle<YieldTermStructure>& discountCurve
                                              =3D Handle<YieldTermStructure=
>(),
                           const Date& stub =3D Date(),
                           bool fromEnd =3D true)=20

generates six separate wrappers for each possible number of optional argume=
nt.
(See below for the first few wrappers.)

Loading the wrappers into R seems to take about several meg of heap space. =
=20
Loading in about a hundred of these sorts of functions, kills the machine.

If I change the signature to make the optional arguments required, then an=
=20
ordinary non-generic function gets generated, and I don't get the huge memo=
ry=20
bloat.



setGeneric('FixedCouponBond', function(s_arg1, s_arg2, s_arg3, s_arg4, s_ar=
g5,=20
s_arg6, s_arg7, s_arg8, s_arg9, s_arg10, s_arg11, s_arg12, s_arg13, s_arg14=
,=20
s_arg15, ...) standardGeneric('FixedCouponBond'))
attr(FixedCouponBond, 'returnType') =3D '_p_FixedCouponBondPtr'
setMethod('FixedCouponBond',=20
c('_p_Date', '_p_Date', '_p_Date', 'numeric', '_p_std__vectorTdouble_std__a=
llocatorTdouble_t_t', 'character', '_p_Calendar', '_p_DayCounter', 'charact=
er', 'character', 'numeric', '_p_HandleTYieldTermStructure_t', '_p_Date', '=
logical',=20
s_arg15 =3D "missing"),=20
function(s_arg1, s_arg2, s_arg3, s_arg4, s_arg5, s_arg6, s_arg7, s_arg8,=20
s_arg9, s_arg10, s_arg11, s_arg12, s_arg13, s_arg14)
{
  s_arg1 =3D coerceIfNotSubclass(s_arg1, "_p_Date")=20
  s_arg2 =3D coerceIfNotSubclass(s_arg2, "_p_Date")=20
  s_arg3 =3D coerceIfNotSubclass(s_arg3, "_p_Date")=20
  s_arg4 =3D as.integer(s_arg4)=20
 =20
  if(length(s_arg4) > 1) {
    warning("using only the first element of s_arg4")
  }
 =20
  s_arg5 =3D=20
coerceIfNotSubclass(s_arg5, "_p_std__vectorTdouble_std__allocatorTdouble_t_=
t")=20
  s_arg6 =3D enumToInteger(s_arg6, "_Frequency")=20
 =20
  if(length(s_arg6) > 1) {
    warning("using only the first element of s_arg6")
  }
 =20
  s_arg7 =3D coerceIfNotSubclass(s_arg7, "_p_Calendar")=20
  s_arg8 =3D coerceIfNotSubclass(s_arg8, "_p_DayCounter")=20
  s_arg9 =3D enumToInteger(s_arg9, "_BusinessDayConvention")=20
 =20
  if(length(s_arg9) > 1) {
    warning("using only the first element of s_arg9")
  }
 =20
  s_arg10 =3D enumToInteger(s_arg10, "_BusinessDayConvention")=20
 =20
  if(length(s_arg10) > 1) {
    warning("using only the first element of s_arg10")
  }
 =20
  s_arg11 =3D as.numeric(s_arg11)=20
  s_arg12 =3D coerceIfNotSubclass(s_arg12, "_p_HandleTYieldTermStructure_t"=
)=20
  s_arg13 =3D coerceIfNotSubclass(s_arg13, "_p_Date")=20
  s_arg14 =3D as.logical(s_arg14)=20
  ans =3D .Call('R_swig_new_FixedCouponBond__SWIG_0', s_arg1, s_arg2, s_arg=
3,=20
s_arg4, s_arg5, s_arg6, s_arg7, s_arg8, s_arg9, s_arg10, s_arg11, s_arg12,=
=20
s_arg13, s_arg14, PACKAGE=3D'QuantLib_wrap')
  class(ans) <- "_p_FixedCouponBondPtr"
 =20
  ans
 =20
}

)
setMethod('FixedCouponBond',=20
c('_p_Date', '_p_Date', '_p_Date', 'numeric', '_p_std__vectorTdouble_std__a=
llocatorTdouble_t_t', 'character', '_p_Calendar', '_p_DayCounter', 'charact=
er', 'character', 'numeric', '_p_HandleTYieldTermStructure_t', '_p_Date',=20
s_arg14 =3D "missing", s_arg15 =3D "missing"),=20
function(s_arg1, s_arg2, s_arg3, s_arg4, s_arg5, s_arg6, s_arg7, s_arg8,=20
s_arg9, s_arg10, s_arg11, s_arg12, s_arg13)
{
  s_arg1 =3D coerceIfNotSubclass(s_arg1, "_p_Date")=20
  s_arg2 =3D coerceIfNotSubclass(s_arg2, "_p_Date")=20
  s_arg3 =3D coerceIfNotSubclass(s_arg3, "_p_Date")=20
  s_arg4 =3D as.integer(s_arg4)=20
 =20
  if(length(s_arg4) > 1) {
    warning("using only the first element of s_arg4")
  }
 =20
  s_arg5 =3D=20
coerceIfNotSubclass(s_arg5, "_p_std__vectorTdouble_std__allocatorTdouble_t_=
t")=20
  s_arg6 =3D enumToInteger(s_arg6, "_Frequency")=20
 =20
  if(length(s_arg6) > 1) {
    warning("using only the first element of s_arg6")
  }
 =20
  s_arg7 =3D coerceIfNotSubclass(s_arg7, "_p_Calendar")=20
  s_arg8 =3D coerceIfNotSubclass(s_arg8, "_p_DayCounter")=20
  s_arg9 =3D enumToInteger(s_arg9, "_BusinessDayConvention")=20
 =20
  if(length(s_arg9) > 1) {
    warning("using only the first element of s_arg9")
  }
 =20
  s_arg10 =3D enumToInteger(s_arg10, "_BusinessDayConvention")=20
 =20
  if(length(s_arg10) > 1) {
    warning("using only the first element of s_arg10")
  }
 =20
  s_arg11 =3D as.numeric(s_arg11)=20
  s_arg12 =3D coerceIfNotSubclass(s_arg12, "_p_HandleTYieldTermStructure_t"=
)=20
  s_arg13 =3D coerceIfNotSubclass(s_arg13, "_p_Date")=20
  ans =3D .Call('R_swig_new_FixedCouponBond__SWIG_1', s_arg1, s_arg2, s_arg=
3,=20
s_arg4, s_arg5, s_arg6, s_arg7, s_arg8, s_arg9, s_arg10, s_arg11, s_arg12,=
=20
s_arg13, PACKAGE=3D'QuantLib_wrap')
  class(ans) <- "_p_FixedCouponBondPtr"
 =20
  ans
 =20
}

)

Re: [Quantlib-dev] Running into problem with R-Swig wrappers

[Duncan T. L. <du...@wa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Can you show us some of the overloaded functions, please?
I don't know what you mean by a "large" number of arguments
and why you are generating functions with a large number of
parameters so it would be helpful to see what you are generating.

 D.

Joseph Wang wrote:
> The problem I'm running into is that an overloaded r function with large 
> numbers of arguments seem to be eating up huge amounts of memory, causing my 
> 512 meg machine to run out of free memory before loading the wrapper.  
> 
> The trouble is that the functions with large numbers of option arguments 
> generate r overloaded functions.  
> 
> One way I've been able to get things to work is by defining 
> 
> #if defined(SWIGR)
> #define OPTIONAL(x, y) x
> #else
> #define OPTIONAL(x, y) x = y
> #endif
> 
> and then
> 
>         ParCouponPtr(Real nominal, const Date& paymentDate,
>                      const XiborPtr& index,
>                      const Date& startDate, const Date& endDate,
>                      Integer fixingDays,
>                      OPTIONAL(Spread spread, 0.0),
>                      OPTIONAL(const Date& refPeriodStart, Date()),
>                      OPTIONAL(const Date& refPeriodEnd, Date())
> 
> This forces R to remove the optional arguments, which means that R no longer 
> uses overloading to represent these long functions, which bypasses the memory 
> bloating.
> 
> I've e-mailed the r-help list for any suggestions to get around the memory 
> bloat.
> 
> I'm curious if anyone has any other ideas on how to handle this.  One thing 
> that might be possible is to turn off operator overloading in R-SWIG if there 
> are more than six arguments, and then to use a herustic to figure out which 
> method to generate a wrapper for.
> 
> Thoughts?

- --
Duncan Temple Lang                    du...@wa...
Department of Statistics              work:  (530) 752-4782
4210 Mathematical Sciences Building   fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis,
CA 95616,
USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFEhkxg9p/Jzwa2QP4RAp8zAJ9fq4+xV3cjD4+uhB8SkCk18JPUuACdEMA0
Fp5feNGFE2CmiGJrrkJ6cv4=
=w/8W
-----END PGP SIGNATURE-----

[Quantlib-dev] Running into problem with R-Swig wrappers

[Joseph W. <jo...@gn...>]

The problem I'm running into is that an overloaded r function with large 
numbers of arguments seem to be eating up huge amounts of memory, causing my 
512 meg machine to run out of free memory before loading the wrapper.  

The trouble is that the functions with large numbers of option arguments 
generate r overloaded functions.  

One way I've been able to get things to work is by defining 

#if defined(SWIGR)
#define OPTIONAL(x, y) x
#else
#define OPTIONAL(x, y) x = y
#endif

and then

        ParCouponPtr(Real nominal, const Date& paymentDate,
                     const XiborPtr& index,
                     const Date& startDate, const Date& endDate,
                     Integer fixingDays,
                     OPTIONAL(Spread spread, 0.0),
                     OPTIONAL(const Date& refPeriodStart, Date()),
                     OPTIONAL(const Date& refPeriodEnd, Date())

This forces R to remove the optional arguments, which means that R no longer 
uses overloading to represent these long functions, which bypasses the memory 
bloating.

I've e-mailed the r-help list for any suggestions to get around the memory 
bloat.

I'm curious if anyone has any other ideas on how to handle this.  One thing 
that might be possible is to turn off operator overloading in R-SWIG if there 
are more than six arguments, and then to use a herustic to figure out which 
method to generate a wrapper for.

Thoughts?

Re: [Quantlib-dev] ConvertibleBond framework

[Toyin A. <toy...@ho...>]

Hi,

I've had a quick look at some of the converibleBond code within CVS, it 
looks like within the ConvertibleBond::option class, a schedule object is 
passed to the constructor and stored, but it is never used within the class 
(stored as private and thus inherited classes will also not gain access to 
it.)

Toy out.


>From: TB...@ao...
>To: toy...@ho...
>CC: qua...@li...
>Subject: Re: [Quantlib-dev] Re: ConvertibleBond framework
>Date: Tue, 6 Jun 2006 11:30:59 EDT
>
>Hi toyin,
>
>Yes I have a resolution and  with some code with examples. I am  waiting 
>for
>Luigi to come back from vacation to check the code.  If he's  happy with it
>then it will be comitted to quantlib cvs.
>
>Regards
>
>Theo
>

Re: [Quantlib-dev] ConvertibleBond framework

[Toyin A. <toy...@ho...>]

Hi,

Are you saying that the code correction has already been commited to CVS, 
but the examples/test have not?

If the code corrections have not been commited what has been commited?

In addition, if the code corrections have not been commited, is it possible 
for you to email me your corrections so that I can play with it a bit?

Best Regards,
Toy out.

>From: TB...@ao...
>To: toy...@ho...
>CC: qua...@li...
>Subject: Re: [Quantlib-dev] ConvertibleBond framework
>Date: Tue, 6 Jun 2006 11:30:59 EDT
>
>Hi toyin,
>
>Yes I have a resolution and  with some code with examples. I am  waiting 
>for
>Luigi to come back from vacation to check the code.  If he's  happy with it
>then it will be comitted to quantlib cvs.
>
>Regards
>
>Theo
>




>_______________________________________________
>QuantLib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] ConvertibleBond framework

[<TB...@ao...>]

Hi toyin,
 
Yes I have a resolution and  with some code with examples. I am  waiting for 
Luigi to come back from vacation to check the code.  If he's  happy with it 
then it will be comitted to quantlib cvs.
 
Regards
 
Theo
 

Re: [Quantlib-dev] ConvertibleBond framework

[Toyin A. <toy...@ho...>]

Hi Theo,

Has the discrete dividends bit within the ConvertibleBond framework been 
resolved?

I noticed that you made some changes to this part of the code.

Toy out.


>From: TB...@ao...
>To: toy...@ho...
>CC: lui...@gm..., qua...@li...
>Subject: [Quantlib-dev] Re: ConvertibleBond framework
>Date: Thu, 11 May 2006 04:52:18 EDT
>
>Hi toyin,
>
>Luigi can correct me if I am wrong but so far the implementation is  
>correct.
>
>The posting you saw was regarding discrete dividends which is not part of
>the current implementation as what we had in developement was incorrect.
>
>I intend to look at the discrete dividends bit.
>
>
>Regards
>
>Theo
>

[Quantlib-dev] QuantLibAddin / ObjectHandler mailing list

[eric e. <eri...@gm...>]

Hello,

As mentioned previously ObjectHandler and QuantLibAddin have been
reorganized into separate projects:

http://sourceforge.net/projects/objecthandler
http://sourceforge.net/projects/gensrc
http://sourceforge.net/projects/quantlibaddin
http://sourceforge.net/projects/quantlibxl

We've set up the mailing lists as follows:

1) quantlibxl-users - end users of QuantLibXL

2) quantlibaddin-developers - everybody else, i.e. anyone interested in:
   - source code for QuantLibXL
   - source code and/or usage of other Addins e.g. Calc
   - anything relating to QuantLibAddin, ObjectHandler, or gensrc

For now I would propose to transfer any discussion of
ObjectHandler/QuantLibAddin development from quantlib-dev to
quantlibaddin-developers.  I've started with a message regarding
changes to the processing of instance names:

    http://sourceforge.net/mailarchive/forum.php?thread_id=11101467&forum_id=48697

When we do the next release I'll ask end users to relocate from
quantlib-users to quantlibxl-users.

Regards,
Eric

[Quantlib-dev] Missing in inaction

[Luigi B. <lui...@gm...>]

Hi all,
	starting tomorrow, I'll be in vacation for the next 10 days.
Therefore, replies will be even later than usual...

Later,
	Luigi


----------------------------------------

Any software problem can be solved by adding another layer of =20
indirection.
-- Steven M. Bellovin

Re: [Quantlib-dev] New termstructure for bootstrap algorithm

[Luigi B. <lui...@gm...>]

On 05/30/2006 11:43:14 AM, jamal abid wrote:
>   I am currently using Quantlib and would like to implement some new
> options with the "Term structure based on piecewise-constant flat
> forwards with libor-futures-swap bootstrapping algorithm". I would
> like to implement the same algorithm but with the so-called linear
> forward and quadratic forward algorithms. There is something that I
> still don't understand, the current implementation is called =20
> piecewise constant flat forward algorithm but where are these =20
> constant flat forward rates ? as far as I know in QL, a term strucure =20
> with loglinear interpolation is run along optimizing the reevaluation =20
> of each instrument till an accuracy is reached.

Jamal,
	loglinear discounts are equivalent to flat (instantaneous) =20
forward rates; you can verify it by manipulating the conversion =20
formula, i.e., (LaTeX ahead)

D(t) =3D exp(-int_0^t f(\tau) d\tau)

Using the discounts was simply more convenient for the implementation.

Also, the piecewise-flat forward is not really "the current =20
implementation"; it was the only one available up to a few releases =20
ago, but now it's just a special case of a more generic piecewise yield =20
curve. You can find more such curves used in the test suite, including =20
curves which actually interpolate forwards.

Later,
	Luigi


----------------------------------------

For every problem there is one solution which is simple, neat, and =20
wrong.
-- H. L. Mencken

[Quantlib-dev] New termstructure for bootstrap algorithm

[jamal a. <the...@ya...>]

Hi,
   
  I am currently using Quantlib and would like to implement some new options with the "Term structure based on piecewise-constant flat forwards with libor-futures-swap bootstrapping algorithm". I would like to implement the same algorithm but with the so-called linear forward and quadratic forward algorithms. There is something that I still don't understand, the current implementation is called piecewise constant flat forward algorithm but where are these constant flat forward rates ? as far as I know in QL, a term strucure with loglinear interpolation is run along optimizing the reevaluation of each instrument till an accuracy is reached.
   
  Thanks
   
  the naif...

Send instant messages to your online friends http://uk.messenger.yahoo.com 

[Quantlib-dev] no pserver access from behind firewall

[eric e. <eri...@gm...>]

Hi All,

Following the move to their new infrastructure, SourceForge have
quietly stopped providing an alternate port number for pserver access,
meaning that anonymous cvs access is no longer possible for those of
us at sites where traffic is blocked on the standard port (2401).

As mentioned previously SF do continue to provide an alternate port
for ext (developer) access from behind a firewall.

Regards,
Eric

---------- Forwarded message ----------
From: SourceForge.net <no...@so...>
Date: May 22, 2006 7:49 PM
Subject: [ alexandria-Support Requests-1489428 ] pserver access via proxy
To: no...@so...


Support Requests item #1489428, was opened at 2006-05-16 06:12
Message generated for change (Comment added) made by burley
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1489428&group_id=1

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: Project CVS Services
Group: None
>Status: Closed
Priority: 5
Submitted By: Eric Ehlers (ericehlers)
>Assigned to: David Burley (burley)
Summary: pserver access via proxy

Initial Comment:
Hello,

Prior to the recent hardware failures, I was able to
access CVS anonymously via my employer's proxy server
like so:

"C:\Program Files\TortoiseCVS\cvs.exe"
"-d:pserver;proxy=xxx;proxyport=xxx;proxyuser=xxx;proxypassword=xxx:ano...@cv...:443/cvsroot/xxx"
login

Since the upgrade to the new infrastructure I can't
figure out how to access CVS anonymously via a proxy.

Normal pserver access would now be via
PROJECTNAME.cvs.sourceforge.net on port 2401.  For
those of us behind a firewall, and using a proxy, I
guess you would provide an alternate port and/or
hostname?  The docs indicate an alternate port for SSH
but I can't see any mention of an alternate port for
pserver and I can't figure out what it is.  For example
the following command ...

"C:\Program Files\TortoiseCVS\cvs.exe"
"-d:pserver;proxy=xxx;proxyport=xxx;proxyuser=xxx;proxypassword=xxx:ano...@xx...:443/cvsroot/quantlib"
login

... fails with this error:

cvs.exe [login aborted]: unrecognized auth response
from xxx.cvs.sourceforge.net: SSH-1.99-OpenSSH_3.9p1

It looks like your port 443 is expecting access via SSH
- whereas under the old infrastructure, port 443 on
cvs-pserver.sourceforge.net accepted HTTP access which
was simply redirected.

Please note that I _am_ able to access the new
infrastructure via developer/SSH from behind my
employer's firewall/proxy.  It's only anonymous/pserver
access that I can't figure out.

Many thanks for any assistance that you are able to
provide.

Kind Regards,
Eric

----------------------------------------------------------------------

>Comment By: David Burley (burley)
Date: 2006-05-22 13:49

Message:
Logged In: YES
user_id=597273

Greetings,

We no longer provide an alternate port for pserver, given
that all the good ports are already taken on the host. You
should contact your network administrator and ask them to
open port 2401 up.

Thank you,

David Burley
Quality of Service Analyst, SourceForge.net

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1489428&group_id=1

[Quantlib-dev] QuantLibAddin / ObjectHandler Project Reorganization

[eric e. <eri...@gm...>]

Hi All

QuantLibAddin and ObjectHandler have been transferred out of QuantLib
and reorganized into the following SourceForge projects:

gensrc - renamed from srcgen due to a SourceForge name conflict and
decoupled from QuantLibAddin
ObjectHandler - unchanged
QuantLibAddin - as before minus the Excel addin
QuantLibXL - the Excel component of QuantLibAddin

The Excel portion of QuantLibAddin has been separated out to reflect
the fact that most interest in QuantLibAddin originates from
nontechnical users on the Excel platform. Resurrection of the
QuantLibXL name reflects the ongoing initiative to port functionality
from the old QuantLibXL project.

The build process is basically the same.  gensrc has been modified to
output files into QuantLibAddin and QuantLibXL.  At present the only
platform that builds correctly is Excel/VC8 - other platforms will be
fixed before the next release.

Mailing lists will shortly be created for the new projects.

Hope that's all OK, any problems please let me know.

Thanks
Eric

[Quantlib-dev] Question on TimeGrid

[Javier B. <jav...@gm...>]

Hello quantlib's developers.
I'm reading the TimeGrid code and I've noticed that the constructor of
this object using two iterator is not a particular case of the
constructor using two iterator plus a step parameter (set to zero),
and the object behaves different. Is there any reason to this?
Also, in the constructor wich use the end and a Step, the value 0.0 is
not set as the first mandatory time.
Just Curiosity
Cheers
/jb

ps: the use of this template oriented c++ you are using is awesome :)
--=20
Remember: KING KONG Died for your Sins

Re: [Quantlib-dev] QuEP 4: Reducing abstraction penalty by means of disposable arrays

[Luigi B. <lui...@gm...>]

On 05/16/2006 07:52:59 PM, DU VIGNAUD Fran=E7ois wrote:
> The following constructor destroys
> the non disposable object t given as argument:
> (ql/Utilities/disposable.hpp)
>=20
>     template <class T>
>     inline Disposable<T>::Disposable(T& t) {
>         this->swap(t);
>     }

Yes, this is by design. The purpose is to allow one to write

Disposable<Foo> bar() {
     Foo f(1,2);
     return f;
}

and avoid the copy in the automatic conversion from Foo to =20
Disposable<Foo> implied by the return. The problem was that it is =20
difficult to initialize a Disposable directly, as in:

Disposable<Foo> baz() {
     Disposable<Foo> f(1,2);
     return f;
}

because Disposable has no idea of how many arguments the constructor =20
should take, nor of their types. Other approaches might be possible, =20
but I think they make the resulting client code more clumsy.

Luigi


----------------------------------------

The first rule of intelligent tinkering is to save all the parts.
-- Paul Erlich

Re: [Quantlib-dev] CVS root change

[Luigi B. <lui...@gm...>]

On 05/16/2006 09:44:01 PM, Ken Anderson wrote:
> Not to mention the fact that Subversion is loads better than CVS!

I know---I'm using it already for other projects. I was thinking of =20
making the switch in the near future, but I didn't want to =20
hurry---unless there's serious problems with CVS, of course...

Luigi


----------------------------------------

Matz's Law:
	A conclusion is the place where you got tired of thinking.

Re: [Quantlib-dev] CVS root change

[Ken A. <li...@an...>]

Not to mention the fact that Subversion is loads better than CVS!

On May 16, 2006, at 3:02 PM, Plamen Neykov wrote:

> Hi guys,
>
> On Tuesday 16 May 2006 16:08, eric ehlers wrote:
>> I've tried anonymous access from behind a firewall without success.
>
> I saw the other day that source forge is offering also svn - svn  
> supports
> check-in  check-out operations over http/https - I've personally  
> used such a
> repository behind a corporate fire wall and a proxy - it worked  
> perfectly -
> if QL could switch to svn it will simplify tremendously all of us  
> behind a
> firewall and/or proxies ...
>
> just my two cents
>
> cheers,
> Plamen
>

Re: [Quantlib-dev] CVS root change

[Plamen N. <Pla...@re...>]

Hi guys,

On Tuesday 16 May 2006 16:08, eric ehlers wrote:
> I've tried anonymous access from behind a firewall without success.

I saw the other day that source forge is offering also svn - svn supports=20
check-in  check-out operations over http/https - I've personally used such =
a=20
repository behind a corporate fire wall and a proxy - it worked perfectly -=
=20
if QL could switch to svn it will simplify tremendously all of us behind a=
=20
firewall and/or proxies ...

just my two cents

cheers,
Plamen

[Quantlib-dev] QuEP 4: Reducing abstraction penalty by means of disposable arrays

[<Fra...@ca...>]

=20

Hi all,

=20

I have found something that seems to be a bug in the disposable =
Disposable Class Template. Indeed, the following constructor destroys =
the non disposable object t given as argument: =
(ql/Utilities/disposable.hpp =
<mk:@MSITStore:C:\Program%20Files\Quantlib\QuantLib-0.3.12\Docs\QuantLib_=
cpp-3.12.chm::/disposable_8hpp-source.html>  line 74 to 77)

    template <class T>

    inline Disposable<T>::Disposable(T& t) {

        this->swap(t);

    }

=20

To my point of view this behaviour is not consistent with the original =
Luigi's proposal. By the way, this "bug" is corrected in the code =
excerpts featured in the QuEP9.

=20

Best regards,

=20

Fran=E7ois

=20

Re: [Quantlib-dev] QuantLib:0.3.12 bug and polishes

[Luigi B. <lui...@gm...>]

Hi Eugene,

On 05/10/2006 02:15:15 PM, Eugene Shevkoplyas wrote:
> 1. [Bug] I've got the error like "Tamas R Sashalmi"
>=20
> Testing analytic Heston engine against Black formula...
> quantlib/0.3.12/src/test-suite/hestonmodel.cpp(296): fatal error in
> "HestonModelTest::testAnalyticVsBlack": failed to reproduce Black
> price
> calculated: 0.80067
> expected: 0.80067
> error: 1.071473e-007

This was already fixed in CVS.



> 2. I use some extra compiler's options: -std=3Dgnu99 -pedantic -Wall
> -ansi

I see. I've been using the -pedantic -Wall -ansi flags, but not -std.

>     So I get many errors during compilation:
>=20
> 2.1. C++ style comment in C sources.
>       In files ql/RandomNumbers/primitivepolynomials.[ch]
>       there are "// ... " comments used instead of "/* ... */".

Fixed.


> 2.2. Non ASCII symbols
>       Also in files ql/RandomNumbers/primitivepolynomials.[ch]
>       I've got many errors like this:
>          error: stray '\169' in program
>       It is because there are name in comment with strange symbol:
>         "Monte Carlo Methods in Finance" by Peter J?kel

Hmm. I'd rather keep the correct name. Is there any directive I can add =20
to the file to disable the warning?

Thanks,
	Luigi


----------------------------------------

The first rule of intelligent tinkering is to save all the parts.
-- Paul Erlich