quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] More problems with QuantLib-Ruby

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

Hi Liguo,

On 2003.10.31 22:54, Liguo Song wrote:
> After upgrading to ruby-1.8.0, I begin to experience a new problem.
> 
> In ruby-1.6.*, the host-os is linux, which is what the setup.rb  
> expects. But in ruby-1.8.0, the host-os is called linux-gnu, which
> really ruins the day for the setup.rb.

Hmm. Maybe a Red Hat thing---it's still 'linux' in ruby 1.8.0 on  
Debian.

It's a small fix anyway---wherever it says

when 'linux'

change it to

when 'linux','linux-gnu'

I already committed it to cvs.

Thanks,
	Luigi

Re: [Quantlib-dev] Release?

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

Hi all,

On 2003.10.31 18:20, Ferdinando Ametrano wrote:
> Luigi:
>>         this looks to me like a good time to branch out 0.3.4---a  
>> few bugs were fixed (most notably, the library works again with  
>> Borland) and a few features added.
> 
> I would have liked to ask Niels Elken Sønderbys (in CC here) if he  
> would merge his SVJD code (http://www.nielses.dk/quantlib/nesquant/)  
> into QuantLib before the next release.

I was aware of nesquant, even though I didn't mention it. It looked to  
me as one of the nice things we will include into next release, but not  
into this one as it will probably take a while to integrate it and add  
tests. I was thinking of 0.3.4 as a bug-fix release. Heck, Borland  
users couldn't even _use_ 0.3.3.

> Another thing I would like to have fixed is the broken Borland  
> documentation. Luigi: I'm sure it will take few minutes of your  
> time ;-)

You'll be happy to hear that I now have a new box, and Borland isn't  
even installed yet. "A few minutes" kind of strikes me as an  
underestimate :) That, and the fact that I don't know what's broken.
(and anyway, bug-fixes can be applied to the branch)

> A 0.3.4 related issue: I would like to remove my personal address  
> fer...@am... (which I'm going to suspend for a few months  
> due to excessive spam > 300 messages per day) from the "You should  
> have received a copy of the license along with this program; if not,  
> please email fer...@am..." file header. Suggestion about  
> which address could be used instead? What about quantlib-dev@lists. 
> sourceforge.net ?

Ok for me.

>>  The current code would nicely qualify as a
>> semi-stable, bug-fix release which people could rely on while we go
>> ahead and break the world (or start using boost, or flatten  
>> namespaces, or generally start some new development.)
> 
> since you were planning to be backward compatible for one release on  
> namespace flattening, why don't we do it for 0.3.4?

Because I have a real work :)
Also, my point was: we could use a bug-fix release, this is a good  
time, let's branch before we break something else.

Later,
	Luigi

[Quantlib-dev] More problems with QuantLib-Ruby

[Liguo S. <Lig...@va...>]

After upgrading to ruby-1.8.0, I begin to experience a new problem.

In ruby-1.6.*, the host-os is linux, which is what the setup.rb expects. But in 
ruby-1.8.0, the host-os is called linux-gnu, which really ruins the day for the 
setup.rb.

I can modify the source with the RPM package. But, this might cause problem for 
the future release. Any patch from the ruby gurus on this list?

Thanks.


Liguo

[Quantlib-dev] RPM packages for QuantLib-Python-0.3.3 are available on sourceforge.net

[Liguo S. <Lig...@va...>]

QuantLib users and developers,

RPM packages for QuantLib-Python-0.3.3 are available on sourceforege.net now. 
Check them out at  http://quantlib.org/download.html. Thanks to Nando for 
putting them there. As I am not a python programmer, I haven't done extensive 
testing on it except the test cases in the package. Please let me know if there 
is any bugs in these RPM packages.

RPM packages for the other language wrappers are on their way. They should all 
be present for the 0.3.4 release, I hope. :)

Have a nice weekend.


Liguo (Leo)

[Quantlib-dev] about

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

Liguo:
>I was just reading The Cathedral and the Bazaar by Eric Steven Raymond. It 
>is some eye-opener for the open source software projects.

