quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Some noobie questions

[Takashi Y. <tak...@ho...>]

Hi All,

I recently came accross Quantlib and have a few questions (I couldnt find 
the answers in the "documentation):

1). Is there a "roll your own" cookbook that shows how to derive other 
instruments (from an existing base instrument class say?)

2). Equity derivatives, Futures and Commodities appear to be missing from 
the library - was this an oversight?
(i)- if yes, when are these instruments likely to be included ?
(ii). No plan is in place for these instruments, could someone then kindly 
suggest to me how I may go about using the existing library to build these 
instruments - i.e attempt to add these instruments to the library (similar 
to question 1).

3).  Concrete classes for calendars (one for each country) seems a bit 
unusual, why was this approach taking rather than having a generic calendar 
class with properties/methods that would determine which country the 
calendar was representing?

4). There are existing, complete libraries for Date/Time (e.g. wxWidget), 
why did you not build on these existing classes (i.e. why did  you decide to 
start from scratch)?


All i all, a very interesting project, to which I would like to contribute 
some code, once I have understood how everything "hangs" together - and the 
philosophy behind it ...

Look forward to your response.

Takashi

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Quantlib-dev] a simple question

[DU V. DE V. F. G. P. <fra...@ca...>]

>Is this the base class?=20
Yes=20

In this case, isValid_ should be protected and derived classes would =
have to manage it.=20

I agree with you, we could also leave it as it is and provide a =
protected function setQuote() which would set isValid_ to true.

>Using optional wouldn't be so tricky: we could just write SimpleQuote =
as >(without namespace boost)

I agree again, provided that you add a resetQuote() method to your =
class, then the use of optional would be transparent to the user. Still, =
I have two remaining arguments:=20
->You have to reimplement this machinery in every quote classe.
->What would be the added benefit compare to a more traditionnal =
solution ? (like mine)

I know that you will destroy these arguments in a couple of seconds, but =
it is instructive to understand one's error anyway

Fran=E7ois

[Quantlib-dev] Join Project

[Subhro N. <na...@gm...>]

Hello:

I apologize if this is not the right forum to ask this question. I was
reviewing the "To Do" lists in the Project Overview page. I would like to
contribute in some of the finite difference methods. Is there anybody/group
working on "Richardson Extrapolation". I could not find it on the Open Tasks
page. Whats the procedure to get started?

Thank you.

[Quantlib-dev] How to generate correlation multipath

[Apollo W. <aw...@gw...>]

Hi all,
 In version 0.3.4 I can use the
QuantLib::MonteCarlo::MultipathGenerator(&drifts, &covariance,
timelength, timestep, sggenerator) to do the job
 How do I do the same in version 0.4.0?  The interface seems to be
changed significantly.  The onlything I can find about covariance in the
documentation is for covariance(Time t0, const Array &x0, Time dt) which
only give V(xto+dt|xto)  for StochasticProcessArray, which is not what I
was looking for.=20
 Thanks.
 Sample code would be appricated.
Apollo
*************************************************************************=
*********************
This email is being sent to you for your information pursuant to your req=
uest. This information is not warranted=20
as to completeness or accuracy. The views expressed in the message are th=
ose of the individual sender,=20
except where the message states otherwise and the sender is authorized to=
 state them to be the views of=20
George Weiss Associates, Inc. or any of its affiliated entities. This mes=
sage is for the named person's use=20
only. It may contain sensitive and private proprietary or legally privile=
ged information. No confidentiality or=20
privilege is waived or lost by any mistransmission. You must not, directl=
y or indirectly, use, disclose, distribute,=20
print or copy any part of this message if you are not the intended recipi=
ent.
*** eSafe scanned this email for viruses, vandals, and malicious content.=
 ***
*************************************************************************=
*********************

[Quantlib-dev] 0.8.0 candidate tarballs

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

Hi all,
	I've uploaded candidate tarballs for the 0.8.0 release into
<http://quantlib.org/prerelease/>. Please download and test them if you
have some spare cycles. These are not the filan tarballs (I still need
to update a few readme-like files) but the code is not likely to change
unless problems are found.

Note: while it is possible to download them via http, it is painfully
slow. If you have a Sourceforge username, it's much faster to use scp;
the files can be retrieved from
<shell.sf.net://home/groups/q/qu/quantlib/htdocs/prerelease/>

Thanks,
	Luigi


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

There's no sense in being precise when you don't even know what you're 
talking about. 
-- John von Neumann 

Re: [Quantlib-dev] a simple question

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

On Fri, 2007-05-18 at 15:00 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> >As for QL_NULL_REAL, it doesn't really matter what value is used as long as >it's a determined one
> 
> Since it is now used as some kind of unitialized value by the quotes classes, I would say that it is no longer such an immaterial detail.

Sure. We picked a value which is unlikely to be chosen as a valid one;
but since it has to be a value anyway (we could use NaN, but it's not
very portable) it's not foolproof.

