quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Candidate 0.3.13 tarballs

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

On 07/28/2006 11:48:14 PM, Dirk Eddelbuettel wrote:
> it failed on hppa with an actual error.

Dirk,
	apologies for the delay. You might try to patch the source for =20
hppa only (can you do this?)  I'm attaching the (untested) patch to =20
this message.

Later,
	Luigi


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

Steinbach's Guideline for Systems Programming:
	Never test for an error condition you don't know how to handle.

Re: [Quantlib-dev] callable bonds

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

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 =20
> the economy of the first method but the ConvertibleBond class is =20
> designed the second way, so was not sure how to proceed.
>=20
> (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 =20
kind of bond it's being passed---or at least what kind of coupons it =20
contains. I.e., if you choose a tree engine, fixed-rate and =20
floating-rate coupons will be discounted in a different way on the =20
tree. Therefore, the above mightn't be as generic as it seems.


>   (2)
>   Analogous to the ConvertibleBond class, we would have three =20
> explicit constructors for each of three types of bonds ( =20
> CallableZeroCouponBond , CallableFloatingRateBond , =20
> CallableFixedCouponBond ).

This might be less nice, but it has the advantage of specifying the =20
kind of bond to be called. I would go for this one first; after the =20
code is done, we might try some refactoring to bring it closer to the =20
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 =20
look at the relevant classes---Callability and such---so that you can =20
reuse them.)

Later,
	Luigi


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

Cogito ergo I'm right and you're wrong.
-- Blair Houghton

Re: [Quantlib-dev] [Quantlib-users] ZeroSpreadedTermStructure

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

On 07/31/2006 11:02:40 AM, Roland Lichters wrote:
> I'd like to propose adding a slightly generalized version (I called =20
> it "ZeroSpreadTermStructure") to the library that takes a vector of =20
> spread quotes and interpolates linearly between them, see the =20
> attached file.

Roland,
	thanks for the patch---yes, I'm interested in the feature. I'll =20
have a look at it when I come back from vacation (2 weeks starting =20
tomorrow.)

Later,
	Luigi


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

There are two ways to write error-free programs; only the third one =20
works.
-- unknown

Re: [Quantlib-dev] Pricing Callable Capped Floaters within a HullWhite Tree

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

On 07/19/2006 09:40:46 AM, Toyin Akin wrote:
> I am looking at the possibility of pricing callable capped floater =20
> using QuantLib and it seems like most of the code to price such a =20
> product is more or less within Quantlib already (parts of the logic =20
> is present in different classes).

Toyin,
	I'm afraid I don't have time to go much into details (I'll be =20
in vacation for two weeks starting today and I have a few things to =20
finish before I leave.) However, the implementation of the payoff is as =20
you sketched. As for the callable part, you can look at the code in =20
DiscretizedSwaption for inspiration. Basically, at each exercise date =20
you'll find the value of the note (Libor + cap) as you explained. The =20
exercise price is paid at the exercise date itself, so at the i-th node =20
you'll just set value[i] =3D min(value[i], price).

Hope this helps,
	Luigi


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

The box said "Use Windows 95 or better," so I got a Macintosh.

Re: [Quantlib-dev] QuantLib-dev Digest, Vol 3, Issue 1

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

Hi Joe,
 
The LMM model is to model payoffs that can be decomposed into forward rates  
and their  correlations.  Swap rates could be used also.   Basically its a 
multi factor interest rate model.
 
I dont think LMM is ideal for valuing convertible bonds where we have one  
stock and one underlying bond.
 
 
Regards
 
Theo

Re: [Quantlib-dev] Projects/cleanups in market model code

[Ferdinando A. <na...@am...>]

On 8/2/06, Joseph Wang <jo...@gn...> wrote:
> Are there any small projects and cleanups in the market model code that need
> to be made.  I've got Rebanto's book, and I'd like to get a small project so
> that I can get my hands dirty with the code.

1) write the one-step and multiple-step MarketModelProduct for pricing
all co-initial plain vanilla swaps. Follows the Caplet and Forward
Rate MarketModelProduct implementation as blueprint. Test the pricing
is not affected by the forward libor correlation model
2) write the one-step and multiple-step MarketModelProduct that price
all Forward, Caplets, and Co-initial Swaps at the same time. A
composite pattern should be preferred

ciao -- Nando

PS please do not cross-post to quantlib-users when the subject relates
to developing QuantLib, especially if the code you are referring to is
not yet released

[Quantlib-dev] Projects/cleanups in market model code

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

Are there any small projects and cleanups in the market model code that need 
to be made.  I've got Rebanto's book, and I'd like to get a small project so 
that I can get my hands dirty with the code.

Also, does anyone know if LMM has been used to value convertible bonds?  It 
seems like one would just need to add a stock process.

Re: [Quantlib-dev] cvsgrab

[Lars S. <sch...@ya...>]

I got this answer on the cvsgrab mailing list.

Sourceforge is now on ViewVC 1.0, which is not currently supported by CVSGrab  2.2.2. 
You can try the 2.2.3-SNAPSHOT version available at http://www.picoservice.com/cvsgrab

it works!
 
Lars


Luigi Ballabio <lui...@gm...> wrote: 
On 07/25/2006 08:38:37 AM, Lars Schouw wrote:
> Does anyone know how I get the sources checked out from cvs using cvs
> grab?

I haven't tried cvsgrab, so I can't confirm it works. The WebCVS  
interface is at .  
However, you'll probably want to get a single module, e.g.,  
. You can try  
passing the latter URL to cvsgrab and see what happens...


> Alternatively is there a tar ball for the nightly regression tests
> that I can download?

No, there's no nightly regression.

Later,
 Luigi



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

Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away.
-- Antoine de Saint-Exupery


 		
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.

[Quantlib-dev] callable bonds

[Allen K. <all...@ya...>]

Hi:
   
  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.
  
Thanks,
  Allen
   
  
(1) 
  class CallableBond : public Bond {
 public:
     CallableBond(const boost::shared_ptr<Bond> bond&
                      const boost::shared_ptr<PricingEngine>& engine,
                      const CallabilitySchedule& callability,
                      );
   etc.
 }
   
  i.e. first need to construct a FixedCouponBond, FloatingRateBond or ZeroCouponBond and then pass it in to the CallableBond constructor (which then implicitly defines the callable bond). Theoretically, a ConvertibleBond could also be passed into the constructor to make it callable, though some equity/interest rate correlations would have to be handled/modeled within it.
   
  (2) 
  Analogous to the ConvertibleBond class, we would have three explicit constructors for
each of three types of bonds ( CallableZeroCouponBond , CallableFloatingRateBond , 
CallableFixedCouponBond ). Doing it this way, in the future though, we might need three more constructors for convertible bonds: CallableConvertibleFloatingRateBond,  
CallableConvertibleFixedCouponBond, CallableConvertibleZeroCouponBond.
   
  Example below, analogous to ConvertibleBond class:
  
class CallableBond : public Bond {
 public:
     CallableBond( .... ); 
}
  