It was february 2000: I just discovered Python and I was amazed that such a 
great software was free. Then "The Cathedral and the Bazaar" hooked me 
completely. At the time I taught Richard Stallman was too radical, and I 
was fond of the ESR Open Source approach.

Four years later I've realized Stallman was not too radical, he was simply 
right.

YMMV

ciao -- Nando

Re: [Quantlib-dev] QuantLib-Ruby-0.3.3 bug report and building assistance.

[Liguo S. <Lig...@va...>]

Hi, Luigi,

> You need the Test::Unit framework. You can get it from  
> <http://testunit.talbott.ws>. You'll need version 0.1.8 or above.
Just checked the place. And since ruby-1.8, Test::Unit lives inside the main 
ruby package. My ruby is 1.6.7. I will upgrade it to 1.8.

> Hmm. I'll look into it. There's probably some way to tell autoconf to  
> add a prefix to the macro names.
Inside /usr/lib/ruby/1.6/i386-linux/config.h, those macros are all defined as 
"". It seems a little wierd for me to do something like this.

Thanks for check it.


Liguo

Re: [Quantlib-dev] Release?

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

Luigi:
>         this looks to me like a good time to branch out 0.3.4---a few
>bugs were fixed (most notably, the library works again with Borland)
>and a few features added.

I would have liked to ask Niels Elken S=F8nderbys (in CC here) if he would=
=20
merge his
SVJD code (http://www.nielses.dk/quantlib/nesquant/) into QuantLib before=20
the next release. I don't remember if he is already a quantlib-dev=20
subscriber: if I didn't invite you before Niels, please accept my apologies=
=20
and consider this an open invitation.
To add the code should be easy enough, but it would make sense to add a=20
unit test too.
Of course we might just add SVJD for 0.3.5, especially if the merge+test=20
take longer than 1 week.
BTW Niels: please consider to actively work on the current CVS, I grant you=
=20
we will make it clear what your (master thesis) work consists ;-)

Another thing I would like to have fixed is the broken Borland=20
documentation. Luigi: I'm sure it will take few minutes of your time ;-)

A 0.3.4 related issue: I would like to remove my personal address=20
fer...@am... (which I'm going to suspend for a few months due to=
=20
excessive spam > 300 messages per day) from the "You should have received a=
=20
copy of the license along with this program; if not, please email=20
fer...@am..." file header. Suggestion about which address could=
=20
be used instead? What about qua...@li... ?

>  The current code would nicely qualify as a
>semi-stable, bug-fix release which people could rely on while we go
>ahead and break the world (or start using boost, or flatten namespaces,
>or generally start some new development.)

since you were planning to be backward compatible for one release on=20
namespace flattening, why don't we do it for 0.3.4?

My 0.2$

ciao -- Nando=20

Re: [Quantlib-dev] QuantLib-Ruby-0.3.3 bug report and building assistance.

[Liguo S. <Lig...@va...>]

Hi, Dirk,

Dirk Eddelbuettel wrote:
> On Thu, Oct 30, 2003 at 03:12:43PM -0600, Liguo Song wrote:
> 
>>I am building the RPM package for QuantLib-Ruby-0.3.3. As I know nothing 
>>about ruby, so I might need someone with more experience with this package 
>>to help me out.
> 
> 
> Luigi helped me years ago, and I recall that I used some small patches of
> his in either install.rb or setup.rb, or both.  But based on the current
> diff.gz, I do no longer. Not sure when those ceased to be required, maybe
> around 0.3? 
> 
> Here is what I do, in a nutshell:
> 
> 
> cxxcompiler  = g++
> compilerflags  = -O2 
> 
>        
>        # per Luigi's suggestion	
>        touch quantlib_wrap.cpp
>        CXX="$(cxxcompiler)" 		\
>        CFLAGS="$(compilerflags)" 	\
>        CXXFLAGS="$(compilerflags)" 	$(RUBY) setup.rb build  
> 
> 
>        [...]
> 
>        CXX="$(cxxcompiler)"      	\
>        CFLAGS="$(compilerflags)" 	\
>        CXXFLAGS="$(compilerflags)" 	\
>        $(RUBY) setup.rb install --prefix=debian/$(package)
> 
> 
> 
> You can look at any Debian mirror for QuantLib-Ruby_0.3.3-4.diff.gz (for the
> most current release) which is a diff against the pristine QL sources.
Thanks for clarifying the steps for me. It gives me some ideas to improve my 
spec file to build the rpm package. :)