> Maybe you have thought about boost::optional for the same reason. ;-) 
> It would be cleaner indeed. However I'm not convinced that it's a good solution yet.
> IMO boost::optional a pefect solution in the case of a free function which can return invalid result even in normal situations. (like the second example of boost optional tutorial).
> 
> On the hand it seems to me that using it for a function member would add some spurious trickyness to the class. What do you think of this implementation ? 
> 
> 	Quote():isValid_(false){}
> 
> 	virtual void resetQuote() {
> 	    isValid_ = false;
> 	}
> 
> 	virtual bool isValid() const {
> 	    return isValid_;
> 	};
> 	private:
> 	bool isValid_;

Is this the base class? In this case, isValid_ should be protected and
derived classes would have to manage it. Using optional wouldn't be so
tricky: we could just write SimpleQuote as (without namespace boost)

class SimpleQuote {
  private:
    optional<Real> value_;
  public:
    explicit SimpleQuote(optional<Real> value = none)
    : value_(value) {}

    bool isValid() const {
        return value_;  // automatic conversion to bool
    }

    Real value() const {
        return *value_; // access the actual Real
    }

    Real setValue(Real x) {
        value_ = x;     automatic conversion to optional
        ... // notify etc.
    }
};

SimpleQuote q1;       // not initialized, isValid() returns false
SimpleQuote q2(42.0); // double automatically converted to optional

Later,
	Luigi




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

The First Rule of Optimization: Don't do it. 
The Second Rule of Optimization (For experts only): Don't do it yet. 
-- Michael Jackson 

Re: [Quantlib-dev] a simple question

[DU V. DE V. F. G. P. <fra...@ca...>]

>As for QL_NULL_REAL, it doesn't really matter what value is used as =
long as >it's a determined one

Since it is now used as some kind of unitialized value by the quotes =
classes, I would say that it is no longer such an immaterial detail. For =
example if we can encounter the following problem:

	SimpleQuote quote;
	Real value =3D (std::numeric_limits<float>::max)(); //limit case test
	Quote.setValue(value);
	//a few lines of code later ... bug !!!!

>Speaking of which, funny that you came out with a question on Null. =
Just
>yesterday I was thinking of removing it and using boost::optional when =
a
>number might or might not be defined. What do you think?

Maybe you have thought about boost::optional for the same reason. ;-)=20
It would be cleaner indeed. However I'm not convinced that it's a good =
solution yet.
IMO boost::optional a pefect solution in the case of a free function =
which can return invalid result even in normal situations. (like the =
second example of boost optional tutorial).

On the hand it seems to me that using it for a function member would add =
some spurious trickyness to the class. What do you think of this =
implementation ?=20

	Quote():isValid_(false){}

	virtual void resetQuote() {
	    isValid_ =3D false;
	}

	virtual bool isValid() const {
	    return isValid_;
	};
	private:
	bool isValid_;


regards,

Fran=E7ois

Re: [Quantlib-dev] a simple question

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

On Fri, 2007-05-18 at 10:08 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> Is there any reason why QL_NULL_REAL  is defined this way : 
> 
> #define QL_NULL_REAL   ((std::numeric_limits<float>::max)())
> 
> whereas QL_MIN_REAL and QL_MAX_REAL  are defined this way :
> 
> #define QL_MAX_REAL   ((std::numeric_limits<QL_REAL>::max)())


In theory, QL_REAL might be redefined to float or long double (in
practice it is not, as some tests break.) QL_MIN_REAL and QL_MAX_REAL
should be the min and max value for the actual type chosen, so
numeric_limits<QL_REAL> is used. As for QL_NULL_REAL, it doesn't really
matter what value is used as long as it's a determined one, so there's
no need to use the actual QL_REAL type; also, we define Null<float>,
Null<double> and Null<long double> to be all equal to QL_NULL_REAL,
which is somewhat convenient (this way, Null<T> is the same number, no
matter the actual type) and using float ensured that the resulting
number could be contained in all such types without overflow.

Speaking of which, funny that you came out with a question on Null. Just
yesterday I was thinking of removing it and using boost::optional when a
number might or might not be defined. What do you think?

Later,
	Luigi


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

Lubarsky's Law of Cybernetic Entomology: 
There is _always_ one more bug. 

[Quantlib-dev] a simple question

[DU V. DE V. F. G. P. <fra...@ca...>]

Is there any reason why QL_NULL_REAL  is defined this way :=20

=20

#define QL_NULL_REAL   ((std::numeric_limits<float>::max)())

=20

whereas QL_MIN_REAL =
<mk:@MSITStore:C:\Documents%20and%20Settings\duvigf1a\My%20Documents\_my%=
20Stuffs\QuantLib-docs-ql_svn.chm::/group__limit_macros.html#g8a6736b7bfe=
f354a1fc507317d49117a>  and QL_MAX_REAL  are defined this way :

=20

#define=20

QL_MIN_REAL =
<mk:@MSITStore:C:\Documents%20and%20Settings\duvigf1a\My%20Documents\_my%=
20Stuffs\QuantLib-docs-ql_svn.chm::/group__limit_macros.html#g8a6736b7bfe=
f354a1fc507317d49117a>    -((std::numeric_limits<QL_REAL =
<mk:@MSITStore:C:\Documents%20and%20Settings\duvigf1a\My%20Documents\_my%=
20Stuffs\QuantLib-docs-ql_svn.chm::/class_q_l___r_e_a_l.html> >::max)())