class CallableZeroCouponBond : public CallableBond {
 public:
     CallableZeroCouponBond( .... ); 
}
  
class CallableFloatingRateBond : public CallableBond {
 public:
     CallableFloatingRateBond( .... );
}
  
class CallableFixedCouponBond : public CallableBond {
 public:
     CallableFixedCouponBond( .... ); 
}


 			
---------------------------------
See the all-new, redesigned Yahoo.com.  Check it out.

[Quantlib-dev] ZeroSpreadedTermStructure

[Roland L. <rol...@go...>]

I2lmbmRlZiBxdWFudGxpYl96ZXJvX3NwcmVhZF90ZXJtX3N0cnVjdHVyZV9ocHAKI2RlZmluZSBx
dWFudGxpYl96ZXJvX3NwcmVhZF90ZXJtX3N0cnVjdHVyZV9ocHAKCiNpbmNsdWRlIDxxbC9UZXJt
U3RydWN0dXJlcy96ZXJveWllbGRzdHJ1Y3R1cmUuaHBwPgojaW5jbHVkZSA8cWwvcXVvdGUuaHBw
PgoKbmFtZXNwYWNlIFF1YW50TGliIHsKCiAgLy8hIFRlcm0gc3RydWN0dXJlIHdpdGggYW4gYWRk
ZWQgdmVjdG9yIG9mIHNwcmVhZHMgb24gdGhlIHplcm8geWllbGQgcmF0ZQogIC8qISBcbm90ZSBU
aGlzIHRlcm0gc3RydWN0dXJlIHdpbGwgcmVtYWluIGxpbmtlZCB0byB0aGUgb3JpZ2luYWwKICAg
IHN0cnVjdHVyZSwgaS5lLiwgYW55IGNoYW5nZXMgaW4gdGhlIGxhdHRlciB3aWxsIGJlCiAgICBy
ZWZsZWN0ZWQgaW4gdGhpcyBzdHJ1Y3R1cmUgYXMgd2VsbC4KCiAgICBcaW5ncm91cCB5aWVsZHRl
cm1zdHJ1Y3R1cmVzCiAgKi8KICBjbGFzcyBaZXJvU3ByZWFkVGVybVN0cnVjdHVyZSA6IHB1Ymxp
YyBaZXJvWWllbGRTdHJ1Y3R1cmUgewogIHB1YmxpYzoKICAgIFplcm9TcHJlYWRUZXJtU3RydWN0
dXJlKGNvbnN0IEhhbmRsZTxZaWVsZFRlcm1TdHJ1Y3R1cmU+JiwKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgY29uc3Qgc3RkOjp2ZWN0b3I8SGFuZGxlPFF1b3RlPiA+JiBzcHJlYWQsCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0ZDo6dmVjdG9yPERhdGU+JiBkYXRl
KTsKICAgIC8vISBcbmFtZSBZaWVsZFRlcm1TdHJ1Y3R1cmUgaW50ZXJmYWNlCiAgICAvL0B7CiAg
ICBEYXlDb3VudGVyIGRheUNvdW50ZXIoKSBjb25zdCB7IHJldHVybiBvcmlnaW5hbEN1cnZlXy0+
ZGF5Q291bnRlcigpOyB9CiAgICBDYWxlbmRhciBjYWxlbmRhcigpIGNvbnN0OwogICAgY29uc3Qg
RGF0ZSYgcmVmZXJlbmNlRGF0ZSgpIGNvbnN0OwogICAgRGF0ZSBtYXhEYXRlKCkgY29uc3Q7CiAg
ICBUaW1lIG1heFRpbWUoKSBjb25zdDsKICAgIC8vQH0KICBwcm90ZWN0ZWQ6CiAgICAvLyEgcmV0
dXJucyB0aGUgc3ByZWFkZWQgemVybyB5aWVsZCByYXRlCiAgICBSYXRlIHplcm9ZaWVsZEltcGwo
VGltZSkgY29uc3Q7CiAgICAvLyEgcmV0dXJucyB0aGUgc3ByZWFkZWQgZm9yd2FyZCByYXRlCiAg
ICAvKiBUaGlzIG1ldGhvZCBtdXN0IGRpc2FwcGVhciBzaG91bGQgdGhlIHNwcmVhZCBiZWNvbWUg
YSBjdXJ2ZSAqLwogICAgUmF0ZSBmb3J3YXJkSW1wbChUaW1lKSBjb25zdDsKICBwcml2YXRlOgog
ICAgSGFuZGxlPFlpZWxkVGVybVN0cnVjdHVyZT4gb3JpZ2luYWxDdXJ2ZV87CiAgICBzdGQ6OnZl
Y3RvcjxIYW5kbGU8UXVvdGU+ID4gc3ByZWFkXzsKICAgIHN0ZDo6dmVjdG9yPFRpbWU+IHRpbWVf
OwogIH07CgogIGlubGluZSBaZXJvU3ByZWFkVGVybVN0cnVjdHVyZTo6WmVyb1NwcmVhZFRlcm1T
dHJ1Y3R1cmUoCiAgICBjb25zdCBIYW5kbGU8WWllbGRUZXJtU3RydWN0dXJlPiYgaCwKICAgIGNv
bnN0IHN0ZDo6dmVjdG9yPEhhbmRsZTxRdW90ZT4gPiYgc3ByZWFkLAogICAgY29uc3Qgc3RkOjp2
ZWN0b3I8RGF0ZT4mIGRhdGUgPSBzdGQ6OnZlY3RvcjxEYXRlPigwLERhdGUoKSkpCiAgICA6IG9y
aWdpbmFsQ3VydmVfKGgpLCBzcHJlYWRfKHNwcmVhZCkgewogICAgUUxfUkVRVUlSRSAoc3ByZWFk
Xy5zaXplKCkgPiAwLCAic3ByZWFkIHZlY3RvciBzaXplID0gMCIpOwovLyAgICAgUUxfUkVRVUlS
RSAoc3ByZWFkXy5zaXplKCkgPT0gZGF0ZS5zaXplKCkgfHwgc3ByZWFkXy5zaXplKCkgPT0gMSwK
Ly8gICAgICAgICAgICAgICAgICJzcHJlYWQgYW5kIGRhdGUgdmVjdG9yIGhhdmUgZGlmZmVyZW50
IHNpemUiKTsKICAgIHJlZ2lzdGVyV2l0aChvcmlnaW5hbEN1cnZlXyk7CiAgICBmb3IgKGludCBp
ID0gMDsgaSA8IHNwcmVhZF8uc2l6ZSgpOyBpKyspCiAgICAgIHJlZ2lzdGVyV2l0aChzcHJlYWRf
W2ldKTsKCiAgICBmb3IgKGludCBpID0gMDsgaSA8IGRhdGUuc2l6ZSgpOyBpKyspCiAgICAgIHRp
bWVfLnB1c2hfYmFjayAodGltZUZyb21SZWZlcmVuY2UgKGRhdGVbaV0pKTsKICB9CgogIGlubGlu
ZSBDYWxlbmRhciBaZXJvU3ByZWFkVGVybVN0cnVjdHVyZTo6Y2FsZW5kYXIoKSBjb25zdCB7CiAg
ICByZXR1cm4gb3JpZ2luYWxDdXJ2ZV8tPmNhbGVuZGFyKCk7CiAgfQoKICBpbmxpbmUgY29uc3Qg
RGF0ZSYgWmVyb1NwcmVhZFRlcm1TdHJ1Y3R1cmU6OnJlZmVyZW5jZURhdGUoKSBjb25zdCB7CiAg
ICByZXR1cm4gb3JpZ2luYWxDdXJ2ZV8tPnJlZmVyZW5jZURhdGUoKTsKICB9CgogIGlubGluZSBE
YXRlIFplcm9TcHJlYWRUZXJtU3RydWN0dXJlOjptYXhEYXRlKCkgY29uc3QgewogICAgICByZXR1
cm4gb3JpZ2luYWxDdXJ2ZV8tPm1heERhdGUoKTsKICB9CgogIGlubGluZSBUaW1lIFplcm9TcHJl
YWRUZXJtU3RydWN0dXJlOjptYXhUaW1lKCkgY29uc3QgewogICAgcmV0dXJuIG9yaWdpbmFsQ3Vy
dmVfLT5tYXhUaW1lKCk7CiAgfQoKICBpbmxpbmUgUmF0ZSBaZXJvU3ByZWFkVGVybVN0cnVjdHVy
ZTo6emVyb1lpZWxkSW1wbChUaW1lIHQpIGNvbnN0IHsKICAgIC8vIHJldHVybiBvcmlnaW5hbEN1
cnZlXy0+emVyb1lpZWxkKHQsIHRydWUpICsgc3ByZWFkXy0+dmFsdWUoKTsKICAgIGRvdWJsZSB6
ID0gb3JpZ2luYWxDdXJ2ZV8tPnplcm9SYXRlKHQsIENvbnRpbnVvdXMsIE5vRnJlcXVlbmN5LCB0
cnVlKTsKICAgIGlmICh0aW1lXy5zaXplKCkgPT0gMCB8fCB0IDw9IHRpbWVfWzBdKQogICAgICBy
ZXR1cm4geiArIHNwcmVhZF9bMF0tPnZhbHVlKCk7CiAgICBlbHNlIGlmICh0ID49IHRpbWVfLmJh
Y2soKSkKICAgICAgcmV0dXJuIHogKyBzcHJlYWRfLmJhY2soKS0+dmFsdWUoKTsKICAgIGVsc2Ug
ewogICAgICBpbnQgaTsKICAgICAgZm9yIChpID0gMDsgaSA8IHRpbWVfLnNpemUoKTsgaSsrKQog
ICAgICAgIGlmICh0aW1lX1tpXSA+IHQpIGJyZWFrOwogICAgICBkb3VibGUgZHQgPSB0aW1lX1tp
XSAtIHRpbWVfW2ktMV07CiAgICAgIHJldHVybiB6ICsgc3ByZWFkX1tpXS0+dmFsdWUoKSAqICh0
IC0gdGltZV9baS0xXSkgLyBkdAogICAgICAgICsgc3ByZWFkX1tpLTFdLT52YWx1ZSgpICogKHRp
bWVfW2ldIC0gdCkgLyBkdDsKICAgIH0KICB9CgogIGlubGluZSBSYXRlIFplcm9TcHJlYWRUZXJt
U3RydWN0dXJlOjpmb3J3YXJkSW1wbChUaW1lIHQpIGNvbnN0IHsKLy8gICAgIHJldHVybiBvcmln
aW5hbEN1cnZlXy0+Zm9yd2FyZFJhdGUodCwgdCwgQ29udGludW91cywgTm9GcmVxdWVuY3ksIHRy
dWUpCi8vICAgICAgICsgc3ByZWFkXy0+dmFsdWUoKTsKICAgIGRvdWJsZSBmPW9yaWdpbmFsQ3Vy
dmVfLT5mb3J3YXJkUmF0ZSh0LCB0LCBDb250aW51b3VzLCBOb0ZyZXF1ZW5jeSwgdHJ1ZSk7CiAg
ICBpZiAodGltZV8uc2l6ZSgpID09IDAgfHwgdCA8PSB0aW1lX1swXSkKICAgICAgcmV0dXJuIGYg
KyBzcHJlYWRfWzBdLT52YWx1ZSgpOwogICAgZWxzZSBpZiAodCA+PSB0aW1lXy5iYWNrKCkpCiAg
ICAgIHJldHVybiBmICsgc3ByZWFkXy5iYWNrKCktPnZhbHVlKCk7CiAgICBlbHNlIHsKICAgICAg
aW50IGk7CiAgICAgIGZvciAoaSA9IDA7IGkgPCB0aW1lXy5zaXplKCk7IGkrKykKICAgICAgICBp
ZiAodGltZV9baV0gPiB0KSBicmVhazsKICAgICAgZG91YmxlIGR0ID0gdGltZV9baV0gLSB0aW1l
X1tpLTFdOwogICAgICByZXR1cm4gZiArIHNwcmVhZF9baV0tPnZhbHVlKCkgKiAodCAtIHRpbWVf
W2ktMV0pIC8gZHQKICAgICAgICArIHNwcmVhZF9baS0xXS0+dmFsdWUoKSAqICh0aW1lX1tpXSAt
IHQpIC8gZHQ7CiAgICB9CiAgfQoKfQoKI2VuZGlmCg==

