quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] [ quantlib-Bugs-934626 ] Excel is hung when calling qlAmericanOption_FD

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

Bugs item #934626, was opened at 2004-04-13 17:09
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=934626&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Excel is hung when calling qlAmericanOption_FD

Initial Comment:
it seems it only happens when the Type = C, and when 
the function template is used.

XL version = 0.35,
OS = XP Professional SP1;
QuantLib & QuantLibXL are compiled off the source code 
by the user using the 0.35 release.



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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-06-24 16:53

Message:
Logged In: NO 

Excel's function template invokes the function each time you
tab through the input fields.  Excel hangs when you enter
the expiry date (the 8th of the 10 input parameters).  The
reason that Excel does not hang before then is because the
relevant QuantLibXL function (xlAmericanOption_FD in file
QuantLibXL\qlxl\pricers.cpp) contains the line
                                                           
                                                           
double maturity      = Actual365().yearFraction(valueDate,
maturityDate);            
                                                           
                                                     which
throws an exception when either or both date is null,
causing the function to return #N/A to Excel.  Once both
dates are provided, the above line completes successfully,
and the code proceeds to call the underlying Quantlib
constructor FdAmericanOption(), which hangs because the
remaining input parameters are still null.           
                                                           
                                                     The
problem can be corrected by validating the input parameters
at the beginning of function xlAmericanOption_FD() and
exiting if any is missing:                                 
                                                           
             
    if (xltype.IsMissing() ||    
    xlunderlying.IsMissing() ||    
    ... etc ...    
    xlgridPoints.IsMissing())
        throw("missing inputs"); // returns #N/A to Excel  
     
                                                           
                                                         but
I'm not sure that's the right thing to do, there may be
times when you legitimately want to call a function with
some parameters missing, in which case the validation would
have to be more elaborate.

this bug occurs regardless of whether the type is C or P.

eric at ehlers dot plus dot com.

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

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

Re: [Quantlib-dev] tentative tarballs

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

On Fri, Jun 18, 2004 at 05:59:26PM +0200, Luigi Ballabio wrote:
> On 2004.06.18 16:30, Dirk Eddelbuettel wrote:
> >Can you point me to the smallest possible alteration of the tarball  
> >so that I could make it locally and get this shipped, and thus tested  
> >on other arches?
> 
> In QuantLibTestSuite.py, remove the relevant suite.addTest(...) line.

Thanks!  Had to do the same for TermStructureTests, and then it built fine.
Uploaded now, so we have the candidate releases of QL, QL-P and QL-R in
Debian.

Bye, Dirk

[ off-topic: what's the word on Totti in Italy?  There was a fabulous NY
Times article on him a few days before the tournament, chronicling his rise
in popularity with the two books of Totti jokes he wrote/issued. Can resend
the article if there is interest. Boy do I ever miss the tv coverage :-/ ]

-- 
FEATURE:  VW Beetle license plate in California

Re: [Quantlib-dev] tentative tarballs

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

On 2004.06.18 16:30, Dirk Eddelbuettel wrote:
> Can you point me to the smallest possible alteration of the tarball  
> so that I could make it locally and get this shipped, and thus tested  
> on other arches?

In QuantLibTestSuite.py, remove the relevant suite.addTest(...) line.

Later,
	Luigi

Re: [Quantlib-dev] tentative tarballs

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

On Fri, Jun 18, 2004 at 04:24:46PM +0200, Luigi Ballabio wrote:
> On 2004.06.18 05:36, Dirk Eddelbuettel wrote:
> >On Mon, Jun 14, 2004 at 09:36:41AM +0200, Luigi Ballabio wrote:
> >QuantLib itself built fine yesterday, and the build daemons have  
> >built ia64, s390, hppa, powerpc, arm, sparc and m68k.
> >
> >So I turned to QL-Python and QL-Ruby. QL-Python built, but has now
> >been hanging for 30 minutes at
> >	Testing observability of stocks ...
> >when running 'python2.3 setup test'.  Any idea?
> >
> >For what it's worth, QL-Ruby doesn't have the issue.
> 
> Hmm, I don't know. I never saw it happen in Python. I did see this  
> behavior in Ruby, but you didn't, so I'm officially puzzled.
> Unfortunately I don't have much time to investigate the thing (next  
> week I'm undergoing some minor surgery---nothing to be worried of, but  
> I won't have a computer nearby :) so I think I'll disable that specific  
> test in the final tarball and add the problem to the known bug list.