#define QL_MAX_REAL   ((std::numeric_limits<QL_REAL>::max)())

=20

Fran=E7ois

Re: [Quantlib-dev] Plans for future releases and call for contributions

[Xiaoming L. <lx...@th...>]

THVpZ2kgJiBhbGwsDQoNCkkga25vdyBpdCBpcyBhIGxhdGUgcmVwbHkuDQpCdXQgdG9kYXkgd2hl
biBJIGdvdCB0aW1lIHRvIHJldmlldyB0aGUgaGlzdG9yaWNhbCBlbWFpbHMsIEkgdGhpbmsgdGhh
dCBpdCBpcyBhIHRpbWUgZm9yIG1lIHRvIGNvbnRyaWJ1dGUgc29tZXRoaW5nIGJhY2sgdG8gdGhl
IHByb2plY3QuDQoNCkkgaGFkIGtlcHQgYW4gZXllIG9uIHRoaXMgcHJvamVjdCBmb3IgbW9yZSB0
aGFuIHRocmVlIHllYXJzLCBJIHJlYWxseSBsZWFybmVkIGEgbG90IGZyb20gYWxsIHBlb3BsZSBh
bmQgcHJvamVjdCBpdHNlbGYuIA0KDQpJIHdpbGwgd29yayB0aGUgbW9ydGdhZ2UgcHJpY2luZyBh
cyB0aGUgc3RhcnQuDQoNClRoYW5rcywNClhpYW9taW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh
Z2UgLS0tLS0gDQpGcm9tOiAiTHVpZ2kgQmFsbGFiaW8iIDxsdWlnaS5iYWxsYWJpb0BnbWFpbC5j
b20+DQpUbzogIlF1YW50TGliIGRldmVsb3BlcnMiIDxxdWFudGxpYi1kZXZAbGlzdHMuc291cmNl
Zm9yZ2UubmV0Pg0KU2VudDogRnJpZGF5LCBNYXJjaCAxNiwgMjAwNyAxMDoyNyBQTQ0KU3ViamVj
dDogW1F1YW50bGliLWRldl0gUGxhbnMgZm9yIGZ1dHVyZSByZWxlYXNlcyBhbmQgY2FsbCBmb3Ig
Y29udHJpYnV0aW9ucw0KDQoNCj4gDQo+IEhpIGFsbCwNCj4gICAgZmlyc3Qgb2YgYWxsLCBJJ2Qg
bGlrZSB0byBzYXkgdGhhbmtzIHRvIGV2ZXJ5Ym9keSB3aG8gaGVscGVkIHVzDQo+IHJlbGVhc2lu
ZyBRdWFudExpYiAwLjQuMCAoYXMgd2VsbCBhcyBhbGwgcHJldmlvdXMgcmVsZWFzZXMpIGJ5DQo+
IGNvbnRyaWJ1dGluZyBjb2RlLCBidWcgcmVwb3J0cywgY29tbWVudHMtLS15b3UgbmFtZSBpdC4g
SXQncyBiZWVuIGENCj4gZ3JlYXQgc2l4IHllYXJzLg0KPiANCj4gVGhpcyB5ZWFyLCB3ZSdyZSBw
bGFubmluZyB0byBmaW5hbGx5IHRha2UgdGhlIG5leHQgc3RlcCBhbmQgcmVsZWFzZQ0KPiBRdWFu
dExpYiAxLjAuICBJJ2xsIGRyYWZ0IGEgcGxhbiBhbmQgYXNrIGZvciBzcGVjaWZpYyBjb250cmli
dXRpb25zDQo+IGxhdGVyIGluIHRoaXMgcG9zdDsgYnV0IGJlZm9yZSB0aGF0LCBwbGVhc2UgbGV0
IG1lIHNoYXJlIGEgZmV3IHRob3VnaHRzLg0KPiANCj4gTGF0ZWx5IEkgc3RhcnRlZCB0byBoYXZl
IHRoZSBmZWVsaW5nIHRoYXQgb3VyIGRldmVsb3BtZW50IG1vZGVsIGhhcw0KPiByZWFjaGVkIGl0
cyBsaW1pdC4gVW50aWwgbm93LCBkZXZlbG9wbWVudCBvZiB0aGUgbGlicmFyeSBoYXMgYmVlbiBw
dXNoZWQNCj4gZm9yd2FyZHMgYnkgYSBmZXcgZGVkaWNhdGVkIGluZGl2aWR1YWxzIGFuZCBieSBv
Y2Nhc2lvbmFsIGNvbnRyaWJ1dGlvbnMNCj4gYnkgb3RoZXIgcGVvcGxlLiBIb3dldmVyLCB0aGVy
ZSdzIG9ubHkgc28gbXVjaCB0aGF0IHRoaXMgY2FuIGFjaGlldmU7IGFzDQo+IHdpdG5lc3NlZCwg
dG8gbmFtZSBhIGNvdXBsZSBvZiBleGFtcGxlcywgYnkgdGhlIGxhY2sgb2YgdXNlcg0KPiBkb2N1
bWVudGF0aW9uIGFuZCBteSBzeXN0ZW1hdGljIGRlbGF5IGluIGFuc3dlcmluZyBwb3N0cyB0byB0
aGUgbWFpbGluZw0KPiBsaXN0cy4NCj4gDQo+IEluIHNob3J0LCB3ZSBuZWVkIHRvIGZvc3RlciBh
IGNvbW11bml0eS4gV2UgZGlkbid0IGdpdmUgbXVjaCBlZmZvcnQgdG8NCj4gdGhpcyBzbyBmYXI7
IGFjdHVhbGx5LCBJJ20gYWZyYWlkIHdlICh0aGUgY29yZSBkZXZlbG9wZXJzKSBtaWdodCBoYXZl
DQo+IHNjYXJlZCBwb3RlbnRpYWwgY29udHJpYnV0b3JzIGF3YXkuIFVudGlsIG5vdywgd2UgaGF2
ZSBoYWQgYSBzb21ld2hhdA0KPiBjYXZhbGllciBhdHRpdHVkZS0tLXdoZW4gd2Ugd2FudGVkIHRv
IGRvIHNvbWV0aGluZywgd2UganVzdCBvcGVuZWQgb3VyDQo+IGVkaXRvcnMgYW5kIElERXMgYW5k
IHN0YXJ0ZWQgaGFja2luZy4gKE1lPyBHdWlsdHkgYXMgY2hhcmdlZC4pDQo+IFVuZm9ydHVuYXRl
bHksIHRoaXMgbWlnaHQgZ2l2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoZSBsaWJyYXJ5IGlzIG91
cg0KPiBwbGF5Z3JvdW5kIGFuZCBkaXNjb3VyYWdlIHBlb3BsZSBmcm9tIGVudGVyaW5nIG91ciBz
dXBwb3NlZGx5IGNsb3NlZA0KPiBjbHViLg0KPiANCj4gVGhpcyB3aWxsIGhhdmUgdG8gY2hhbmdl
LiBJJ2xsIHRyeSBhbmQgYm91bmNlIGlkZWFzIG9uIHRoZSBkZXZlbG9wZXINCj4gbWFpbGluZyBs
aXN0IGJlZm9yZSBhbnkgbWFqb3IgY2hhbmdlLiBPZiBjb3Vyc2UsIEkgYWxzbyBlbmNvdXJhZ2Ug
dGhlDQo+IG90aGVyIGRldmVsb3BlcnMgdG8gZG8gdGhlIHNhbWUtLS1rdWRvcyB0byB0aG9zZSB0
aGF0IGFscmVhZHkgZG8uIEluDQo+IHNob3J0LCBJJ2xsIGRvIG15IGJlc3Qgc28gdGhhdCB0aGUg
bGlicmFyeSBpcyBvd25lZCAoYW5kIGZlbHQgYXMgc3VjaCkNCj4gYnkgdGhlIHdob2xlIGNvbW11
bml0eSBncmF2aXRhdGluZyBhcm91bmQgdGhlIG1haWxpbmcgbGlzdHMuDQo+IA0KPiBFbm91Z2gt
LS1hbmQgb253YXJkcyB0byB0aGUgcGxhbiBmb3IgcmVsZWFzZSAxLjAuDQo+IA0KPiBNeSBpZGVh
IChvcGVuIHRvIGRpc2N1c3Npb24sIG9mIGNvdXJzZSkgd2FzIHRvIGdldCB0byAxLjAgaW4gdHdv
IG9yDQo+IHRocmVlIHJlbGVhc2VzLiBUaGUgb25lcyBiZWZvcmUgMS4wIHdpbGwgZ2l2ZSB1cyBh
IGNoYW5jZSB0byBtYWtlDQo+IGNoYW5nZXMgd2UndmUgaW50ZW5kZWQgdG8gZG8gZm9yIHF1aXRl
IGEgd2hpbGUsIGJ1dCB0aGF0IGNvdWxkIG5vdCBiZQ0KPiBkb25lIGVhc2lseSBpbiBhIGJhY2t3
YXJkLWNvbXBhdGlibGUgd2F5LiBTb21lIG9mIHRoZW0gd2VyZSBtYWRlDQo+IGFscmVhZHkuDQo+
IA0KPiBUaGUgbmV4dCBzdGVwIHdvdWxkIGJlIFF1YW50TGliIDEuMC4gSW4gZmFjdCwgdGhlIHJl
bGVhc2UgYmVmb3JlIHRoYXQNCj4gb25lICgwLjkuMD8pIHdvdWxkIGFsbW9zdCBiZSBhIGJldGEg
cmVsZWFzZSBvZiAxLjAuIEkgd291bGRuJ3QgY2hhbmdlDQo+IG11Y2ggYmV0d2VlbiB0aGUgdHdv
OyBpbnN0ZWFkLCBJIHdvdWxkIGZvY3VzIG9uIGltcHJvdmluZyBkb2N1bWVudGF0aW9uDQo+IGFu
ZCBnZW5lcmFsIHVzYWJpbGl0eSAoYSB0YXNrIHdoaWNoIHNob3VsZCBhbHJlYWR5IHN0YXJ0IGZv
ciB0aGUNCj4gdXBjb21pbmcgcmVsZWFzZXMuKQ0KPiANCj4gTmVlZGxlc3MgdG8gc2F5LCBhbGwg
c3VjaCByZWxlYXNlcyAoYXMgd2VsbCBhcyBmdXR1cmUgb25lcykgd2lsbCBuZWVkDQo+IHlvdXIg
Y29udHJpYnV0aW9uLiBZb3UgZG9uJ3QgbmVlZCB0byBkbyBhbnl0aGluZyBleGNlcHRpb25hbDsg
ZWFjaCBvZg0KPiB5b3UgY2FuIGhlbHAgYnkgZ2l2aW5nIGFzIGxpdHRsZSB0aW1lIGFuZCBlZmZv
cnQgeW91IGNhbiBhZmZvcmQgb3Igd2FudA0KPiB0byBzcGFyZS4NCj4gDQo+IFRoZSBlYXNpZXN0
IHdheSB0byBjb250cmlidXRlIHdvdWxkIGJlIHRvIHN1YnNjcmliZSB0byB0aGUgUXVhbnRMaWIt
ZGV2DQo+IG1haWxpbmcgbGlzdCAodGhlIHN1YnNjcmlwdGlvbiBwYWdlIGNhbiBiZSBmb3VuZCBh
dA0KPiA8aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVhbnRs
aWItZGV2Pi4pIEFzIEkgc2FpZCwNCj4gd2UnbGwgdHJ5IGFuZCBkaXNjdXNzIGZ1dHVyZSBkZXZl
bG9wbWVudHMgdGhlcmUuIFlvdXIgY29udHJpYnV0aW9uIHRvDQo+IHRoZSBkaXNjdXNzaW9ucywg
ZXZlbiBpZiBvbmx5IGFuIG9jY2FzaW9uYWwgb25lLCB3aWxsIGJlIHVzZWZ1bC4NCj4gDQo+IElm
IHlvdSB0aGluayB5b3UgY2FuIGdldCBtb3JlIGludm9sdmVkLCB0aGVyZSdzIGEgbnVtYmVyIG9m
IG90aGVyIHRoaW5ncw0KPiB5b3UgY2FuIGRvIC0gYXBhcnQgZnJvbSBjb250cmlidXRpbmcgY29k
ZSBvciBwYXRjaGVzIHRvIHRoZSBsaWJyYXJ5LCBvZg0KPiBjb3Vyc2UuIEEgZmV3IG9mIHRoZW0g
YXJlOg0KPiANCj4gLSBhbnN3ZXIgcXVlc3Rpb25zIG9uIHRoZSBRdWFudExpYi11c2VycyBtYWls
aW5nIGxpc3Q7DQo+IA0KPiAtIHN1YnNjcmliZSB0byB0aGUgUXVhbnRMaWItY3ZzIG1haWxpbmcg
bGlzdCBhbmQgcmV2aWV3IHRoZSBjaGFuZ2VzDQo+ICBjb21taXR0ZWQgdG8gdGhlIHJlcG9zaXRv
cnkuIFlvdSBtaWdodCBhc2sgcXVlc3Rpb25zIGFib3V0IHRoZQ0KPiAgY2hhbmdlLCBtYWtlIGZ1
cnRoZXIgc3VnZ2VzdGlvbnMsIG9yIHJlcG9ydCBhIGJ1ZyB5b3Ugc3BvdHRlZC4gSSdsbA0KPiAg
dHJ5IGFuZCBzZXR1cCB0aGUgbWFpbGluZyBsaXN0IHNvIHRoYXQgcmVwbGllcyB0byBwb3N0cyBn
byB0bw0KPiAgUXVhbnRMaWItZGV2Lg0KPiANCj4gLSBwcm92aWRlIGV4YW1wbGVzLiBUaG9zZSBh
cmUgZWFzaWVyIHRvIHdyaXRlIHRoYW4gbmV3IHBhcnRzIG9mIHRoZQ0KPiAgbGlicmFyeSwgYW5k
IGFyZSBpbW1lbnNlbHkgdXNlZnVsIHRvIG5ldyB1c2VycyBhcyB0aGV5IGNhbiBhY3QgYXMNCj4g
IGRvY3VtZW50YXRpb24gb2YgbGlicmFyeSBmZWF0dXJlcyBhbmQgdGhlaXIgdXNhZ2UuIElmIHlv
dSBkb24ndCBoYXZlDQo+ICB0aGUgdGltZSB0byBwcm92aWRlIGV4YW1wbGVzLCB5b3UgY2FuIHN0
aWxsIGNvbnRyaWJ1dGUgYnkgd3JpdGluZyB0bw0KPiAgUXVhbnRMaWItZGV2IGFuZCBwcm9wb3Np
bmcgZXhhbXBsZXMgdG8gYmUgd3JpdHRlbiBieSB3aG9ldmVyIGFjY2VwdHMNCj4gIHRoZSB0YXNr
Lg0KPiANCj4gLSBXZSBtaWdodCBwdXQgc29tZSBraW5kIG9mIGNvb2tib29rIG9uIHRoZSB3aWtp
ICh3ZSdsbCBoYXZlIHRvDQo+ICBkaXNjdXNzIHRoZSBpZGVhIG9uIHRoZSBsaXN0LikgSW4gdGhp
cyBjYXNlLCB5b3UgbWlnaHQgcHJvdmlkZSBjb2RlDQo+ICBzbmlwcGV0cyBleGVtcGxpZnlpbmcg
aG93IHRvIHBlcmZvcm0gc2ltcGxlIChvciBsZXNzIHNpbXBsZSkNCj4gIHRhc2tzLiBUaGlzIHdv
dWxkIHJlcXVpcmUgbGVzcyBlZmZvcnQgdGhhbiBmdWxsLWZsZWRnZWQgZXhhbXBsZXMuDQo+IA0K
PiBBbGwgb2YgdGhlIGFib3ZlIGFyZSB3YXlzIHRvIGNvbnRyaWJ1dGUuIEV2ZW4gaWYgY29udHJp
YnV0aW9ucyB3ZXJlDQo+IGxpdHRsZSwgdGhlaXIgY3VtdWxhdGl2ZSBlZmZlY3Qgd291bGQgYmUg
YSBncmVhdCBoZWxwIHRvIGltcHJvdmUgdGhlDQo+IGxpYnJhcnkuIE1vcmVvdmVyLCBlYWNoIG9m
IHRoZSBhYm92ZSBhcmUgYWxzbyB3YXlzIHRvIGZhbWlsaWFyaXplIHdpdGgNCj4gdGhlIGxpYnJh
cnkgYW5kIGluIHRpbWUgdG8gYmVjb21lIGFibGUgdG8gd29yayBvbiBpdHMgaW50ZXJuYWxzLg0K
PiANCj4gVGhhbmtzIGZvciBsaXN0ZW5pbmcuIENvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPiANCj4g
TGF0ZXIsDQo+ICAgICAgICBMdWlnaQ0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0gDQo+IA0KPiBmaXgsIG4uLHYuIA0KPiBXaGF0IG9uZSBkb2VzIHdo
ZW4gYSBwcm9ibGVtIGhhcyBiZWVuIHJlcG9ydGVkIHRvbyBtYW55IHRpbWVzIA0KPiB0byBiZSBp
Z25vcmVkLiANCj4gLS0gdGhlIEphcmdvbiBmaWxlIA0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+IFRha2UgU3VydmV5cy4gRWFybiBDYXNoLiBJbmZsdWVuY2UgdGhlIEZ1dHVyZSBv
ZiBJVA0KPiBKb2luIFNvdXJjZUZvcmdlLm5ldCdzIFRlY2hzYXkgcGFuZWwgYW5kIHlvdSdsbCBn
ZXQgdGhlIGNoYW5jZSB0byBzaGFyZSB5b3VyDQo+IG9waW5pb25zIG9uIElUICYgYnVzaW5lc3Mg
dG9waWNzIHRocm91Z2ggYnJpZWYgc3VydmV5cy1hbmQgZWFybiBjYXNoDQo+IGh0dHA6Ly93d3cu
dGVjaHNheS5jb20vZGVmYXVsdC5waHA/cGFnZT1qb2luLnBocCZwPXNvdXJjZWZvcmdlJkNJRD1E
RVZERVYNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gUXVhbnRMaWItZGV2IG1haWxpbmcgbGlzdA0KPiBRdWFudExpYi1kZXZAbGlzdHMuc291cmNl
Zm9yZ2UubmV0DQo+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZv
L3F1YW50bGliLWRldg==