Re: [Quantlib-dev] Candidate 0.3.13 tarballs

[Dirk E. <ed...@de...>]

DQpPbiAyNiBKdWx5IDIwMDYgYXQgMTg6NDMsIEx1aWdpIEJhbGxhYmlvIHdyb3RlOg0KfCAJSSd2
ZSB1cGxvYWRlZCBjYW5kaWRhdGUgdGFyYmFsbHMgZm9yIHRoZSAwLjMuMTMgcmVsZWFzZSBpbnRv
ICANCnwgPGh0dHA6Ly9xdWFudGxpYi5vcmcvcHJlcmVsZWFzZS8+LiBQbGVhc2UgdHJ5IHRvIGNv
bXBpbGUgdGhlbSBhbmQgcnVuICANCnwgdGhlIHRlc3Qgc3VpdGUgb24geW91ciBtYWNoaW5lcy4g
SWYgdGhlcmUncyBubyBzaG93c3RvcHBlcnMsIEknbGwgIA0KfCByZWxlYXNlIHRoZW0gaW4gYSBm
ZXcgZGF5cyAoeWVzLCBEaXJrLCB0aGV5J3JlIHRoZSBmaW5hbCBvbmVzLikNCg0KV2l0aCBzcGVj
aWFsIHRoYW5rcyB0byBKb2VyZyBmcm9tIHRoZSBmdHAgbWFpbnRhaW5lciB0ZWFtLCB0aGUgbmV3
IHBhY2thZ2UNCih3aXRoIGl0cyBuZXcgbGlicmFyeS12ZXJzaW9uIGJhc2VkIG5hbWUgbGlicXVh
bnRsaWItMC4zLjEzKSB3YXMgYWRkZWQgYQ0KbWVyZSAxMiBob3VycyBhZnRlciBJIHVwbG9hZGVk
IGl0LiAgSXQgaGFzIGFscmVhZHkgaGl0IHRoZSBidWlsZCBkYWVtb25zIC0tDQpzZWUgaHR0cDov
L2J1aWxkZC5kZWJpYW4ub3JnL2J1aWxkLnBocD9wa2c9cXVhbnRsaWIgLS0gYW5kIHdlIGFscmVh
ZHkgaGF2ZQ0KZWlnaHQgc3VjY2Vzc2Z1bCBidWlsZHMuICBIb3dldmVyLCBhbmQgaGVyZSBpcyB0
aGUgYmFkIHBpZWNlOiBpdCBmYWlsZWQgb24NCmhwcGEgd2l0aCBhbiBhY3R1YWwgZXJyb3IuICBT
ZWUNCg0KbWFrZVs0XTogTGVhdmluZyBkaXJlY3RvcnkgYC9idWlsZC9idWlsZGQvcXVhbnRsaWIt
MC4zLjEzL3FsL1ZvbGF0aWxpdHlNb2RlbHMnDQptYWtlWzRdOiBFbnRlcmluZyBkaXJlY3Rvcnkg
YC9idWlsZC9idWlsZGQvcXVhbnRsaWItMC4zLjEzL3FsJw0KL2Jpbi9zaCAuLi9saWJ0b29sIC0t
dGFnPUNYWCAtLW1vZGU9bGluayBnKysgIC1PMiAtRF9SRUVOVFJBTlQgLWZwZXJtaXNzaXZlICAg
LW8gbGliUXVhbnRMaWIubGEgLXJwYXRoIC9idWlsZC9idWlsZGQvcXVhbnRsaWItMC4zLjEzL2Rl
Ymlhbi9saWJxdWFudGxpYi0wLjMuMTMvdXNyL2xpYiAtcmVsZWFzZSAwLjMuMTMgY2FsZW5kYXIu
bG8gY3VycmVuY3kubG8gZGF0ZS5sbyBkaXNjcmV0aXplZGFzc2V0LmxvIGVycm9ycy5sbyBleGNo
YW5nZXJhdGUubG8gZXhlcmNpc2UubG8gaW5kZXgubG8gaW50ZXJlc3RyYXRlLmxvIG1vbmV5Lmxv
IHByaWNlcy5sbyBzY2hlZHVsZS5sbyBzdG9jaGFzdGljcHJvY2Vzcy5sbyB0aW1lZ3JpZC5sbyB2
b2x0ZXJtc3RydWN0dXJlLmxvIENhbGVuZGFycy9saWJDYWxlbmRhcnMubGEgQ2FzaEZsb3dzL2xp
YkNhc2hGbG93cy5sYSBDdXJyZW5jaWVzL2xpYkN1cnJlbmNpZXMubGEgRGF5Q291bnRlcnMvbGli
RGF5Q291bnRlcnMubGEgRmluaXRlRGlmZmVyZW5jZXMvbGliRmluaXRlRGlmZmVyZW5jZXMubGEg
SW5kZXhlcy9saWJJbmRleGVzLmxhIEluc3RydW1lbnRzL2xpYkluc3RydW1lbnRzLmxhIExhdHRp
Y2VzL2xpYkxhdHRpY2VzLmxhIE1hdGgvbGliTWF0aC5sYSBNb250ZUNhcmxvL2xpYk1vbnRlQ2Fy
bG8ubGEgT3B0aW1pemF0aW9uL2xpYk9wdGltaXphdGlvbi5sYSBQcmljZXJzL2xpYlByaWNlcnMu
bGEgUHJpY2luZ0VuZ2luZXMvbGliUHJpY2luZ0VuZ2luZXMubGEgUHJvY2Vzc2VzL2xpYlByb2Nl
c3Nlcy5sYSBSYW5kb21OdW1iZXJzL2xpYlJhbmRvbU51bWJlcnMubGEgU2hvcnRSYXRlTW9kZWxz
L2xpYlNob3J0UmF0ZU1vZGVscy5sYSBUZXJtU3RydWN0dXJlcy9saWJUZXJtU3RydWN0dXJlcy5s
YSBVdGlsaXRpZXMvbGliVXRpbGl0aWVzLmxhIFZvbGF0aWxpdGllcy9saWJWb2xhdGlsaXRpZXMu
bGEgVm9sYXRpbGl0eU1vZGVscy9saWJWb2xhdGlsaXR5TW9kZWxzLmxhIA0KZysrIC1zaGFyZWQg
LW5vc3RkbGliIC91c3IvbGliL2djYy9ocHBhLWxpbnV4LWdudS80LjEuMi8uLi8uLi8uLi9jcnRp
Lm8gL3Vzci9saWIvZ2NjL2hwcGEtbGludXgtZ251LzQuMS4yL2NydGJlZ2luUy5vICAubGlicy9j
YWxlbmRhci5vIC5saWJzL2N1cnJlbmN5Lm8gLmxpYnMvZGF0ZS5vIC5saWJzL2Rpc2NyZXRpemVk
YXNzZXQubyAubGlicy9lcnJvcnMubyAubGlicy9leGNoYW5nZXJhdGUubyAubGlicy9leGVyY2lz
ZS5vIC5saWJzL2luZGV4Lm8gLmxpYnMvaW50ZXJlc3RyYXRlLm8gLmxpYnMvbW9uZXkubyAubGli
cy9wcmljZXMubyAubGlicy9zY2hlZHVsZS5vIC5saWJzL3N0b2NoYXN0aWNwcm9jZXNzLm8gLmxp
YnMvdGltZWdyaWQubyAubGlicy92b2x0ZXJtc3RydWN0dXJlLm8gLVdsLC0td2hvbGUtYXJjaGl2
ZSBDYWxlbmRhcnMvLmxpYnMvbGliQ2FsZW5kYXJzLmEgQ2FzaEZsb3dzLy5saWJzL2xpYkNhc2hG
bG93cy5hIEN1cnJlbmNpZXMvLmxpYnMvbGliQ3VycmVuY2llcy5hIERheUNvdW50ZXJzLy5saWJz
L2xpYkRheUNvdW50ZXJzLmEgRmluaXRlRGlmZmVyZW5jZXMvLmxpYnMvbGliRmluaXRlRGlmZmVy
ZW5jZXMuYSBJbmRleGVzLy5saWJzL2xpYkluZGV4ZXMuYSBJbnN0cnVtZW50cy8ubGlicy9saWJJ
bnN0cnVtZW50cy5hIExhdHRpY2VzLy5saWJzL2xpYkxhdHRpY2VzLmEgTWF0aC8ubGlicy9saWJN
YXRoLmEgTW9udGVDYXJsby8ubGlicy9saWJNb250ZUNhcmxvLmEgT3B0aW1pemF0aW9uLy5saWJz
L2xpYk9wdGltaXphdGlvbi5hIFByaWNlcnMvLmxpYnMvbGliUHJpY2Vycy5hIFByaWNpbmdFbmdp
bmVzLy5saWJzL2xpYlByaWNpbmdFbmdpbmVzLmEgUHJvY2Vzc2VzLy5saWJzL2xpYlByb2Nlc3Nl
cy5hIFJhbmRvbU51bWJlcnMvLmxpYnMvbGliUmFuZG9tTnVtYmVycy5hIFNob3J0UmF0ZU1vZGVs
cy8ubGlicy9saWJTaG9ydFJhdGVNb2RlbHMuYSBUZXJtU3RydWN0dXJlcy8ubGlicy9saWJUZXJt
U3RydWN0dXJlcy5hIFV0aWxpdGllcy8ubGlicy9saWJVdGlsaXRpZXMuYSBWb2xhdGlsaXRpZXMv
LmxpYnMvbGliVm9sYXRpbGl0aWVzLmEgVm9sYXRpbGl0eU1vZGVscy8ubGlicy9saWJWb2xhdGls
aXR5TW9kZWxzLmEgLVdsLC0tbm8td2hvbGUtYXJjaGl2ZSAgLUwvdXNyL2xpYi9nY2MvaHBwYS1s
aW51eC1nbnUvNC4xLjIgLUwvdXNyL2xpYi9nY2MvaHBwYS1saW51eC1nbnUvNC4xLjIvLi4vLi4v
Li4gLWxzdGRjKysgLWxtIC1sZ2NjIC1sYyAtbGdjY19zIC91c3IvbGliL2djYy9ocHBhLWxpbnV4
LWdudS80LjEuMi9jcnRlbmRTLm8gL3Vzci9saWIvZ2NjL2hwcGEtbGludXgtZ251LzQuMS4yLy4u
Ly4uLy4uL2NydG4ubyAgLVdsLC1zb25hbWUgLVdsLGxpYlF1YW50TGliLTAuMy4xMy5zbyAtbyAu
bGlicy9saWJRdWFudExpYi0wLjMuMTMuc28gIC1ML3Vzci9saWIvZ2NjL2hwcGEtbGludXgtZ251
LzQuMS4yIC1ML3Vzci9saWIvZ2NjL2hwcGEtbGludXgtZ251LzQuMS4yLy4uLy4uLy4uIC1sc3Rk
YysrIC1sbSAtbGdjYyAtbGMgLWxnY2Nfcw0KUHJpY2Vycy8ubGlicy9saWJQcmljZXJzLmEobWNk
aXNjcmV0ZWFyaXRobWV0aWNhc28ubyk6KC5kYXRhKzB4MCk6IG11bHRpcGxlIGRlZmluaXRpb24g
b2YgYF9aTjhRdWFudExpYjhNY1ByaWNlcklUX1QwX0UxMG1pblNhbXBsZV9FJw0KUHJpY2Vycy8u
bGlicy9saWJQcmljZXJzLmEobWNjbGlxdWV0b3B0aW9uLm8pOiguZGF0YSsweDApOiBmaXJzdCBk
ZWZpbmVkIGhlcmUNClByaWNlcnMvLmxpYnMvbGliUHJpY2Vycy5hKG1jZXZlcmVzdC5vKTooLmRh
dGErMHgwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgX1pOOFF1YW50TGliOE1jUHJpY2VySVRf
VDBfRTEwbWluU2FtcGxlX0UnDQpQcmljZXJzLy5saWJzL2xpYlByaWNlcnMuYShtY2NsaXF1ZXRv
cHRpb24ubyk6KC5kYXRhKzB4MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0KUHJpY2Vycy8ubGlicy9s
aWJQcmljZXJzLmEobWNoaW1hbGF5YS5vKTooLmRhdGErMHgwKTogbXVsdGlwbGUgZGVmaW5pdGlv
biBvZiBgX1pOOFF1YW50TGliOE1jUHJpY2VySVRfVDBfRTEwbWluU2FtcGxlX0UnDQpQcmljZXJz
Ly5saWJzL2xpYlByaWNlcnMuYShtY2NsaXF1ZXRvcHRpb24ubyk6KC5kYXRhKzB4MCk6IGZpcnN0
IGRlZmluZWQgaGVyZQ0KUHJpY2Vycy8ubGlicy9saWJQcmljZXJzLmEobWNtYXhiYXNrZXQubyk6
KC5kYXRhKzB4MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYF9aTjhRdWFudExpYjhNY1ByaWNl
cklUX1QwX0UxMG1pblNhbXBsZV9FJw0KUHJpY2Vycy8ubGlicy9saWJQcmljZXJzLmEobWNjbGlx
dWV0b3B0aW9uLm8pOiguZGF0YSsweDApOiBmaXJzdCBkZWZpbmVkIGhlcmUNClByaWNlcnMvLmxp
YnMvbGliUHJpY2Vycy5hKG1jcGFnb2RhLm8pOiguZGF0YSsweDApOiBtdWx0aXBsZSBkZWZpbml0
aW9uIG9mIGBfWk44UXVhbnRMaWI4TWNQcmljZXJJVF9UMF9FMTBtaW5TYW1wbGVfRScNClByaWNl
cnMvLmxpYnMvbGliUHJpY2Vycy5hKG1jY2xpcXVldG9wdGlvbi5vKTooLmRhdGErMHgwKTogZmly
c3QgZGVmaW5lZCBoZXJlDQpQcmljZXJzLy5saWJzL2xpYlByaWNlcnMuYShtY3BlcmZvcm1hbmNl
b3B0aW9uLm8pOiguZGF0YSsweDApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBfWk44UXVhbnRM
aWI4TWNQcmljZXJJVF9UMF9FMTBtaW5TYW1wbGVfRScNClByaWNlcnMvLmxpYnMvbGliUHJpY2Vy
cy5hKG1jY2xpcXVldG9wdGlvbi5vKTooLmRhdGErMHgwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpQ
cmljaW5nRW5naW5lcy8ubGlicy9saWJQcmljaW5nRW5naW5lcy5hKG1jX2Rpc2NyX2dlb21fYXZf
cHJpY2Uubyk6KC5kYXRhKzB4MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYF9aTjhRdWFudExp
YjEyTWNTaW11bGF0aW9uSVRfVDBfRTEwbWluU2FtcGxlX0UnDQpQcmljaW5nRW5naW5lcy8ubGli
cy9saWJQcmljaW5nRW5naW5lcy5hKG1jX2Rpc2NyX2FyaXRoX2F2X3ByaWNlLm8pOiguZGF0YSsw
eDApOiBmaXJzdCBkZWZpbmVkIGhlcmUNClByaWNpbmdFbmdpbmVzLy5saWJzL2xpYlByaWNpbmdF
bmdpbmVzLmEobWNiYXJyaWVyZW5naW5lLm8pOiguZGF0YSsweDApOiBtdWx0aXBsZSBkZWZpbml0
aW9uIG9mIGBfWk44UXVhbnRMaWIxMk1jU2ltdWxhdGlvbklUX1QwX0UxMG1pblNhbXBsZV9FJw0K
UHJpY2luZ0VuZ2luZXMvLmxpYnMvbGliUHJpY2luZ0VuZ2luZXMuYShtY19kaXNjcl9hcml0aF9h
dl9wcmljZS5vKTooLmRhdGErMHgwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpQcmljaW5nRW5naW5l
cy8ubGlicy9saWJQcmljaW5nRW5naW5lcy5hKG1jYmFza2V0ZW5naW5lLm8pOiguZGF0YSsweDAp
OiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBfWk44UXVhbnRMaWIxMk1jU2ltdWxhdGlvbklUX1Qw
X0UxMG1pblNhbXBsZV9FJw0KUHJpY2luZ0VuZ2luZXMvLmxpYnMvbGliUHJpY2luZ0VuZ2luZXMu
YShtY19kaXNjcl9hcml0aF9hdl9wcmljZS5vKTooLmRhdGErMHgwKTogZmlyc3QgZGVmaW5lZCBo
ZXJlDQpQcmljaW5nRW5naW5lcy8ubGlicy9saWJQcmljaW5nRW5naW5lcy5hKG1jaHVsbHdoaXRl
ZW5naW5lLm8pOiguZGF0YSsweDApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBfWk44UXVhbnRM
aWIxMk1jU2ltdWxhdGlvbklUX1QwX0UxMG1pblNhbXBsZV9FJw0KUHJpY2luZ0VuZ2luZXMvLmxp
YnMvbGliUHJpY2luZ0VuZ2luZXMuYShtY19kaXNjcl9hcml0aF9hdl9wcmljZS5vKTooLmRhdGEr
MHgwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpQcmljaW5nRW5naW5lcy8ubGlicy9saWJQcmljaW5n
RW5naW5lcy5hKG1jZGlnaXRhbGVuZ2luZS5vKTooLmRhdGErMHgwKTogbXVsdGlwbGUgZGVmaW5p
dGlvbiBvZiBgX1pOOFF1YW50TGliMTJNY1NpbXVsYXRpb25JVF9UMF9FMTBtaW5TYW1wbGVfRScN
ClByaWNpbmdFbmdpbmVzLy5saWJzL2xpYlByaWNpbmdFbmdpbmVzLmEobWNfZGlzY3JfYXJpdGhf
YXZfcHJpY2Uubyk6KC5kYXRhKzB4MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0KY29sbGVjdDI6IGxk
IHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCm1ha2VbNF06ICoqKiBbbGliUXVhbnRMaWIubGFdIEVy
cm9yIDENCm1ha2VbNF06IExlYXZpbmcgZGlyZWN0b3J5IGAvYnVpbGQvYnVpbGRkL3F1YW50bGli
LTAuMy4xMy9xbCcNCg0KDQpBbnkgaWRlYXMgd2h5IHRoaXMgd29ya3Mgb24gbmluZSBhcmNoaXRl
Y3R1cmUgYnV0IGZhaWxzIG9uIGhwcGEgPw0KDQpEaXJrDQoNCnwgVGhhbmtzLA0KfCAJTHVpZ2kN
CnwgDQp8IA0KfCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQp8IA0K
fCBUaGUgeW91bmcgbWFuIGtub3dzIHRoZSBydWxlcywgYnV0IHRoZSBvbGQgbWFuIGtub3dzIHRo
ZSBleGNlcHRpb25zLg0KfCAtLSBPLiBXLiBIb2xtZXMNCnwgDQp8IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
CnwgVGFrZSBTdXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0aGUgRnV0dXJlIG9mIElUDQp8
IEpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNheSBwYW5lbCBhbmQgeW91J2xsIGdldCB0aGUg
Y2hhbmNlIHRvIHNoYXJlIHlvdXINCnwgb3BpbmlvbnMgb24gSVQgJiBidXNpbmVzcyB0b3BpY3Mg
dGhyb3VnaCBicmllZiBzdXJ2ZXlzIC0tIGFuZCBlYXJuIGNhc2gNCnwgaHR0cDovL3d3dy50ZWNo
c2F5LmNvbS9kZWZhdWx0LnBocD9wYWdlPWpvaW4ucGhwJnA9c291cmNlZm9yZ2UmQ0lEPURFVkRF
Vg0KfCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KfCBR
dWFudExpYi1kZXYgbWFpbGluZyBsaXN0DQp8IFF1YW50TGliLWRldkBsaXN0cy5zb3VyY2Vmb3Jn
ZS5uZXQNCnwgaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVh
bnRsaWItZGV2DQoNCi0tIA0KSGVsbCwgdGhlcmUgYXJlIG5vIHJ1bGVzIGhlcmUgLSB3ZSdyZSB0
cnlpbmcgdG8gYWNjb21wbGlzaCBzb21ldGhpbmcuIA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBUaG9tYXMgQS4gRWRpc29u