Can you point me to the smallest possible alteration of the tarball so that
I could make it locally and get this shipped, and thus tested on other arches?

Shall I just remove/rename/comment tests/instruments.py ?

Dirk

-- 
FEATURE:  VW Beetle license plate in California

Re: [Quantlib-dev] tentative tarballs

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

On 2004.06.18 05:36, Dirk Eddelbuettel wrote:
> On Mon, Jun 14, 2004 at 09:36:41AM +0200, Luigi Ballabio wrote:
> QuantLib itself built fine yesterday, and the build daemons have  
> built ia64, s390, hppa, powerpc, arm, sparc and m68k.
> 
> So I turned to QL-Python and QL-Ruby. QL-Python built, but has now
> been hanging for 30 minutes at
> 	Testing observability of stocks ...
> when running 'python2.3 setup test'.  Any idea?
> 
> For what it's worth, QL-Ruby doesn't have the issue.

Hmm, I don't know. I never saw it happen in Python. I did see this  
behavior in Ruby, but you didn't, so I'm officially puzzled.
Unfortunately I don't have much time to investigate the thing (next  
week I'm undergoing some minor surgery---nothing to be worried of, but  
I won't have a computer nearby :) so I think I'll disable that specific  
test in the final tarball and add the problem to the known bug list.

Later,
	Luigi

Re: [Quantlib-dev] tentative tarballs

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

On Mon, Jun 14, 2004 at 09:36:41AM +0200, Luigi Ballabio wrote:
> 
> Hi all,
> 	0.3.7 tarballs are now available in <http://quantlib.org/gm/>.  
> You're welcome to download and try them on your system(s). Three notes:

QuantLib itself built fine yesterday, and the build daemons have built ia64,
s390, hppa, powerpc, arm, sparc and m68k.  

So I turned to QL-Python and QL-Ruby. QL-Python built, but has now been
hanging for 30 minutes at 
	Testing observability of stocks ...
when running 'python2.3 setup test'.  Any idea?

For what it's worth, QL-Ruby doesn't have the issue.

> c) for Dirk :)
> these are NOT the final tarballs.

Thanks for that :)  I called them 0.3.6.rc.20040611 to ensure the final
0.3.7 will sort higher.

Dirk


-- 
FEATURE:  VW Beetle license plate in California

Re: [Quantlib-dev] tentative tarballs

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

On Wed, Jun 16, 2004 at 03:32:31PM +0200, Luigi Ballabio wrote:
> On 2004.06.16 15:00, Dirk Eddelbuettel wrote:
> >Something changed in the Makefiles.
> >
> >Is that caused by a new libtool version?  I guess I am simply behind
> >in terms of what is currently en vogue ...
> 
> Old libtool, new flags. It might (emphasis on might) make it feasible  
> to keep different versions installed.

Right, that's how it looks by encoding the major/minor in the filename.

> >From the looks of it, I need to make sure that the two .so libs (to  
> >which ldd on the example binary points) stay in the library package,  
> >and I should then be fine.  Comments?
> 
> I think so. lib*-0.3.7 should correspond to the old lib*.0.0.0.

Yes, I'll try that later then.
> 
> Later,
> 	Luigi
> 
> P.S. You won't have to depend on boost-regex in the final version (the  
> dependency probably came from a forgotten #include that I just nuked)

Ack. I may as well keep it in.  Would be nice to have configure checks for
the different boost pieces, though.

Ciao, Dirk

-- 
FEATURE:  VW Beetle license plate in California

Re: [Quantlib-dev] tentative tarballs

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

On 2004.06.16 15:00, Dirk Eddelbuettel wrote:
> Something changed in the Makefiles.
> 
> Is that caused by a new libtool version?  I guess I am simply behind
> in terms of what is currently en vogue ...

Old libtool, new flags. It might (emphasis on might) make it feasible  
to keep different versions installed.

> From the looks of it, I need to make sure that the two .so libs (to  
> which ldd on the example binary points) stay in the library package,  
> and I should then be fine.  Comments?

I think so. lib*-0.3.7 should correspond to the old lib*.0.0.0.