[Quantlib-dev] quadratic stuff

[Mark j. <mar...@gm...>]

OK I'm not a big expert on terminology.

I have x \in R^n, I have three polynomials p q r ,
p(x) = ||x||^2
q(x) = C \sum \limits_{j=1}^{n-1} x_{j}^{2} plus lower order terms

r(x) = \sum (x_j - y_j)^2  for a vector y

i want to minimize r(x) on the set p(x) = a, q(x) =b.

I reckon this shouldn't be too hard, but would rather not work out how
to do it from scratch if there's some well-known technique.

Mark

[Quantlib-dev] quadratic programming

[<fre...@gm...>]

Hello Mark,

I am not sure to have understood well your question. Do you talk about
sequential quadratic programming (SQP) or just 'how to solve' a quadratic
problem?

Do your problem have this form: Minimize f(x): { x in X, g(x) <=3D 0, h(x) =
<=3D
0 }? so SQP would be suitable to solve your problem. The known method is
with lagrangian multipliers. Anyway, I dont know any open source libraries
which have it.

Regards
Fr=E9d=E9ric Degraeve

-----Original Message-----
From: qua...@li... [mailto:
qua...@li...] On Behalf Of Mark joshi
Sent: lundi 7 mai 2007 02:10
To: qua...@li...
Subject: [Quantlib-dev] quadratic programming