Re: [Quantlib-dev] cvsgrab

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

On 07/25/2006 08:38:37 AM, Lars Schouw wrote:
> Does anyone know how I get the sources checked out from cvs using cvs
> grab?

I haven't tried cvsgrab, so I can't confirm it works. The WebCVS =20
interface is at <http://quantlib.cvs.sourceforge.net/quantlib/>. =20
However, you'll probably want to get a single module, e.g., =20
<http://quantlib.cvs.sourceforge.net/quantlib/QuantLib/>. You can try =20
passing the latter URL to cvsgrab and see what happens...


> Alternatively is there a tar ball for the nightly regression tests
> that I can download?

No, there's no nightly regression.

Later,
	Luigi



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

Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away.
-- Antoine de Saint-Exupery

Re: [Quantlib-dev] Candidate 0.3.13 tarballs

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

Hi all,
	I've updated the tarballs in <http://quantlib.org/prerelease/> =20
to include the last couple of fixes. I'll release them on Monday if =20
there's no further problems.

Later,
	Luigi


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

I have made this letter longer than usual, only because I have not had
the time to make it shorter.
-- B. Pascal

Re: [Quantlib-dev] [Quantlib-users] termstructure daycounter and put/call parity

[Ferdinando A. <na...@am...>]

Hi Roland