>>Second, does the test suite of QuantLib-Ruby require something like cppunit 
>>to run? If so, where can I get it?
> 
> 
> It's a Debian package for me, but I cheat and don't run this for QL-Ruby.
The test should be optional. But I'd like to make use of it if the required 
software is present. It would help to prevent a corrupted build, which happens 
when I tried to optimized the quantlib compile. But the test-suite saved the day 
there. :)

> 
> You can look at our build-logs if you want to compare warnings:
> 	http://buildd.debian.org/build.php?pkg=quantlib-ruby
> for all different build architectures going back to the 0.2.1 release.
I just looked at it. There is no such warning about these macros. Wierd. BTW, 
which one is i386/i686? Some names of the architectures are not familiar to me.

> BTW I'm all for 0.3.4 -- good idea AFAICT.
Same here, if I didn't mention before. Frequent bug fixing releases aside from 
the main developing branch is a great idea. I was just reading The Cathedral and 
the Bazaar by Eric Steven Raymond. It is some eye-opener for the open source 
software projects.

Have a nice weekend.


Liguo

Re: [Quantlib-dev] QuantLib-Ruby-0.3.3 bug report and building assistance.

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

Hi Liguo,

On 2003.10.30 22:12, Liguo Song wrote:
> I am building the RPM package for QuantLib-Ruby-0.3.3. As I know  
> nothing about ruby, so I might need someone with more experience with  
> this package to help me out.
> 
> First of all, the bug report:
> README.txt:
>  line 8: ruby setup.py wrap -> ruby setup.rb wrap

Ouch.
(aside: you shouldn't need that step, though. The SWIG-generated file  
is included in the tarball. You can start from "ruby setup.py build".)
 
> Second, does the test suite of QuantLib-Ruby require something like  
> cppunit to run? If so, where can I get it?

You need the Test::Unit framework. You can get it from  
<http://testunit.talbott.ws>. You'll need version 0.1.8 or above.

> Third, when building the QuantLib-Ruby package, there are serveral  
> warnings about the redefinition of macros. The error messages are  
> like the following:
> *******************************************************************************
> 	In file included from /usr/include/ql/qldefines.hpp:68,
>         	         from /usr/include/ql/quantlib.hpp:23,
>                 	 from quantlib_wrap.cpp:804:
> 	/usr/include/ql/config.hpp:98:1: warning: "PACKAGE_BUGREPORT"  
> redefined
> 	In file included from /usr/lib/ruby/1.6/i386-linux/ruby.h:21,
>         	         from quantlib_wrap.cpp:28:
> 	/usr/lib/ruby/1.6/i386-linux/config.h:6:1: warning: this is the  
> location of the previous definition
> *******************************************************************************
> Other macros with this problem are PACKAGE_NAME, PACKAGE_STRING,  
> PACKAGE_TARNAME, and PACKAGE_VERSION.
> 
> After some research, I found that these macros are defined in both / 
> usr/include/ql/config.hpp and /usr/lib/ruby/1.6/i386-linux/config.h.  
> Would this cause any surprise in the future?

Hmm. I'll look into it. There's probably some way to tell autoconf to  
add a prefix to the macro names.

Thanks,
	Luigi

Re: [Quantlib-dev] QuantLib-Ruby-0.3.3 bug report and building assistance.

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

On Thu, Oct 30, 2003 at 03:12:43PM -0600, Liguo Song wrote:
> I am building the RPM package for QuantLib-Ruby-0.3.3. As I know nothing 
> about ruby, so I might need someone with more experience with this package 
> to help me out.