Dear All,



I have an idea how to reduce the LMM calibration to a quadratic

programming question.

So



1) is there any quadratic programming in quantlib already?

2) does anyone know anything about it?

3) does anyone have any views on how it ought to be done?



The problem is pretty simple: solve a couple of quadratics in

n-variables, whilst minimizing a third.





best



mark





--=20

Assoc Prof Mark Joshi

Centre for Actuarial Studies

University of Melbourne

My website is www.markjoshi.com



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

This SF.net email is sponsored by DB2 Express

Download DB2 Express C - the FREE version of DB2 express and take

control of your XML. No limits. Just data. Click to get it now.

http://sourceforge.net/powerbar/db2/

_______________________________________________

QuantLib-dev mailing list

Qua...@li...

https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10623]trunk/QuantLib

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

On Mon, 2007-05-07 at 19:31 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> It should be reviewed by Ferdinando because I'm not sure that the results are satisfactory, and also because it is not integrated in the pseusodsqrt function yet. When is the 0.8.0 release to be packaged ? 

I'll try and release 0.8.0 this month.
Don't hurry though, it's not a problem if it doesn't make this release.
We still have another release before 1.0, so take your time.

Later,
	Luigi


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

Green's Law of Debate: 
Anything is possible if you don't know what you're talking about. 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10623]trunk/QuantLib