the bug it's been fixed on the CVS trunk. Please let me know if you still
have problem

ciao -- Nando


On 7/18/06, Roland Lichters <Rol...@we...> wrote:
>
>  Hello all,
>
> the QuantLib test-suite (capfloor.cpp) checks that the put/call parity
> (capNPV - floorNPV = swapNPV) holds. It seems to me that this test is passed
> successfully only as long as one chooses  term structure daycount
> Actual360(), see function setup() in capfloor.cpp.
>
> After setting this to e.g. ActualActual(ActualActual::ISDA) and keeping
> anything else unchanged, the test suite fails with the following messages ..
>
> Running 236 test cases...
> capfloor.cpp(283): fatal error in "CapFloorTest::testParity": put/call
> parity violated:
>     length:      1 years
>     volatility:  1.000000 %
>     strike:      3.000000 %
>     cap v alue:   2.01507
>     floor value: 0
>     swap value:  1.94683
>
> .. because the  cap price is overstated.
>
> I assume that the term structure daycounter should not have this effect on
> pricing results. Shouldn't it be arbitrary?
>
> Would you please have a quick look and correct me if I am wrong.
>
> I noticed this while building a small caplet volatility bootstrap tool
> that I'd like to contribute (eventually) if there is any interest.
>
> Many thanks for your efforts,
>
> Roland
>
>
>
>
>
>
>
>    Der WEB.DE <http://web.de/> SmartSurfer hilft bis zu 70% Ihrer
> Onlinekosten zu sparen!
> *http://smartsurfer.web.de/?mc=100071&distributionid=000000000071*<http://smartsurfer.web.de/?mc=100071&distributionid=000%0A+000000071>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
>