Later,
	Luigi

P.S. You won't have to depend on boost-regex in the final version (the  
dependency probably came from a forgotten #include that I just nuked)

Re: [Quantlib-dev] tentative tarballs

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

On Wed, Jun 16, 2004 at 07:49:51AM -0500, Dirk Eddelbuettel wrote:
> On Wed, Jun 16, 2004 at 12:14:02PM +0200, Luigi Ballabio wrote:
> > On 2004.06.16 04:32, Mark Treiber wrote:
> > >I spoke too soon.  I just looked back at the console history and the  
> > >original time QuantLib and the test-suite compiled it was with -O2.   
> > >When gcc crashed with QuantLib-python it was compiling with -O3.  I'm  
> > >re-compiling QuantLib now with -O1 (hopefully I won't have to go all  
> > >the way to -O0).
> > 
> > Mark,
> > 	you might want to go all the way up to gcc 3.3.4 instead.
> > I just recompiled the sources with -O3, and I didn't get the error.
> 
> Seconded, for what it's worth. It builds fine here on i386 with the default
> -02, once I figured out which of the Debian boost development packages I
> needed (libboost-dev, libboost-regex-dev, libboost-test-dev). I now have to
> fix something in the package structure that seems to stem from the split of
> the main libraries. So on track, but a little late...

Something changed in the Makefiles. Up until 0.3.6, I would have

edd@basebud:/var/local/cache/pbuilder/result> dpkg -c libquantlib0_0.3.6-1_i386.deb | grep usr/lib
drwxr-xr-x root/root         0 2004-04-15 17:44:31 ./usr/lib/
-rw-r--r-- root/root   3660992 2004-04-15 17:44:31 ./usr/lib/libQuantLib.so.0.0.0
lrwxrwxrwx root/root         0 2004-04-15 17:44:23 ./usr/lib/libQuantLib.so.0 -> libQuantLib.so.0.0.0

in the runtime package, and 

edd@basebud:/var/local/cache/pbuilder/result> dpkg -c libquantlib0-dev_0.3.6-1_i386.deb | grep usr/lib
drwxr-xr-x root/root         0 2004-04-15 17:44:33 ./usr/lib/
-rw-r--r-- root/root  15932122 2004-04-15 17:44:33 ./usr/lib/libQuantLib.a
lrwxrwxrwx root/root         0 2004-04-15 17:44:29 ./usr/lib/libQuantLib.so -> libQuantLib.so.0.0.0