[DU V. DE V. F. G. P. <fra...@ca...>]

It should be reviewed by Ferdinando because I'm not sure that the =
results are satisfactory, and also because it is not integrated in the =
pseusodsqrt function yet. When is the 0.8.0 release to be packaged ?=20
Fran=E7ois


-----Original Message-----
From: qua...@li... =
[mailto:qua...@li...] On Behalf Of Luigi =
Ballabio
Sent: Monday, May 07, 2007 6:21 PM
To: qua...@li...
Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: =
[10623]trunk/QuantLib

On Mon, 2007-05-07 at 09:10 -0700, fd...@us... wrote:
> Revision: 10623
>           =
http://quantlib.svn.sourceforge.net/quantlib/?rev=3D10623&view=3Drev
> Author:   fdv1
> Date:     2007-05-07 09:10:52 -0700 (Mon, 07 May 2007)
>=20
> Log Message:
> -----------
> triangularAnglesParametrization ready to be reviewed

Does this mean it wasn't ready before? Should I exclude it from the
0.8.0 release?

Later,
	Luigi


----------------------------------------=20

Though this be madness, yet there is method in't.=20
-- Hamlet, Act II, scene II=20



-------------------------------------------------------------------------=

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10623] trunk/QuantLib

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

On Mon, 2007-05-07 at 09:10 -0700, fd...@us... wrote:
> Revision: 10623
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10623&view=rev
> Author:   fdv1
> Date:     2007-05-07 09:10:52 -0700 (Mon, 07 May 2007)
> 
> Log Message:
> -----------
> triangularAnglesParametrization ready to be reviewed