Re: [Quantlib-dev] Quantlib 0.3.13 PiecewiseYieldCurveTest Failures

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

On 07/27/2006 09:16:53 PM, Ram Meenakshisundaram wrote:
> Just compiled QuantLib 0.3.13 and had the following tests failed:

Fixed. Thanks for the heads-up.

Luigi


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

Don't say "yes" until I finish talking.
-- Darryl F. Zanuck

[Quantlib-dev] Quantlib 0.3.13 PiecewiseYieldCurveTest Failures

[Ram M. <RMe...@ol...>]

Just compiled QuantLib 0.3.13 and had the following tests failed:

Testing consistency of piecewise-log-linear discount curve...
unknown location(0): fatal error in =
"PiecewiseYieldCurveTest::testLogLinearDiscountConsistency": =
std::exception: two instruments have the same maturity (August 31st, =
2006)
Testing consistency of piecewise-linear discount curve...
unknown location(0): fatal error in =
"PiecewiseYieldCurveTest::testLinearDiscountConsistency": =
std::exception: two instruments have the same maturity (August 31st, =
2006)
Testing consistency of piecewise-log-linear zero-yield curve...
unknown location(0): fatal error in =
"PiecewiseYieldCurveTest::testLogLinearZeroConsistency": std::exception: =
two instruments have the same maturity (August 31st, 2006)
Testing consistency of piecewise-linear zero-yield curve...
unknown location(0): fatal error in =
"PiecewiseYieldCurveTest::testLinearZeroConsistency": std::exception: =
two instruments have the same maturity (August 31st, 2006)
Testing consistency of piecewise-spline zero-yield curve...
unknown location(0): fatal error in =
"PiecewiseYieldCurveTest::testSplineZeroConsistency": std::exception: =
two instruments have the same maturity (August 31st, 2006)
Testing consistency of piecewise-linear forward-rate curve...
unknown location(0): fatal error in =
"PiecewiseYieldCurveTest::testLinearForwardConsistency": std::exception: =
two instruments have the same maturity (August 31st, 2006)
Testing consistency of piecewise-flat forward-rate curve...
unknown location(0): fatal error in =
"PiecewiseYieldCurveTest::testFlatForwardConsistency": std::exception: =
two instruments have the same maturity (August 31st, 2006)
Testing observability of piecewise yield curve...
unknown location(0): fatal error in =
"PiecewiseYieldCurveTest::testObservability": std::exception: two =
instruments have the same maturity (August 31st, 2006)