in the development package.  The meta-rules where tagges on that, i.e.
/usr/lib/*.so and /usr/lib/*.a get moved into the -dev package.

Now I get 

basebud:/home/quantlib-0.3.6.rc.20040611/debian/libquantlib0-dev/usr/lib# ls -l
total 21912
-rwxr-xr-x    1 root     root      4742328 Jun 16 12:50 libQuantLib-0.3.7.so
-rw-r--r--    1 root     root     17215158 Jun 16 12:50 libQuantLib.a
lrwxrwxrwx    1 root     root           20 Jun 16 12:50 libQuantLib.so -> libQuantLib-0.3.7.so
-rwxr-xr-x    1 root     root       177061 Jun 16 12:50 libQuantLibFunctions-0.3.7.so
-rw-r--r--    1 root     root       250240 Jun 16 12:50 libQuantLibFunctions.a
lrwxrwxrwx    1 root     root           29 Jun 16 12:50 libQuantLibFunctions.so -> libQuantLibFunctions-0.3.7.so
basebud:/home/quantlib-0.3.6.rc.20040611/debian/libquantlib0-dev/usr/lib#

Is that caused by a new libtool version?  I guess I am simply behind in
terms of what is currently en vogue ...  From the looks of it, I need to
make sure that the two .so libs (to which ldd on the example binary points)
stay in the library package, and I should then be fine.  Comments?

Dirk

-- 
FEATURE:  VW Beetle license plate in California

Re: [Quantlib-dev] tentative tarballs

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

On Wed, Jun 16, 2004 at 12:14:02PM +0200, Luigi Ballabio wrote:
> On 2004.06.16 04:32, Mark Treiber wrote:
> >I spoke too soon.  I just looked back at the console history and the  
> >original time QuantLib and the test-suite compiled it was with -O2.   
> >When gcc crashed with QuantLib-python it was compiling with -O3.  I'm  
> >re-compiling QuantLib now with -O1 (hopefully I won't have to go all  
> >the way to -O0).
> 
> Mark,
> 	you might want to go all the way up to gcc 3.3.4 instead.
> I just recompiled the sources with -O3, and I didn't get the error.

Seconded, for what it's worth. It builds fine here on i386 with the default
-02, once I figured out which of the Debian boost development packages I
needed (libboost-dev, libboost-regex-dev, libboost-test-dev). I now have to
fix something in the package structure that seems to stem from the split of
the main libraries. So on track, but a little late...

Dirk, who is busy with Quantian


-- 
FEATURE:  VW Beetle license plate in California

Re: [Quantlib-dev] tentative tarballs

[<mrt...@en...>]

Unfortunately I'm limited to the gcc versions that apple releases (since they
are modified) and the latest is an Apple modified version of gcc 3.3-prerelease.
 Until apple updates their gcc (which may happen this summer with 10.4 coming
out) I found that compiling and the test-suite for QuantLib have no problems
with -O1 and that compiling and the test-suite for QuantLib-Python have no
problems with -O2.

Mark.

Quoting Luigi Ballabio <lui...@fa...>:

> 	you might want to go all the way up to gcc 3.3.4 instead.
> I just recompiled the sources with -O3, and I didn't get the error.


----------------------------------------
This mail sent through www.mywaterloo.ca

Re: [Quantlib-dev] tentative tarballs

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

On 2004.06.16 04:32, Mark Treiber wrote:
> I spoke too soon.  I just looked back at the console history and the  
> original time QuantLib and the test-suite compiled it was with -O2.   
> When gcc crashed with QuantLib-python it was compiling with -O3.  I'm  
> re-compiling QuantLib now with -O1 (hopefully I won't have to go all  
> the way to -O0).

Mark,
	you might want to go all the way up to gcc 3.3.4 instead.
I just recompiled the sources with -O3, and I didn't get the error.

Later,
	Luigi

Re: [Quantlib-dev] Keeping track of changes

[Mark T. <mrt...@en...>]

Sorry, replied to wrong message.

On Jun 15, 2004, at 10:32 PM, Mark Treiber wrote:

> I spoke too soon.  I just looked back at the console history and the 
> original time QuantLib and the test-suite compiled it was with -O2.  
> When gcc crashed with QuantLib-python it was compiling with -O3.  I'm 
> re-compiling QuantLib now with -O1 (hopefully I won't have to go all 
> the way to -O0).
>
> Mark.
>
> On Jun 15, 2004, at 10:37 AM, Luigi Ballabio wrote:
>
>>
>> Hi all,
>> 	mostly as an aid to Nando (which before a release goes through the 
>> ChangeLog, poor soul, and writes a list of the changes since the 
>> previous release) I've added a file called Changes.txt to the root 
>> QuantLib folder. After committing a change, you're invited to append 
>> to such file a short description of your contribution.
>>
>> Thanks,
>> 	Luigi
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>> Conference, June 28 - July 1 at the Moscone Center in San Francisco, 
>> CA
>> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
>> NWMGYKND
>> _______________________________________________
>> Quantlib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
> NWMGYKND
> _______________________________________________
> Quantlib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Keeping track of changes

[Mark T. <mrt...@en...>]

I spoke too soon.  I just looked back at the console history and the 
original time QuantLib and the test-suite compiled it was with -O2.  
When gcc crashed with QuantLib-python it was compiling with -O3.  I'm 
re-compiling QuantLib now with -O1 (hopefully I won't have to go all 
the way to -O0).

Mark.

On Jun 15, 2004, at 10:37 AM, Luigi Ballabio wrote:

>
> Hi all,
> 	mostly as an aid to Nando (which before a release goes through the 
> ChangeLog, poor soul, and writes a list of the changes since the 
> previous release) I've added a file called Changes.txt to the root 
> QuantLib folder. After committing a change, you're invited to append 
> to such file a short description of your contribution.
>
> Thanks,
> 	Luigi
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
> NWMGYKND
> _______________________________________________
> Quantlib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Keeping track of changes

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

Hi all,
	mostly as an aid to Nando (which before a release goes through  
the ChangeLog, poor soul, and writes a list of the changes since the  
previous release) I've added a file called Changes.txt to the root  
QuantLib folder. After committing a change, you're invited to append to  
such file a short description of your contribution.

Thanks,
	Luigi

Re: [Quantlib-dev] tentative tarballs

[Mark T. <mrt...@en...>]

On Jun 11, 2004, at 5:50 AM, Luigi Ballabio wrote:
>
> a) for all: you'll need a working Boost installation.
>

Perfect timing, my boost package just went into boost 10.3/unstable on 
friday.

> b) for packagers:
> "make" now creates two libraries, namely, libQuantLib-0.3.7 (as usual) 
> and libQuantLibFunctions-0.3.7, which is a functional rib taken out of 
> the main library. You may choose to package them together or 
> separately; in any case, note that the test-suite links to both, while 
> SWIG-generated bindings only link to the main library.
>

Everything compiles fine, although the new -release linking caught me 
out (although it makes sense).  The only problem is that I'm getting a 
single failure in the test suite.

Exception in "StatisticsTest::testStatistics": std::exception: 
incrementalstatistics.hpp:173: Real 
QuantLib::IncrementalStatistics::max() const: empty sample set

The detailed report level doesn't really add any additional information:

  Test suite "Statistics tests" failed with:
   1 test case out of 2 passed
   1 test case out of 2 failed
   0 assertions out of 0 passed
   0 assertions out of 0 failed

     Test case "StatisticsTest::testStatistics" failed with:
     0 assertions out of 0 passed
     0 assertions out of 0 failed
     Test case "StatisticsTest::testStatistics" was aborted due to 
uncaught exception, user assert or system error

     Test case "StatisticsTest::testSequenceStatistics" passed with:
     0 assertions out of 0 passed
     0 assertions out of 0 failed

Mark.

[Quantlib-dev] tentative tarballs

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

Hi all,
	0.3.7 tarballs are now available in <http://quantlib.org/gm/>.  
You're welcome to download and try them on your system(s). Three notes:

a) for all: you'll need a working Boost installation.

b) for packagers:
"make" now creates two libraries, namely, libQuantLib-0.3.7 (as usual)  
and libQuantLibFunctions-0.3.7, which is a functional rib taken out of  
the main library. You may choose to package them together or  
separately; in any case, note that the test-suite links to both, while  
SWIG-generated bindings only link to the main library.

c) for Dirk :)
these are NOT the final tarballs.

Later,
	Luigi

[Quantlib-dev] tentative tarballs

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

Hi all,
	0.3.7 tarballs are now available in <http://quantlib.org/gm/>.  
You're welcome to download and try them on your system(s). Three notes:

a) for all: you'll need a working Boost installation.

b) for packagers:
"make" now creates two libraries, namely, libQuantLib-0.3.7 (as usual)  
and libQuantLibFunctions-0.3.7, which is a functional rib taken out of  
the main library. You may choose to package them together or  
separately; in any case, note that the test-suite links to both, while  
SWIG-generated bindings only link to the main library.

c) for Dirk :)
these are NOT the final tarballs.

Later,
	Luigi

[Quantlib-dev] 0.3.7 branch

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

Hi all,
	I've just created a branch for release 0.3.7, to be announced  
sometime this month. Bug fixes (and only bug-fixes) should be committed  
on that branch, which has tag "R000307f0-branch". Tarballs will be soon  
available for our fearless packagers.

Later,
	Luigi

[Quantlib-dev] Re: [Quantlib-users] Specifying library to link

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

On 2004.06.08 10:07, Andre Louw wrote:
> distutils puts in a fully qualified name for the compiler i.e "C: 
> \Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe etc...", I've  
> checked and I can't find any environment variable (except my PATH)  
> that it might use? Any other suggestion?

No, unfortunately I've run out of ideas. The only suggestions I can  
give are to try:
- the distutils sources
- Google
- the Python mailing list (or newsgroup, they're aliased)

Later,
	Luigi

[Quantlib-dev] Specifying library to link

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

Still on this,

I asked:
> how does it (distutils) decide which compiler to use 

Luigi wrote:

> you might try putting your VC7 installation before VC6 in your PATH.

It's not a question of which compiler it _finds_, distutils puts in a 
fully qualified name for the compiler i.e "C:\Program Files\Microsoft 
Visual Studio\VC98\BIN\cl.exe etc...", I've checked and I can't find any 
environment variable (except my PATH) that it might use? Any other 
suggestion?

Andre

Re: [Quantlib-dev] Specifying library to link

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

On 2004.06.07 17:20, Ferdinando Ametrano wrote:
> At 02:29 PM 6/7/2004, Andre Louw wrote:
>> I'm trying to get the SWIG/Python setup on Windows to link to a  
>> library other than the one created by the 'Release' configuration,  
>> where does 'distutils'/setup.py get the information it uses to  
>> decide which library to link against?
> 
> I'm not that much familiar with SWIG/Python anymore, anyway the  
> library to be linked should be automagically selected by including  
> config.msvc.hpp through the inclusion of qldefines.hpp
> This should apply everywhere under Windows.

In fact the point is not how to tell which QuantLib library to use, but  
how to compile the wrappers. Including among the compiler options ones  
such as /MD, /ML or /MT should help--you'll have to modify the relevant  
variables in setup.py. Type cl -help at a command prompt to see which  
one corresponds to the one you want.

>> While I'm on the subject, how does it decide which compiler to use  
>> (I have both VC6 and 7 installed and it still uses 6 to compile  
>> with).
> The above SWIG/Python disclaimer still applies, anyway it should  
> depend on which compiler Python has been compiled with. As long as  
> you use the official Python distribution compiled with VC6 you're  
> going to only link VC6 libraries.

Alternatively, you might try putting your VC7 installation before VC6  
in your PATH.

Later,
	Luigi

Re: [Quantlib-dev] Specifying library to link

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

Hi

At 02:29 PM 6/7/2004, Andre Louw wrote:
>I'm trying to get the SWIG/Python setup on Windows to link to a library 
>other than the one created by the 'Release' configuration, where does 
>'distutils'/setup.py get the information it uses to decide which library 
>to link against?

I'm not that much familiar with SWIG/Python anymore, anyway the library to 
be linked should be automagically selected by including config.msvc.hpp 
through the inclusion of qldefines.hpp
This should apply everywhere under Windows.

>While I'm on the subject, how does it decide which compiler to use (I have 
>both VC6 and 7 installed and it still uses 6 to compile with).
The above SWIG/Python disclaimer still applies, anyway it should depend on 
which compiler Python has been compiled with. As long as you use the 
official Python distribution compiled with VC6 you're going to only link 
VC6 libraries.

ciao -- Nando

[Quantlib-dev] Specifying library to link

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

Hi,

I'm trying to get the SWIG/Python setup on Windows to link to a library 
other than the one created by the 'Release' configuration, where does 
'distutils'/setup.py get the information it uses to decide which library 
to link against? 
While I'm on the subject, how does it decide which compiler to use (I have 
both VC6 and 7 installed and it still uses 6 to compile with).

Any help appreciated


Andre

[Quantlib-dev] R

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

Hi Dirk,

>[ OT: I was at useR! 2004 last week, where I had helped to put some Finance
>content together. Lots of visibility of QL, and in particular the fellow who
>did www.rmetrics.org (which we will make Unix/Linux compatible, currently
>Windoze only) is quite interested and aware of QL.  Not sure how reciprocal
>that can get from the QL community as R is presumably seen as a bit of
>fringe language. For empirically minded souls, the R system is heavenly...
>But I digress :) ]

a quite interesting digression.

Next week I will take charge of a new project for my employer. The project 
is aimed to developing an implementation of the Black-Litterman asset 
allocation model (and more). I will work with Hannu Kahra, an associate 
professor from Finland: he should lead the modeling and he plans to use R. 
[I'm CC'ing him, but he will access his mailbox next Tuesday]

While I'm not sure if my employer will allow us to do the project as 
free-software/open-source, I'm quite sure there will be some positive fall out.

What is worrying me these days is that both Rmetrics and RQuantLib are GPL: 
one of the project's goal is to be able to re-distribute our work so this 
might rule out the usage of these GNU packages unless my company accept a 
GPL approach.

It would be too good to leverage QuantLib/RQuantLib/Rmetrics for this 
project and contribute to them. Throw in the chance RiskMap/StatPro would 
join the effort open-sourcing its asset allocation code base...

Too good to be true.

ciao -- Nando