Does this mean it wasn't ready before? Should I exclude it from the
0.8.0 release?

Later,
	Luigi


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

Though this be madness, yet there is method in't. 
-- Hamlet, Act II, scene II 

Re: [Quantlib-dev] quadratic programming

[Alan K. <kin...@gm...>]

It may be too heavy-weight for your application, but there is a high-quality
open-source optimization project at http://www.coin-or.org/.  Mark's email
suggests quadratic constraints are required.  If this is the case, then
probably you would need the IPOPT package.  Check it out and if its unclear
and you want to know more I'd be happy to make the introductions.

Alan

Re: [Quantlib-dev] quadratic programming

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

On Mon, 2007-05-07 at 10:07 +1000, Mark joshi wrote:
> 1) is there any quadratic programming in quantlib already?
> 2) does anyone know anything about it?
> 3) does anyone have any views on how it ought to be done?

I can answer the first one: no, there isn't.

Later,
	Luigi


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

Green's Law of Debate: 
Anything is possible if you don't know what you're talking about. 

[Quantlib-dev] quadratic programming

[Mark j. <mar...@gm...>]

Dear All,

I have an idea how to reduce the LMM calibration to a quadratic
programming question.
So

1) is there any quadratic programming in quantlib already?
2) does anyone know anything about it?
3) does anyone have any views on how it ought to be done?

The problem is pretty simple: solve a couple of quadratics in
n-variables, whilst minimizing a third.


best

mark


-- 
Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

[Quantlib-dev] quadratic programming

[Mark j. <mar...@gm...>]

Dear All,

I have an idea how to reduce the LMM calibration to a quadratic
programming question.
So

1) is there any quadratic programming in quantlib already?
2) does anyone know anything about it?
3) does anyone have any views on how it ought to be done?

The problem is pretty simple: solve a couple of quadratics in
n-variables, whilst minimizing a third.


best

mark


-- 
Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

[Quantlib-dev] QuantLib 0.8.0 release branch

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

Hi all,
	I just created a release branch for next version, namely, QuantLib
0.8.0; you can retrieve it from Subversion with

svn checkout https://quantlib.svn.sourceforge.net/svnroot/quantlib/branches/R000800-branch

As usual, bug fixes should now go on the branch; new developments must
be made on the trunk.

Later,
	Luigi


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

It is always the best policy to tell the truth, unless, of course, 
you are an exceptionally good liar. 
-- Jerome K. Jerome 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10531] trunk/QuantLib

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