Thanks,

Ram

[Quantlib-dev] Candidate 0.3.13 tarballs

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

Hi all,
	I've uploaded candidate tarballs for the 0.3.13 release into =20
<http://quantlib.org/prerelease/>. Please try to compile them and run =20
the test suite on your machines. If there's no showstoppers, I'll =20
release them in a few days (yes, Dirk, they're the final ones.)

Thanks,
	Luigi


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

The young man knows the rules, but the old man knows the exceptions.
-- O. W. Holmes

[Quantlib-dev] [ quantlib-Patches-1528321 ] Business/252 Day counter

[SourceForge.net <no...@so...>]

Patches item #1528321, was opened at 2006-07-25 08:18
Message generated for change (Settings changed) made by piterdias
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1528321&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
Submitted By: Piter Dias (piterdias)
>Assigned to: Ferdinando Ametrano (nando)
Summary: Business/252 Day counter

Initial Comment:
Those are files to implement Business/252 Daycounter,
as used in Brazil.
I included businessDaysBetween into Calendar class in
order to have how to calculate now many business days
there are between two dates (following a Calendar).
Brazil calendar class was rewritten in order to follow
QuantLib standard. I kept backward compatibility.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1528321&group_id=12740

[Quantlib-dev] [ quantlib-Patches-1528321 ] Business/252 Day counter

[SourceForge.net <no...@so...>]

Patches item #1528321, was opened at 2006-07-25 08:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1528321&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
Submitted By: Piter Dias (piterdias)
Assigned to: Nobody/Anonymous (nobody)
Summary: Business/252 Day counter

Initial Comment:
Those are files to implement Business/252 Daycounter,
as used in Brazil.
I included businessDaysBetween into Calendar class in
order to have how to calculate now many business days
there are between two dates (following a Calendar).
Brazil calendar class was rewritten in order to follow
QuantLib standard. I kept backward compatibility.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1528321&group_id=12740

[Quantlib-dev] cvsgrab

[Lars S. <sch...@ya...>]

Does anyone know how I get the sources checked out from cvs using cvs grab?

Alternatively is there a tar ball for the nightly regression tests that I can download?

Lars

 			
---------------------------------
See the all-new, redesigned Yahoo.com.  Check it out.

Re: [Quantlib-dev] SABR/CMS/Vol Interpolation...

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

However,

I believe I have found 2 other issues with the new CMS pricer.

1) The computation of the mDelta variable looks incorrect as line #284 
creates a leg from spot and the top (numer) expression of line #289 is thus 
huge. For a deal set in-arrears the numer formula should be zero and not 
("PaymentDate - SpotDate") which for a CMS rate starting in 5 years, 
Quarterly fixed resets would equal 5.25. Line #284 needs to pass the CMS 
swaps fixing date and not the YieldCurve's ReferenceDate.

2) Line #214 returns the size of the schedule object which is not the same 
as the number of periods within the underlying swap. One needs to reduce the 
calculation by one.

Also, I do know that this class is unfinished and thus untested, however I 
have an interest in this model as I previously integrated this model into a 
pricing application while I worked for Jerome Lebuchoux (Author of Models 
for CMS Caps - Euro Derivative, Risk 2000) and M Musiela (the M in the BGM 
model).

It's nice to see a clear C++ version of the algorithm.

Toy out...