Luigi helped me years ago, and I recall that I used some small patches of
his in either install.rb or setup.rb, or both.  But based on the current
diff.gz, I do no longer. Not sure when those ceased to be required, maybe
around 0.3? 

Here is what I do, in a nutshell:


cxxcompiler  = g++
compilerflags  = -O2 

       
       # per Luigi's suggestion	
       touch quantlib_wrap.cpp
       CXX="$(cxxcompiler)" 		\
       CFLAGS="$(compilerflags)" 	\
       CXXFLAGS="$(compilerflags)" 	$(RUBY) setup.rb build  


       [...]

       CXX="$(cxxcompiler)"      	\
       CFLAGS="$(compilerflags)" 	\
       CXXFLAGS="$(compilerflags)" 	\
       $(RUBY) setup.rb install --prefix=debian/$(package)



You can look at any Debian mirror for QuantLib-Ruby_0.3.3-4.diff.gz (for the
most current release) which is a diff against the pristine QL sources.


> Second, does the test suite of QuantLib-Ruby require something like cppunit 
> to run? If so, where can I get it?

It's a Debian package for me, but I cheat and don't run this for QL-Ruby.

You can look at our build-logs if you want to compare warnings:
	http://buildd.debian.org/build.php?pkg=quantlib-ruby
for all different build architectures going back to the 0.2.1 release.

BTW I'm all for 0.3.4 -- good idea AFAICT.

Cheers, Dirk
    
-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx

[Quantlib-dev] QuantLib-Ruby-0.3.3 bug report and building assistance.

[Liguo S. <Lig...@va...>]

I am building the RPM package for QuantLib-Ruby-0.3.3. As I know nothing about 
ruby, so I might need someone with more experience with this package to help me out.

First of all, the bug report:
README.txt:
  line 8: ruby setup.py wrap -> ruby setup.rb wrap

Second, does the test suite of QuantLib-Ruby require something like cppunit to 
run? If so, where can I get it?

I encountered the following errors when try to use ruby setup.rb test
*******************************************************************************
	ruby setup.rb test
	Building extension...
	creating Makefile
	make: Nothing to be done for `all'.
	Testing QuantLib-Ruby...
	./QuantLibTestSuite.rb:17:in `require': No such file to load -- 	test/unit 