On 5/3/07, Luigi Ballabio <lui...@gm...> wrote:
> On Wed, 2007-05-02 at 10:05 -0700, chi...@us... wrote:
> > Revision: 10531
> >           http://quantlib.svn.sourceforge.net/quantlib/?rev=10531&view=rev
> > Author:   chiforna
> > Date:     2007-05-02 10:05:09 -0700 (Wed, 02 May 2007)
> >
> > Log Message:
> > -----------
> > - provided WeeklyTenorLibor and MonthlyTenorLibor (which should/will be used instead of Libor)
>
> We don't need classes for that, do we? We can just check the units of
> the passed period and set the conventions accordingly. Do you mind if I
> go ahead and make the change?

yes, you're right. go ahead. thank you

ciao -- Nando

[Quantlib-dev] QuantLibXL.xla digital signature

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

On 5/3/07, Luigi Ballabio <lui...@gm...> wrote:
> > Log Message:
> > -----------
> > digital signature added back
>
> I see a lot of these messages lately. How manual is the generation of
> the signature? It seems like something that could be added as a
> post-build action...

there's not that much we could do as far as I know. I summarize my
best understanding below, hoping somebody here has some clever
suggestion

QuantLib.xla is not built in any way, so a post-build action is not
appropriate. Besides the xla can only be signed on my workstation
(more on this later).

Let's look at Excel:
1) Excel has different macro security levels (Tools | Macro |
Security). "Low" is not recommended as it means no protection at all.
"Medium" allows the user to choose whether or not to run "potentially
unsafe" macros: when loading macros it pops up a message box asking
the user if he trust the macros. "High" only trusts signed macros
2) as most developers/beta_users select "medium" security level it's
annoying that every time they load QuantLib.xla Excel asks them if
they trust the macros. here is where digital signature comes into
play: if QuantLib.xla is signed and they trust its (public key)
certificate the question is asked only once and no more
3) if developers/beta_users select "high" security level having a
signed xla is simply mandatory

We have signed QuantLib.xla with a self-certificate, that is a
certificate whose private key cannot be exported and shared, but it
just lives on the workstation where it has been created. If any
developer modifies the xla the signature is lost, and can only be
added back from the original workstation, i.e. currently by me.
Even if in this way we haven't solved any security issue at all, at
least developers/beta_users who trust the (public key) certificate
have a way to avoid the annoying pop up in "medium" security level or
to use QuantLib.xla in "high" security level. Should I lose access to
my current workstation any developer could just issue another
self-certificate, sign the xla, and developers/beta_users will have to
trust this new (public key) certificate

Buying a true digital certificate would not make things really better
for developers/beta_users, as we would face similar problems: whenever
a developer without the private key alters the xla the signature is
lost. Sharing the private key between all developers would actually
invalidate the level of protection provided by a private key, so we
would get back to the situation we have now with the self-certificate,
but we would also have to pay yearly fees.
A true digital certificate would helps in signing QuantLib.xla for
official releases, providing final end users with a real security
protection.

So manually adding back the digital signature using the (private key)
self-certificate on my workstation is the only solution we have found
so far that allows developers/beta_users who trust the distributed
(public key) certificate to avoid pop ups when using QuantLib.xla with
"medium" Excel security level or to use QuantLib.xla in "high"
security level.

If anyone has suggestions to improve the current situation it would be
more than welcome

ciao -- Nando

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10532] trunk/QuantLibXL/framework/QuantLibXL.xla

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

On Wed, 2007-05-02 at 10:17 -0700, na...@us... wrote:
> Revision: 10532
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10532&view=rev
> Author:   nando
> Date:     2007-05-02 10:17:15 -0700 (Wed, 02 May 2007)
> 
> Log Message:
> -----------
> digital signature added back

I see a lot of these messages lately. How manual is the generation of
the signature? It seems like something that could be added as a
post-build action...

Luigi


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

The doctrine of human equality reposes on this: that there is no man 
really clever who has not found that he is stupid. 
-- Gilbert K. Chesterson 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10531] trunk/QuantLib

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

On Wed, 2007-05-02 at 10:05 -0700, chi...@us... wrote:
> Revision: 10531
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10531&view=rev
> Author:   chiforna
> Date:     2007-05-02 10:05:09 -0700 (Wed, 02 May 2007)
> 
> Log Message:
> -----------
> - provided WeeklyTenorLibor and MonthlyTenorLibor (which should/will be used instead of Libor)

We don't need classes for that, do we? We can just check the units of
the passed period and set the conventions accordingly. Do you mind if I
go ahead and make the change?

Luigi


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

Glendower: I can call spirits from the vasty deep. 
Hotspur: Why, so can I, or so can any man; 
But will they come when you do call for them? 
-- King Henry the Fourth Part I, Act III, Scene I 

Re: [Quantlib-dev] New math libraries in Boost

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

On Thu, 2007-04-26 at 14:00 -0300, Piter Dias wrote:
> Today I visited Boost in order to see if there is some news and found the
> Math Toolkit library under review.

Yes, I've seen the announcement on their mailing list. I haven't looked
at the documentation yet, but the first reviews seemed good.

We'll probably have to wait some time before it's released with Boost,
but we're not in a hurry anyway...

Thanks for the head-up,
	Luigi


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

Humphrey's Requirements Uncertainty Principle: 
For a new software system, the requirements will not be 
completely known until after the users have used it.