>From: "Toyin Akin" <toy...@ho...>
>To: qua...@li...
>Subject: Re: [Quantlib-dev] SABR/CMS/Vol Interpolation...
>Date: Mon, 24 Jul 2006 15:45:08 +0100
>
>
>Hi,
>
>My observations concerning point 2) is invalid as I have now associated it
>with equ 2.12
>
>Toy out.
>
>
> >From: "Toyin Akin" <toy...@ho...>
> >To: qua...@li...
> >Subject: [Quantlib-dev] SABR/CMS/Vol Interpolation...
> >Date: Mon, 24 Jul 2006 11:17:33 +0100
> >
> >
> >Hi all,
> >
> >I have a few questions for you...
> >
> >1) Volatility interpolation...
> >
> >Let's assume that one has built a volatility smile based on linear
> >interpolation or a calibrated SABR curve and these volatilities are based
> >on
> >5Y A/MM underlying swap rates. Now some annoying dude comes along and 
>wants
> >to price a swaption based on 5Y S/BB swaps. However only 5Y A/MM vols are
> >quoted in the market. How does one go about adjusting the  5Y S/BB strike
> >rate to that of the 5Y A/MM strike so that an interpolation can be used? 
>Is
> >this enough? Does one need to modify the interpolated volatility also? Or
> >do
> >I tell the dude "we can't price it"!!! :-)
> >
> >2)
> >
> >Concerning the 'unfinished' CMS convexity adjustment class via 
>replication.
> >Looking at the code (line #235 of the conundrumpricer.cpp class.).
> >Shouldn't
> >this be x - forward (rather than x - strike)?
> >
> >3)
> >
> >Also based on the  'unfinished' CMS convexity adjustment class, I noticed
> >that the integration limit for CAPs is set to 1.0 (the strike value will
> >move from the given value all the way up to 1.0). If I am reading this
> >right
> >and one uses a SABR model with mid to high-ish wing values, you can imply
> >volatility values over 100% during the replication!! Is it enough to
> >instead
> >compute some percentage movement from the given strike (ie - 40%)? The 
>same
> >is true for the downward direction.
> >
> >That's all folks...
> >
> >Toy out...
> >
> >
> >
> >-------------------------------------------------------------------------
> >Take Surveys. Earn Cash. Influence the Future of IT
> >Join SourceForge.net's Techsay panel and you'll get the chance to share
> >your
> >opinions on IT & business topics through brief surveys -- and earn cash
> >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >_______________________________________________
> >QuantLib-dev mailing list
> >Qua...@li...
> >https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share 
>your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>QuantLib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] [Quantlib-users] termstructure daycounter and put/call parity

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

On 07/18/2006 01:55:44 PM, Roland Lichters wrote:
> the QuantLib test-suite (capfloor.cpp) checks that the put/call =20
> parity (capNPV - floorNPV =3D swapNPV) holds. It seems to me that this =20
> test is passed successfully only as long as one chooses term =20
> structure daycount Actual360(), see function setup() in capfloor.cpp.
>=20
> I assume that the term structure daycounter should not have this
> effect on pricing results. Shouldn't it be arbitrary?

Yes and no. For instance, the swap price changes---the coupons will =20
have the same fixings, but the discount factors will change due to the =20
different day-count convention. The change has a smaller effect on the =20
cap and floor (where fixing and discounting are not so neatly =20
separated) hence the failure. I've put a warning in the documentation =20
for the Black engine until we figure out what to fix.

Later,
	Luigi

P.S. Yes, the caplet-bootstrapping tool would be interesting.


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

Anyone who says he can see through women is missing a lot.
-- Groucho Marx

[Quantlib-dev] [ quantlib-Bugs-1527326 ] American Exercise Date Check is incorrect

[SourceForge.net <no...@so...>]

Bugs item #1527326, was opened at 2006-07-23 16:33
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1527326&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Luigi Ballabio (lballabio)
Summary: American Exercise Date Check is incorrect

Initial Comment:
In the class AmericanExercise in the constructor a 
check is placed that earliest is smaller than latest. 
This should be earliest<=latest, the text is 
correct "earliest>=latest exercise date.

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2006-07-24 16:57

Message:
Logged In: YES 
user_id=75450

The test depends on whether or not we allow earliest==latest
(in which case it's not really American, but we can see it
as a degenerate case.)

Anyway, I changed the check in CVS to allow equality.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1527326&group_id=12740

Re: [Quantlib-dev] SABR/CMS/Vol Interpolation...

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

Hi,

My observations concerning point 2) is invalid as I have now associated it 
with equ 2.12

Toy out.


>From: "Toyin Akin" <toy...@ho...>
>To: qua...@li...
>Subject: [Quantlib-dev] SABR/CMS/Vol Interpolation...
>Date: Mon, 24 Jul 2006 11:17:33 +0100
>
>
>Hi all,
>
>I have a few questions for you...
>
>1) Volatility interpolation...
>
>Let's assume that one has built a volatility smile based on linear
>interpolation or a calibrated SABR curve and these volatilities are based 
>on
>5Y A/MM underlying swap rates. Now some annoying dude comes along and wants
>to price a swaption based on 5Y S/BB swaps. However only 5Y A/MM vols are
>quoted in the market. How does one go about adjusting the  5Y S/BB strike
>rate to that of the 5Y A/MM strike so that an interpolation can be used? Is
>this enough? Does one need to modify the interpolated volatility also? Or 
>do
>I tell the dude "we can't price it"!!! :-)
>
>2)
>
>Concerning the 'unfinished' CMS convexity adjustment class via replication.
>Looking at the code (line #235 of the conundrumpricer.cpp class.). 
>Shouldn't
>this be x - forward (rather than x - strike)?
>
>3)
>
>Also based on the  'unfinished' CMS convexity adjustment class, I noticed
>that the integration limit for CAPs is set to 1.0 (the strike value will
>move from the given value all the way up to 1.0). If I am reading this 
>right
>and one uses a SABR model with mid to high-ish wing values, you can imply
>volatility values over 100% during the replication!! Is it enough to 
>instead
>compute some percentage movement from the given strike (ie - 40%)? The same
>is true for the downward direction.
>
>That's all folks...
>
>Toy out...
>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share 
>your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>QuantLib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] SABR/CMS/Vol Interpolation...

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

Hi all,

I have a few questions for you...

1) Volatility interpolation...

Let's assume that one has built a volatility smile based on linear 
interpolation or a calibrated SABR curve and these volatilities are based on 
5Y A/MM underlying swap rates. Now some annoying dude comes along and wants 
to price a swaption based on 5Y S/BB swaps. However only 5Y A/MM vols are 
quoted in the market. How does one go about adjusting the  5Y S/BB strike 
rate to that of the 5Y A/MM strike so that an interpolation can be used? Is 
this enough? Does one need to modify the interpolated volatility also? Or do 
I tell the dude "we can't price it"!!! :-)

2)

Concerning the 'unfinished' CMS convexity adjustment class via replication. 
Looking at the code (line #235 of the conundrumpricer.cpp class.). Shouldn't 
this be x - forward (rather than x - strike)?

3)

Also based on the  'unfinished' CMS convexity adjustment class, I noticed 
that the integration limit for CAPs is set to 1.0 (the strike value will 
move from the given value all the way up to 1.0). If I am reading this right 
and one uses a SABR model with mid to high-ish wing values, you can imply 
volatility values over 100% during the replication!! Is it enough to instead 
compute some percentage movement from the given strike (ie - 40%)? The same 
is true for the downward direction.

That's all folks...

Toy out...