http://quantlib.414.s1.nabble.com/pricing-a-floating-rate-bond-tp14445p14673.html
always discounts to the settlement date of the bond. If you move the
out exactly why would require some time with a debugger. I suspect
since you're setting settlementDays = 1. Since you want the discount
set the evaluation date to the 17th. You don't have to worry about
> More on approach A
> ///// approach A
> Finally, if you want to change the evaluation date but keep the
> forward rates fixed (that is, to have discount=1 at 09/17/12 and to
> have the forward rate between, say, 03/17/13 and 06/17/13 to be the
> same as in the original curve) you can use the ImpliedTermStructure
> class. It takes the original curve and a new reference date, and
> builds a curve with the property above.
> //////
>
> With the approach A, I used to term structures in the program,
> TB13WksRateTermStructure, which is basically the original index rate, is
> used in calling FloatingRateBond FRN whose evaluation date is 07/31/12.
> discountRateTermStructureImplied is (TB13WksRateTermStructure+Discount
> Margin) that is used in FRN.setPricingEngine(FRNEngine) and its evaluation
> date is 09/13/12. But setting the evaluation date for
> discountRateTermStructureImplied doesn't make any difference for the final
> results, as shown below:
> ---------------------------Date(13, September, 2012)
> boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new
> ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(13,
> September, 2012)));
> --Today is September 13th, 2012
> FRN Net present value1000267.9088
> FRN Clean price99.999275416
> FRN Dirty price100.02740216
> 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
> Actual/360 simple compounding
> 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
> 0 D discountRateTermStructureImplied->zeroRate: September 13th, 2012 |
> 0.220000 % Actual/360 simple compounding
> 0 D discountRateTermStructureImplied->discount: September 13th, 2012 | 1
>
> --------------------------------Date(31, July, 2012)
> boost::shared_ptr<YieldTermStructure> discountRateTermStructureImplied(new
> ImpliedTermStructure(discountRateTermStructureHandleImplied, Date(31, July,
> 2012)));
> Today is September 13th, 2012
> FRN Net present value999998.98404
> FRN Clean price99.999275416
> FRN Dirty price100.02740216
> 0 T TB13WksRateTermStructure->zeroRate: July 31st, 2012 | 0.095000 %
> Actual/360 simple compounding
> 0 T TB13WksRateTermStructure->discount: July 31st, 2012 | 1
> 0 D discountRateTermStructureImplied->zeroRate: July 31st, 2012 | 0.215000
> % Actual/360 simple compounding
> 0 D discountRateTermStructureImplied->discount: July 31st, 2012 | 1
>
>
> It seems that it doesn't make difference in the price on which term
> structure the priceEngine links to. How can that be? May be the priceEngine
> automatically linked to the term structure defined by <IborIndex> when
> calling the FloatingRateBond?
>
>
> Thanks for your help.
>
>
>
> On Thu, Nov 7, 2013 at 7:52 PM, Steve <
[hidden email]> wrote:
>>
>> more on approach B
>> //////// Approach B
>> If you want to keep your zero-rate data as given, that is, if you want
>> discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>> as you gave to the interpolated curve, you'll have to rebuild your
>> curve; that is, remove the data before 09/17/12, add a new data point
>> at 09/17/12 as the first point, and rebuild your curve.
>> ////////////
>>
>> the program will not error out with 'egative time (-0.0111111) given' and
>> give some result after the first date in the input index rate file was moved
>> from 09/18 to 09/13. But it is not right, because the discount factor should
>> be 1 on 09/18 not 09/13. The reason it doesn't error out once the first date
>> in the file is 09/13 not 09/18 is that the fixingDays=-3, which is due to
>> the fact that the interested start to accrue on 09/13 not 09/18, thought the
>> discount factor should be 1 on 09/18. This is because the instrument used
>> for index rate is issued every Thursday. So the dilemma is that the date
>> when the interest accrual starts and the date where discount factor equals
>> to 1 are different! That only invalidate the approach B. But I would think
>> someone must have dealt this kind of dilemma long ago.
>>
>>
>> On Thu, Nov 7, 2013 at 12:22 AM, Steve <
[hidden email]> wrote:
>>>
>>> Luigi,
>>>
>>> I was not able to make the program much smaller than it used to be. I
>>> simply removed the printing sections. I divided the code to two programs,
>>> one for the approach A and the other for the approach B. They are almost
>>> identical except that the approach B uses ASDateOriginal.dat and
>>> IndexRateOriginal.dat, the approach A removes any index before 9/18/12 and
>>> use ImpliedTermStructure to set evaluation date for term structure used by
>>> floating rate note price engine to 09/13/12. Somehow, resetting the
>>> evaluation date doesn't make any difference in the result
>>>
>>> In the approach A, the program use 07/01/12 as the evaluation date for
>>> TB13WksRateTermStructure that is the input when calling FloatingRateBond
>>> FRN(...). the evaluation date for discountRateTermStructureImplied that is
>>> used in FRN.setPricingEngine. Actually, I am not sure that index structure
>>> in FRN and the term structure used in its price engine can have two
>>> different evaluation date. this approach erred out with 'negative time
>>> (-0.0111111) given'
>>>
>>> the program for A and B attached. also the data file for A and B are
>>> attached. B uses *original* files
>>>
>>> Thank you!
>>>
>>>
>>> On Mon, Nov 4, 2013 at 3:39 AM, Luigi Ballabio <
[hidden email]>
>>> wrote:
>>>>
>>>> Can you post a minimal program to replicate this?
>>>>
>>>> Luigi
>>>>
>>>> On Tue, Oct 29, 2013 at 1:05 AM, song xu <
[hidden email]> wrote:
>>>> > Luigi,
>>>> >
>>>> > Thank you very much for your time and help!
>>>> >
>>>> > ///// approach A
>>>> > Finally, if you want to change the evaluation date but keep the
>>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>>>> > same as in the original curve) you can use the ImpliedTermStructure
>>>> > class. It takes the original curve and a new reference date, and
>>>> > builds a curve with the property above.
>>>> > //////
>>>> > I use two yield term structure. TB13WksRateTermStructure, basically is
>>>> > the
>>>> > zero rate of original file whose evaluation date is 7/31 because the
>>>> > original file starts with 7/31/12. Then I use ImpliedTermStructure to
>>>> > set
>>>> > the evaluation date to 09/18 to create another yield term structure,
>>>> > discountRateTermStructureImplied. TB13WksRateTermStructure is the
>>>> > input for
>>>> > FloatingRateBond FRN and discountRateTermStructureImplied is linked to
>>>> > FRNEngine. But the result, dirty/clean price turns out to be the same
>>>> > as
>>>> > before the evaluation date of the yield term structured used for the
>>>> > engine
>>>> > was set to 09/18/12. Any way, it doesn't make difference on the price.
>>>> >
>>>> > //////// Approach B
>>>> > If you want to keep your zero-rate data as given, that is, if you want
>>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>>>> > as you gave to the interpolated curve, you'll have to rebuild your
>>>> > curve; that is, remove the data before 09/17/12, add a new data point
>>>> > at 09/17/12 as the first point, and rebuild your curve.
>>>> > ////////////
>>>> > I remove the data before 09/18/12 from both the index file and the
>>>> > accrual
>>>> > date file. But the program errored out with
>>>> > AccuralStartSize = 680
>>>> > IndexRateFileSize = 680
>>>> > negative time (-0.0111111) given
>>>> >
>>>> > I tried to locate where exactly the program failed. The closest I
>>>> > could get
>>>> > is
>>>> >> DMCalc-evaluationDate.exe!QuantLib::LazyObject::calculate() Line 152
>>>> >> C++
>>>> > DMCalc-evaluationDate.exe!QuantLib::Instrument::calculate() Line
>>>> > 155 C++
>>>> > DMCalc-evaluationDate.exe!QuantLib::Instrument::NPV() Line 187 +
>>>> > 0xe
>>>> > bytes C++
>>>> > DMCalc-evaluationDate.exe!main(int __formal, int __formal) Line 258
>>>> > + 0xb
>>>> > bytes C++
>>>> > DMCalc-evaluationDate.exe!__tmainCRTStartup() Line 555 + 0x19 bytes
>>>> > C
>>>> > DMCalc-evaluationDate.exe!mainCRTStartup() Line 371 C
>>>> > it failed while calculate NPV().
>>>> >
>>>> > So my questions is why setting the evaluation date to 09/18 for the
>>>> > discount
>>>> > term structure used for price engine didn't make any difference on
>>>> > price and
>>>> > what could be possible reason that the approach B failed. Your help
>>>> > will be
>>>> > greatly appreciated.
>>>> >
>>>> > Best Regards,
>>>> > Steve
>>>> >
>>>> >
>>>> > From: Luigi Ballabio <
[hidden email]>
>>>> > To: Steve <
[hidden email]>
>>>> > Cc: QuantLib users <
[hidden email]>
>>>> > Sent: Friday, October 4, 2013 9:23 AM
>>>> > Subject: Re: [Quantlib-users] pricing a floating rate bond
>>>> >
>>>> > Steve,
>>>> > just setting the evaluation date doesn't work because if you
>>>> >
>>>> > specify a reference date for the curve, it overrides the evaluation
>>>> > date. For InterpolatedZeroCurve, that's done implicitly by using
>>>> > the
>>>> >
>>>> > first passed date as reference date. (For more info, see
>>>> >
>>>> > <
http://implementingquantlib.blogspot.com/2013/09/chapter-3-part-1-of-n-term-structures.html>).
>>>> >
>>>> > Now, there are solutions for this, but there are different possible
>>>> > behaviors when moving the reference date (as you tried to do when
>>>> > changing the evaluation date) and you'll have to choose the
>>>> > solution
>>>> >
>>>> > based on the one you want.
>>>> >
>>>> > If you want to keep your zero-rate data as given, that is, if you want
>>>> > discount = 1 at 09/17/12 and the zero rate at 09/17/13 to be the same
>>>> > as you gave to the interpolated curve, you'll have to rebuild
>>>> > your
>>>> >
>>>> > curve; that is, remove the data before 09/17/12, add a new data point
>>>> > at 09/17/12 as the first point, and rebuild your curve.
>>>> >
>>>> > If you want to move the whole thing two months ahead (that is, to have
>>>> > discount = 1 at 09/17/12 instead of 07/31/12 and to have the zero rate
>>>> > at 09/17/14 equal to the one you had at 07/31/14 before) you'll
>>>> > also
>>>> >
>>>> > have to rebuild your data set and build a new curve. For other types
>>>> > of curves (not for InterpolatedZeroCurve, though) it's possible
>>>> > to
>>>> >
>>>> > have this done automatically when the evaluation date changes; see the
>>>> > link I've posted above.
>>>> >
>>>> >
>>>> > Finally, if you want to change the evaluation date but keep the
>>>> > forward rates fixed (that is, to have discount=1 at 09/17/12 and to
>>>> > have the forward rate between, say, 03/17/13 and 06/17/13 to be the
>>>> > same as in the original curve) you can use the ImpliedTermStructure
>>>> > class. It takes the original curve and a new reference date, and
>>>> > builds a curve with the property above.
>>>> >
>>>> > Later,
>>>> > Luigi
>>>> >
>>>> >
>>>> > On Mon, Sep 30, 2013 at 3:31 AM, Steve <
[hidden email]> wrote:
>>>> >> Luiqi,
>>>> >>
>>>> >> Thank you for your help. I found one of the root problems. I used
>>>> >> InterpolatedZeroCurve to return the corresponding Interpolation
>>>> >> instance,
>>>> >> given a set of data point dated between 07/31/12 and 07/31/14.
>>>> >> However, I
>>>> >> intended to set 09/19/12 as the settlement date and I did so in the
>>>> >> program
>>>> >> using Settings::instance().evaluationDate(). But I just found out
>>>> >> that the
>>>> >> discount=1 at 07/31/12 instead of 09/17/12. That causes a bit off in
>>>> >> discount factors and in turn in clean and dirty prices. Please see
>>>> >> the
>>>> >> attachment for the program. I wonder why assigning Settings
>>>> >> doesn't
>>>> >> work. Do
>>>> >
>>>> >> I need to define YieldTermStructure instance with a specified
>>>> >> reference
>>>> >> date?
>>>> >>
>>>> >> ===========setting evaluation date
>>>> >> Natural settlementDays = 1;
>>>> >> Integer fixingDays = 4;
>>>> >>
>>>> >> DayCounter DMCalcCounter = Actual360();
>>>> >> Calendar DMCalccalendar = UnitedStates(UnitedStates::GovernmentBond);
>>>> >>
>>>> >> Date settlementDate(19, September, 2012);
>>>> >> // must be a business day
>>>> >> settlementDate = DMCalccalendar.adjust(settlementDate);
>>>> >>
>>>> >> Date todaysDate = DMCalccalendar.advance(settlementDate,
>>>> >> -fixingDays, Days);
>>>> >> cout << "Today is " << todaysDate << endl;
>>>> >> // nothing to do with Date::todaysDate
>>>> >> Settings::instance().evaluationDate() = todaysDate;
>>>> >>
>>>> >> =============discount factor
>>>> >> 0 zero rate July 31st, 2012 ^^^ 0.215000 % Actual/360 simple
>>>> >> compounding
>>>> >> 0 discount factor July 31st, 2012 ^^^ 1
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Aug 27, 2013 at 9:17 AM, Luigi Ballabio
>>>> >> <
[hidden email]>
>>>> >> wrote:
>>>> >>>
>>>> >>> Steve,
>>>> >>> InterpolatedZeroCurve expects continuously compounded zero rates,
>>>> >>> so the 0.00105 rate you're passing gets interpreted as such.
>>>> >>> When
>>>> >>> you
>>>> >
>>>> >>> later ask for the index fixing, the code calculates the
>>>> >>> corresponding
>>>> >>> simply compounded rate, which is the 0.00105014 you're seeing
>>>> >>> (it's
>>>> >
>>>> >>> basically the rate r2 so that (1+r2*T) = exp(r1*T), with T = 13
>>>> >>> weeks
>>>> >>> in your case and r1 = 0.00105). You can try converting your 0.00105
>>>> >>> to the correspondingly continuously compounded rate (same formula as
>>>> >>> above, but inverted) and pass that one to the curve.
>>>> >>>
>>>> >>> However, this will work only as long as the rate is constant. If the
>>>> >>> forecast index fixings vary in time, the zero rates will no longer
>>>> >>> be
>>>> >>> the same as the index rates, even converting the compounding (the
>>>> >>> zero
>>>> >>> rates are the average of the forward rates). You'd be much
>>>> >>> better
>>>> >>> off
>>>> >
>>>> >>> if your system could give you, for instance, sampled discount
>>>> >>> factors
>>>> >>> at the same dates. Otherwise you'll have to figure out the zero
>>>> >>> rates
>>>> >
>>>> >>> or the discount factors yourself.
>>>> >>>
>>>> >>> Hope this helps,
>>>> >>> Luigi
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Tue, Aug 13, 2013 at 10:28 AM, Luigi Ballabio
>>>> >>> <
[hidden email]> wrote:
>>>> >>> > Steve,
>>>> >>> > may you send the data files you're using so that we can
>>>> >>> > actually
>>>> >
>>>> >>> > run your code?
>>>> >>> >
>>>> >>> > Luigi
>>>> >>> >
>>>> >>> > On Fri, Aug 2, 2013 at 12:36 PM, Steve <
[hidden email]> wrote:
>>>> >>> >> Luigi,
>>>> >>> >>
>>>> >>> >> I tried to use IborIndex to price the floating note. The result
>>>> >>> >> is
>>>> >>> >> about
>>>> >>> >> 0.0036% off from the correct answer. There are many factors that
>>>> >>> >> contribute
>>>> >>> >> to this discrepancy. But I think the main reason is that the
>>>> >>> >> forecastfixing
>>>> >>> >> is about 0.013% off from the index rate. Below are the code
>>>> >>> >> printing
>>>> >>> >> out
>>>> >>> >> forecastfixing and some of the index rate:
>>>> >>> >> for(int i=0;i<AccuralStart.size();i++){
>>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>>>> >>> >> AccuralStart[i] <
>>>> >>> >> settlementDate){
>>>> >>> >> FRN13Wks->addFixing(AccuralStart[i], IndexRate[i]);
>>>> >>> >> junk << AccuralStart[i] << " +++ " <<
>>>> >>> >> FRN13Wks->fixing(AccuralStart[i])
>>>> >>> >> << "
>>>> >>> >> +++ " << IndexRate[i] << endl;
>>>> >>> >> }
>>>> >>> >> if(FRN13Wks->isValidFixingDate(AccuralStart[i]) &&
>>>> >>> >> AccuralStart[i] >=
>>>> >>> >> settlementDate){
>>>> >>> >> junk << AccuralStart[i] << " ``` " <<
>>>> >>> >> FRN13Wks->forecastFixing(AccuralStart[i]) << " ``` " <<
>>>> >>> >> IndexRate[i]
>>>> >>> >> <<
>>>> >>> >> endl;
>>>> >>> >> }
>>>> >>> >> }
>>>> >>> >>
>>>> >>> >> September 11th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 12th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 13th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 14th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 17th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 18th, 2012 +++ 0.001 +++ 0.001
>>>> >>> >> September 19th, 2012 ``` 0.00105014 ``` 0.001
>>>> >>> >> September 20th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 21st, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 24th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 25th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 26th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 27th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >> September 28th, 2012 ``` 0.00105014 ``` 0.00105
>>>> >>> >>
>>>> >>> >> Basically, the forcastfixing is CONSTANTLY 0.00000014 about the
>>>> >>> >> index
>>>> >>> >> rate
>>>> >>> >> after the settlement date, Sept 19th, 2012, all the way to the
>>>> >>> >> maturity
>>>> >>> >> date. Can you or anyone to help me to understand where 0.00000014
>>>> >>> >> comes
>>>> >>> >> from?
>>>> >>> >>
>>>> >>> >> Thanks
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> On Fri, Jul 19, 2013 at 5:49 PM, Luigi Ballabio
>>>> >>> >> <
[hidden email]>
>>>> >>> >> wrote:
>>>> >>> >>>
>>>> >>> >>> On Sat, Jul 13, 2013 at 1:25 AM, Steve <
[hidden email]> wrote:
>>>> >>> >>> > I am trying to price a floating rate bond that depends on the
>>>> >>> >>> > rate
>>>> >>> >>> > of a
>>>> >>> >>> > Treasury instrument. For simplicity, the rate and the date are
>>>> >>> >>> > imported
>>>> >>> >>> > from
>>>> >>> >>> > the file. But I used IborIndex class for the rate of the
>>>> >>> >>> > instrument.
>>>> >>> >>> > Unsurprisingly, the result is way off. So I have a few
>>>> >>> >>> > questions on
>>>> >>> >>> > this
>>>> >>> >>> > topic:
>>>> >>> >>> >
>>>> >>> >>> > 1 is there an equivalent index class for the Treasury
>>>> >>> >>> > instrument,
>>>> >>> >>> > like
>>>> >>> >>> > IborIndex for LIBOR, in QuantLib?
>>>> >>> >>>
>>>> >>> >>> Not as such. You might use IborIndex as a proxy, provided that
>>>> >>> >>> the
>>>> >>> >>> conventions match; for instance, the LIBOR rate is simply
>>>> >>> >>> compounded,
>>>> >>> >>> with an Actual/360 day-count convention in the case of USD
>>>> >>> >>> LIBOR. As
>>>> >>> >>> far as I know, T-bills are quoted as a discount; how is the rate
>>>> >>> >>> of
>>>> >>> >>> your Treasury instrument derived from that? And instead of
>>>> >>> >>> looking
>>>> >>> >>> at
>>>> >>> >>> the price of the bond (that is, at the sum of the coupons, which
>>>> >>> >>> muddies things), have you tried first looking at forecast
>>>> >>> >>> IborIndex
>>>> >>> >>> fixings to see if they match the rates you expect?
>>>> >>> >>>
>>>> >>> >>> > 2 if the answer is no, is it possible to build a class like
>>>> >>> >>> > TreasuryIndex by
>>>> >>> >>> > extending InterestRateIndex? What would be the challenge in
>>>> >>> >>> > building
>>>> >>> >>> > TreasuryIndex?
>>>> >>> >>>
>>>> >>> >>> You would have to implement the forecastFixing method so that it
>>>> >>> >>> returns the T-Bill rate. Basically, you'd have to be able
>>>> >>> >>> to
>>>> >>> >>> forecast
>>>> >>> >>> the rate off your treasury curve. (You'd also have to
>>>> >>> >>> implement
>>>> >>> >>> the
>>>> >>> >>> maturityDate method, but that's easy).
>>>> >
>>>> >>> >>>
>>>> >>> >>> > 3 Is it possible to use IborIndex for a Treasury instrument by
>>>> >>> >>> > tweaking
>>>> >>> >>> > the
>>>> >>> >>> > calendar alone? What else needs to be done to make it work?
>>>> >>> >>>
>>>> >>> >>> See above. It depends on how much the conventions differ.
>>>> >>> >>>
>>>> >>> >>> > 4 Can someone point me to the right direction on how to
>>>> >>> >>> > leverage
>>>> >>> >>> > QuantLib classes to price a floating rate bond that uses a
>>>> >>> >>> > Treasury
>>>> >>> >>> > instrument as the index after a peek at the code?
>>>> >>> >>>
>>>> >>> >>> If using IborIndex fails, inheriting from InterestRateIndex
>>>> >>> >>> shouldn't
>>>> >
>>>> >>> >>> be that difficult. Once you have a rate class, you should be
>>>> >>> >>> able to
>>>> >>> >>> use the existing classes as you did in your code.
>>>> >>> >>>
>>>> >>> >>> Let me know how it works.
>>>> >>> >>>
>>>> >>> >>> Later,
>>>> >>> >>> Luigi
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> --
>>>> >>> >>> <
https://implementingquantlib.blogspot.com/>
>>>> >>> >>> <
https://twitter.com/lballabio>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >
>>>> >>> >
>>>> >>> >
>>>> >>> > --
>>>> >>> > <
https://implementingquantlib.blogspot.com/>
>>>> >>> > <
https://twitter.com/lballabio>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> <
https://implementingquantlib.blogspot.com/>
>>>> >>> <
https://twitter.com/lballabio>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > <
https://implementingquantlib.blogspot.com/>
>>>> > <
https://twitter.com/lballabio>
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > October Webinars: Code for Performance
>>>> > Free Intel webinars can help you accelerate application performance.
>>>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> > most
>>>> > from
>>>> > the latest Intel processors and coprocessors. See abstracts and
>>>> > register >
>>>> >
>>>> >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk>>>> >
>>>> > _______________________________________________
>>>> > QuantLib-users mailing list
>>>> >
[hidden email]
>>>> >
https://lists.sourceforge.net/lists/listinfo/quantlib-users>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> <
https://implementingquantlib.blogspot.com>
>>>> <
https://twitter.com/lballabio>
>>>
>>>
>>
>
conversations that shape the rapidly evolving mobile landscape. Sign up now.