(LoadError)
		from ./QuantLibTestSuite.rb:17
		from setup.rb:211:in `load'
		from setup.rb:211
		from setup.rb:206:in `call'
		from setup.rb:137:in `execute'
		from setup.rb:268
*******************************************************************************


Third, when building the QuantLib-Ruby package, there are serveral warnings 
about the redefinition of macros. The error messages are like the following:
*******************************************************************************
	In file included from /usr/include/ql/qldefines.hpp:68,
         	         from /usr/include/ql/quantlib.hpp:23,
                 	 from quantlib_wrap.cpp:804:
	/usr/include/ql/config.hpp:98:1: warning: "PACKAGE_BUGREPORT" redefined
	In file included from /usr/lib/ruby/1.6/i386-linux/ruby.h:21,
         	         from quantlib_wrap.cpp:28:
	/usr/lib/ruby/1.6/i386-linux/config.h:6:1: warning: this is the location of the 
previous definition
*******************************************************************************
Other macros with this problem are PACKAGE_NAME, PACKAGE_STRING, 
PACKAGE_TARNAME, and PACKAGE_VERSION.

After some research, I found that these macros are defined in both 
/usr/include/ql/config.hpp and /usr/lib/ruby/1.6/i386-linux/config.h. Would this 
cause any surprise in the future?

Thanks for your help.


Liguo (Leo)

[Quantlib-dev] Release?

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

Hi all,
	this looks to me like a good time to branch out 0.3.4---a few  
bugs were fixed (most notably, the library works again with Borland)  
and a few features added. The current code would nicely qualify as a  
semi-stable, bug-fix release which people could rely on while we go  
ahead and break the world (or start using boost, or flatten namespaces,  
or generally start some new development.)

In short, if there are no objections, I would create the 0.3.4 branch  
Monday morning. Henceforth, only bug fixes would be committed on the  
branch---new developments would go into the trunk and appear in 0.3.5.

Objections? Thoughs?

Later,
	Luigi

[Quantlib-dev] [ quantlib-Feature Requests-807851 ] Adding custom constraints to short-rate model calibration

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

Feature Requests item #807851, was opened at 2003-09-17 16:52
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=807851&group_id=12740

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Francesco Perissin (fperissin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Adding custom constraints to short-rate model calibration

Initial Comment:
Users should be able to add constrains to the model 
calibration.
For example, one may want to keep constant one of the 
2 parameters of the Hull-White model, and calibrate on 
the other.

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

Comment By: Luigi Ballabio (lballabio)
Date: 2003-10-30 18:19

Message:
Logged In: YES 
user_id=75450

The feature is now implemented in CVS and will be available in the 
next library release.


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

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

[Quantlib-dev] [ quantlib-Feature Requests-820783 ] Add method for getting implied volatility in caplet

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

Feature Requests item #820783, was opened at 2003-10-09 20:03
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=820783&group_id=12740

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: amar singh (asd2003)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add method for getting implied volatility in caplet

Initial Comment:
To add a method 'impliedvolatility' in the cap or 
associated classes, to be able to calculate implied 
volatility for a caplet.

Thanks!

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

Comment By: Luigi Ballabio (lballabio)
Date: 2003-10-30 17:12

Message:
Logged In: YES 
user_id=75450

The feature is now implemented in CVS and will be available in the 
next library release.


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

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

[Quantlib-dev] your.name@quantlib.org

[Jens T. <Je...@Th...>]

Hi all,

email forwarded through you...@qu... is filtered more agressively
for SPAM lately. Well-known spammers, unusual SMTP implementations, open
proxies and relays are rejected at the mail server. All other content is
filtered and sanitzed (that is, evil HTML and some attachments deleted). 

The filters add some custom mail headers that your mail client can use to
filter SPAM:

  X-Spam-Level: *******

is set to the number of SPAM points the message received. You can suspect
SPAM with 3 stars and more and tag (or move) the message as you like.
Additional information is given in the X-Spam-Status header.

  X-Spam-Flag: YES

is set with 5 stars and more; you can safely delete these ;-)

Mails routed through sourceforge get a similar header:

  X-Spam-Score: 2.0 (++)

Does anyone know more about this?


Jens.

[Quantlib-dev] [ quantlib-Feature Requests-824364 ] The Real typedef should be used throughout

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

Feature Requests item #824364, was opened at 2003-10-15 22:18
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=824364&group_id=12740

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Dann Corbit (danncorbit)
Assigned to: Nobody/Anonymous (nobody)
Summary: The Real typedef should be used throughout

Initial Comment:
You have a typedef of real like so:

typedef double Real;

but throughout the code, you use ordinary doubles all 
over the place.  Hence, the typedef is basically useless.

If (on the other hand) throughout the code you used 
Real parameters and Real automatic variables, then I 
would be able to use the system with other data types 
such as Moshier's Qfloat, Scott's MIRACL, etc. by making 
my own typedef as follows:

typedef qfloat Real;

or similar to that.

We need to compute with 100 digits of accuracy, so a 
double simply won't do.


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

>Comment By: Luigi Ballabio (lballabio)
Date: 2003-10-24 09:32

Message:
Logged In: YES 
user_id=75450

Hi,
    I have to admit that I even forgot about the Real typedef... 
We'll see what we can do. Does a textual replace of all 
"double" to "Real" work for you?

And just out of curiosity, 100 digits? What kind of financial 
application needs that accuracy?

Bye,
        Luigi


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

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

[Quantlib-dev] [ quantlib-Feature Requests-822568 ] "Getting started" page

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

Feature Requests item #822568, was opened at 2003-10-13 10:10
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=822568&group_id=12740

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Luigi Ballabio (lballabio)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Getting started" page

Initial Comment:
We need a page on the site to which we can refer people 
asking "Where should I start to tackle QuantLib? What to 
read first? Where to go next?" and so on. Once we have 
it, the above can be the first item in a FAQ.


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

>Comment By: Luigi Ballabio (lballabio)
Date: 2003-10-24 09:27

Message:
Logged In: YES 
user_id=75450

Moved to the todo list

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

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

[Quantlib-dev] RE: Basis-point sensitivity and such

[Andre L. <An...@de...>]

Luigi wrote:
> I did some refactoring of basis-point sensitivity calculation  
> and related classes. Could you check that everything works? (Or even  
> better, add a test). 

Will do

> Also, could you document a bit your BPS-basket  
> calculation? For instance, why a subtraction in 
> visit(FixedRateCoupon) instead of the addition in visit(Coupon)?

I will try my best on the documentation. At the coupon level (fixed or not)
it should be simple addition, the subtraction would then happen in the
instrument, depending on which cashflow is payed vs. received. I will fix
this.

> 
> Warning: some interface has changed. In particular, I made the  
> TimeBasket class a whole lot slimmer. However, I kept all its  
> functionality---the differences are only in syntax....

Great, I will have a look

Thanx
Andre

[Quantlib-dev] [ quantlib-Feature Requests-824364 ] The Real typedef should be used throughout

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

Feature Requests item #824364, was opened at 2003-10-15 13:18
Message generated for change (Comment added) made by danncorbit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=824364&group_id=12740

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Dann Corbit (danncorbit)
Assigned to: Nobody/Anonymous (nobody)
Summary: The Real typedef should be used throughout

Initial Comment:
You have a typedef of real like so:

typedef double Real;

but throughout the code, you use ordinary doubles all 
over the place.  Hence, the typedef is basically useless.

If (on the other hand) throughout the code you used 
Real parameters and Real automatic variables, then I 
would be able to use the system with other data types 
such as Moshier's Qfloat, Scott's MIRACL, etc. by making 
my own typedef as follows:

typedef qfloat Real;

or similar to that.

We need to compute with 100 digits of accuracy, so a 
double simply won't do.


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

>Comment By: Dann Corbit (danncorbit)
Date: 2003-10-24 00:43

Message:
Logged In: YES 
user_id=887860

> Hi,
>     I have to admit that I even forgot about the Real 
typedef... 
> We'll see what we can do. Does a textual replace of all 
> "double" to "Real" work for you?

I think probably so.  If not, it would make it a heck of a lot 
easier for me.

> And just out of curiosity, 100 digits? What kind of financial 
> application needs that accuracy?

I write database systems.  Someone can be computing the 
interest on the national debt.  Someone might be doing a 
summation of a billion quadwords. (There is at least one 
application where this is a fact -- a database of all the road-
tolls ever taken in one of the states of the US).

We cannot anticipate what sort of data they may throw at 
the system.  But no matter what it is, we must compute the 
right answer.

We also handle exponents that are quite large.


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

Comment By: Luigi Ballabio (lballabio)
Date: 2003-10-24 00:32

Message:
Logged In: YES 
user_id=75450

Hi,
    I have to admit that I even forgot about the Real typedef... 
We'll see what we can do. Does a textual replace of all 
"double" to "Real" work for you?

And just out of curiosity, 100 digits? What kind of financial 
application needs that accuracy?

Bye,
        Luigi


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

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

[Quantlib-dev] Basis-point sensitivity and such

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

Hi Andre',
	I did some refactoring of basis-point sensitivity calculation  
and related classes. Could you check that everything works? (Or even  
better, add a test). Also, could you document a bit your BPS-basket  
calculation? For instance, why a subtraction in visit(FixedRateCoupon)  
instead of the addition in visit(Coupon)?

Warning: some interface has changed. In particular, I made the  
TimeBasket class a whole lot slimmer. However, I kept all its  
functionality---the differences are only in syntax, i.e.,instead of

basket.push(date,value);
basket.add(date,value);
basket.subtract(date,value);

one now writes

basket[date] = value;
basket[date] += value;
basket[date] -= value;

respectively, and instead of

for (Size i=0; i<basket.size(); i++) {
    Entry e = basket[i];
    Date d = e.date();
    double v = e.value();
    ...
}

one now writes

for (TimeBasket::iterator i=basket.begin(); i!=basket.end(); ++i) {
    Date d = i->first;
    double v = i->second;
    ...
}

Cheers,
	Luigi

Re: [Quantlib-dev] Visual C++ settings

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

At 01:01 PM 10/22/2003, Luigi Ballabio wrote:
>>I'm not against adding multiple configurations for the Multithreaded
>>switch, but all combinations of Multithread+OnTheEdge would lead to 8
>>configurations....
>
>And that's exactly the reason why I would jettison the on-the-edge
>thing :)

Go ahead. I was just reminding the historical reason behind the OnTheEdge 
settings, non defending them. I don't use them anymore in my current work ;-)

ciao -- Nando 

Re: [Quantlib-dev] Visual C++ settings

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

Hi,

On 2003.10.22 11:29, Ferdinando Ametrano wrote:
> 
>>         could anyone remind me why we have two "On the edge"
>> configurations in the VC project?

> from http://quantlib.org/html/usage.html, point 5:
> The "Win32 OnTheEdgeRelease" and "Win32 OnTheEdgeDebug"  
> configurations are equivalent to "Win32 Release" and "Win32 Debug"  
> respectively, except that they do not use the installed QuantLib  
> libraries, but look for the hpp and lib QuantLib files in a  
> relative ..\QuantLib path. This is mainly for QuantLib developers, to  
> allow them to check the examples without having to install their  
> unstable working version of QuantLib.

Hmm. In my opinion, the examples and the test suite should _always_  
point to ../ql and ../lib. It would be kind of strange that they linked  
against a different version of the library than the one in their very  
same workspace. This looks to me like the most natural way you can  
check the examples when you modify the library. And it's still easy to  
work on the past release---just open its workspace. Inside a workspace,  
everything is consistent.

> The "OnTheEdge" approach may be
> adopted in projects using QuantLib, allowing for a quick and easy way  
> to check how the projects work with a new QuantLib release without  
> having to install it.

Except that you have to replicate the on-the-edge configurations in  
your project (the pain! the horror!)
Real developers temporarily modify their QL_DIR environment variable  
instead :)

>> Secondly: why not having a configuration with "Multithreaded" and
>> another for "Multithreaded DLL", instead of arguing about which  
>> should be used?

> Whatever setting is currently selected can be easily modified by the  
> user...

...but if a developer switches, he must remember to revert the project  
before committing his working copy to CVS.

> I'm not against adding multiple configurations for the Multithreaded  
> switch, but all combinations of Multithread+OnTheEdge would lead to 8  
> configurations....

And that's exactly the reason why I would jettison the on-the-edge  
thing :)

> BTW what is the "Win32 Intel OnTheEdgeRelease" configuration? If I  
> remember right it is for using the Visual Studio IDE with the Intel  
> compiler: could the users please document its usage?

Never used it. Maybe Marco can elaborate?

Later,
	Luigi

Re: [Quantlib-dev] Visual C++ settings

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

>         could anyone remind me why we have two "On the edge"
>configurations in the VC project which are indistinguishable from the
>ordinary "Release" and "Debug"?
from http://quantlib.org/html/usage.html, point 5:
The "Win32 OnTheEdgeRelease" and "Win32 OnTheEdgeDebug" configurations are 
equivalent to "Win32 Release" and "Win32 Debug" respectively, except that 
they do not use the installed QuantLib libraries, but look for the hpp and 
lib QuantLib files in a relative ..\QuantLib path. This is mainly for 
QuantLib developers, to allow them to check the examples without having to 
install their unstable working version of QuantLib. The "OnTheEdge" 
approach may be adopted in projects using QuantLib, allowing for a quick 
and easy way to check how the projects work with a new QuantLib release 
without having to install it.


>Secondly: why not having a configuration with "Multithreaded" and
>another for "Multithreaded DLL", instead of arguing about which should
>be used?

since we've dropped the requirement for "Multithreaded" (or "Multithreaded 
DLL") any arguing should have ended. Whatever setting is currently selected 
can be easily modified by the user, paying the cost of recompiling the 
library. We should update this info in the documentation (point 2 of 
http://quantlib.org/html/usage.html)
I'm not against adding multiple configurations for the Multithreaded 
switch, but all combinations of Multithread+OnTheEdge would lead to 8 
configurations....

BTW what is the "Win32 Intel OnTheEdgeRelease" configuration? If I remember 
right it is for using the Visual Studio IDE with the Intel compiler: could 
the users please document its usage?

ciao -- Nando

Re: [Quantlib-dev] Visual C++ settings

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

Ciao Enrico,

On 2003.10.22 16:22, enr...@ri... wrote:
> >>>>> "Gigi" == Luigi Ballabio <lui...@fa...> writes:
> > could anyone remind me why we have two "On the edge"
> > configurations in the VC project which are indistinguishable
> > from the ordinary "Release" and "Debug"?
> 
> for historical reason? I remember Nando liked this configuration a
> lot, he used it to distinguish between "current" and "stable"
> releases. IMO this should be done using different workspaces.

My point exactly.

> > Secondly: why not having a configuration with
> > "Multithreaded" and another for "Multithreaded DLL", instead
> > of arguing about which should be used?
> 
> I completely agree with you.

Thanks.

> By the way, I also completely agree with
> the three proposals you posted some time ago (boost smart pointers,
> flattening name spaces - how about shortening it too? QL:: or ql::
> seems nice, and template lattice framework).

Well, you can agree with the first two (and as for the second, we can  
use namespace aliases, so we can have QuantLib, QL and ql too)
but as for the third, I was in doubt between two alternatives---which  
one is the one you're agreeing with?

Later,
	Luigi

Fwd: Re: [Quantlib-dev] Visual C++ settings

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

apparently this didn't show up yet... I'm trying again


>Date: Wed, 22 Oct 2003 11:29:05 +0200
>To: lui...@fa..., QuantLib developers 
><qua...@li...>
>From: Ferdinando Ametrano <na...@am...>
>Subject: Re: [Quantlib-dev] Visual C++ settings
>
>>         could anyone remind me why we have two "On the edge"
>>configurations in the VC project which are indistinguishable from the
>>ordinary "Release" and "Debug"?
>from http://quantlib.org/html/usage.html, point 5:
>The "Win32 OnTheEdgeRelease" and "Win32 OnTheEdgeDebug" configurations are 
>equivalent to "Win32 Release" and "Win32 Debug" respectively, except that 
>they do not use the installed QuantLib libraries, but look for the hpp and 
>lib QuantLib files in a relative ..\QuantLib path. This is mainly for 
>QuantLib developers, to allow them to check the examples without having to 
>install their unstable working version of QuantLib. The "OnTheEdge" 
>approach may be adopted in projects using QuantLib, allowing for a quick 
>and easy way to check how the projects work with a new QuantLib release 
>without having to install it.
>
>
>>Secondly: why not having a configuration with "Multithreaded" and
>>another for "Multithreaded DLL", instead of arguing about which should
>>be used?
>
>since we've dropped the requirement for "Multithreaded" (or "Multithreaded 
>DLL") any arguing should have ended. Whatever setting is currently 
>selected can be easily modified by the user, paying the cost of 
>recompiling the library. We should update this info in the documentation 
>(point 2 of http://quantlib.org/html/usage.html)
>I'm not against adding multiple configurations for the Multithreaded 
>switch, but all combinations of Multithread+OnTheEdge would lead to 8 
>configurations....
>
>BTW what is the "Win32 Intel OnTheEdgeRelease" configuration? If I 
>remember right it is for using the Visual Studio IDE with the Intel 
>compiler: could the users please document its usage?
>
>ciao -- Nando