quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] swap.py woes

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

Hi all,

I was playing with the idea of making functionality akin to swap.py
available via my still-too-poor-on-features RQuantLib codelet.  Trouble is,
I can't even run swap.py reliably.  Most of the time it just seems to go
away on an endless loop. I have seen seg.faults too but I am not clueful
enough with Python to debug this.

As at least Luigi is also running Debian, could some of you please
confirm/deny whether it works for you?  Related may be the fact that I still
need to disable two of the regression tests for QL-Python during the Debian
builds.

Happy 2005,  regards,  Dirk

-- 
If you don't go with R now, you will someday.
  -- David Kane on r-sig-finance, 30 Nov 2004

[Quantlib-dev] Re: Bug#286995: quantlib-python: FTBFS: buildd stopped because of inactivity.

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

On Thu, Dec 23, 2004 at 02:52:53PM +0100, Kurt Roeckx wrote:
> Package: quantlib-python
> Version: 0.3.8-1
> Severity: serious
> 
> Hi,
> 
> The package is failing to build on a few arches (sparc, amd64 so
> far) because it seems to hang when making tests.

Ok, thanks. This time I only commented out TermStructureTest from the actual
Python script as that one hangs on i386.  SoO maybe I'll revert to what I
did up to 0.3.7 -- comment out InstrumentTest as well.  The buildd page
(i.e. http://buildd.debian.org/build.php?pkg=quantlib-python) shows that
0.3.7 built fine everywhere...

Also CCing upstream as a heads up.

Dirk

> >From the buildd log:
> python2.3 setup.py test
> running test
> running build
> running build_py
> running build_ext
> testing QuantLib 0.3.8
> Testing date arithmetics ... ok
> Testing observability of stocks ... make: *** [test-stamp] Terminated
> Build killed with signal 15 after 150 minutes of inactivity
> 
> python2.3 is using all available cpu during that time.
> 
> It seems to be stuck doing this:
> futex(0x73b4d8, FUTEX_WAIT, 2, NULL)    = -1 EAGAIN (Resource temporarily unavailable)
> futex(0x73b4d8, FUTEX_WAIT, 2, NULL)    = -1 EAGAIN (Resource temporarily unavailable)
> 
> Attached gdb doesn't seem to be very helpful.  A backtrace looks
> like this:
> #0  0x0000002a95782744 in __lll_mutex_lock_wait () from
> /lib/libpthread.so.0
> #1  0x000000000073b4d8 in ?? ()
> #2  0x000000000080c200 in ?? ()
> #3  0x0000002a9577f971 in pthread_mutex_lock () from
> /lib/libpthread.so.0
> #4  0x00000000005d2ae0 in PyDictIter_Type ()
> #5  0x0000002a96d72c90 in ?? ()
> #6  0x0000000000000000 in ?? ()
> #7  0x000000000041ca24 in PyMethod_Fini ()
> #8  0x0000002a96dde980 in ?? ()
> #9  0x0000002a96dde9d0 in ?? ()
> #10 0x00000000006142d0 in ?? ()
> #11 0x0000000000000000 in ?? ()
> #12 0x000000000069f7c0 in ?? ()
> #13 0x000000000069f7a8 in ?? ()
> #14 0x0000000000000000 in ?? ()
> #15 0x0000002a96d72c90 in ?? ()
> #16 0x0000000000000000 in ?? ()
> #17 0x0000000000000000 in ?? ()
> ...
> #95 0x000000000048e208 in PyRun_SimpleFileExFlags ()
> #96 0x000000000040fd7a in Py_Main ()
> #97 0x0000002a95c363c1 in __libc_start_main () from /lib/libc.so.6
> #98 0x000000000040f7ea in _start ()
> #99 0x0000007fbffffb48 in ?? ()
> #100 0x0000000000000000 in ?? ()
> [...]
> #249 0x00332e326e6f6874 in ?? ()
> #250 0x0000000000000000 in ?? ()
> Cannot access memory at address 0x7fc0000000
> 
> 
> 
> Kurt
> 

-- 
If you don't go with R now, you will someday.
  -- David Kane on r-sig-finance, 30 Nov 2004

Re: [Quantlib-dev] Re: Bug#266454: quantlib: FTBFS with gcc-3.4: 'this->' missing

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

On Thu, Aug 19, 2004 at 01:21:48PM +0200, Ferdinando Ametrano wrote:
> Andreas, Dirk,
> 
> thank you for the patch.
> 
> This has been really a timely patch as I had few email exchanges yesterday 
> with Luigi, about MS VC7 not compiling QuantLib with "Language extensions" 
> disabled. Luigi replied that if gcc do compile QuantLib, then it was safe 
> to assume that the code was standard-compliant. So gcc 3.4 is welcome :)
> 
> Many (maybe all) the problems I had are solved with this patch.
> 
> Luigi today is away, I will wait and synch with him to apply the patch.

QuantLib 0.3.8 has been released, and uploaded to Debian, earlier today, so
we can finally close this bug.

Thanks again to Andreas for the report, and patch.

Dirk

> 
> ciao -- Nando
> 
> At 03:03 AM 8/18/2004, Dirk Eddelbuettel wrote:
> 
> >Andreas,
> >
> >        Thanks for the detailed bug report and patch.  I think I won't make
> >a new release quite yet given how gcc / g++ 3.3 are still the default -- 
> >and
> >QuantLib may have a 0.3.8 release before we switch to 3.4.
> >
> >QuantLib crew,
> >
> >        Haven't checked with CVS whether this is already in the sources; if
> >it isn't this may make a nice addition.
> >
> >Cheers,  Dirk
> >
> >On Wed, Aug 18, 2004 at 12:28:16AM +0200, Andreas Jochens wrote:
> >> Package: quantlib
> >> Severity: normal
> >> Tags: patch
> >>
> >> With the attached patch 'quantlib' can be compiled using gcc-3.4.
> >>
> >> Regards
> >> Andreas Jochens
> 
> 

-- 
If you don't go with R now, you will someday.
  -- David Kane on r-sig-finance, 30 Nov 2004

[Quantlib-dev] ObjectHandler and QuantLibAddin (and QuantLibXL)

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

Hi Eric

lately I haven't had time enough to catch up with your 
ObjectHandler/QuantLibAddin development. I didn't have time to update 
QuantLibXL for the 0.3.8 release, too.
I plan to catch up on both issues in January.

What would be your preferences for ObjectHandler/QuantLibAddin? Would it be 
ok to plan for its first release? Could we have a January 0.3.8 release for 
both QuantLibXL and QuantLibAddin?
[My opinion is that QuantLibAddin should replace QuantLibXL in the medium 
term.]
We might even have an global 0.3.9 release in January

Are http://www.quantlib.org/quep/quep011.html and 
http://www.quantlib.org/quep/quep012.html updated? Do you want me to 
announce the QuEPs before any release of ObjectHandler and QuantLibAddin?

Let me know your preferences and let's get the ball rolling.

------------
ciao -- Nando 

[Quantlib-dev] Announcing QuantLib 0.3.8

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

QuantLib is a cross-platform, free/open-source quantitative finance C++
library for modeling, pricing, trading, and risk management in real-life.

Version 0.3.8 has been released and is available for download at
<http://quantlib.org/download.shtml>.
See <http://quantlib.org/reference/history.html>
for a summary of the changes since version 0.3.7.

QuantLib depends on the Boost library (www.boost.org). You will need a
working Boost installation in order to compile and use QuantLib.
Instructions for installing Boost from sources are available at
<http://www.boost.org/more/getting_started.html>.
Pre-packaged binaries might be available from other sources. Google is
your friend (or Debian, or Fink...)

Python, Ruby, Guile, and MzScheme bindings are available for QuantLib
0.3.8. The Excel add-in will follow in January. Instructions for download 
are at
<http://quantlib.org/download.shtml>.

Please log any problems you have with this release in the SourceForge
bug tracker at
<http://sourceforge.net/tracker/?group_id=12740&atid=112740>
specifying that you're using QuantLib 0.3.8.

         The QuantLib group

Re: [Quantlib-dev] Test case failures on OSX

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

Hi Mark,
	thanks for checking this.

On 2004.12.11 00:34, Mark Treiber wrote:
> I've finally been able to get around to testing the one of the 0.3.8
> gm releases and I had two test case failures on OSX.  I wanted to
> check to see if others are getting the same failures on other
> platforms or not before investigating further.

No, that's the first I heard of such failures. As far as I know, a number =20
of compilers on Windows and gcc on Debian x86 all pass the check.

> One of the failures seems to be a precision based failure (this was the =20
> case for a test case failure in 0.3.6 that was fixed)

What was the fix?

> but the other one seems universal.  The test case output is below.

[snip]

Hmm, I might have a suspect. Can you try the attached patch on ql/Patterns/=
=20
singleton.hpp and see if this fixes the problem?

Later,
	Luigi

[Quantlib-dev] Test case failures on OSX

[Mark T. <mtr...@gm...>]

I've finally been able to get around to testing the one of the 0.3.8
gm releases and I had two test case failures on OSX.  I wanted to
check to see if others are getting the same failures on other
platforms or not before investigating further.  One of the failures
seems to be a precision based failure (this was the case for a test
case failure in 0.3.6 that was fixed) but the other one seems
universal.  The test case output is below.

Running 172 test cases...
bonds.cpp(182): fatal error in "BondTest::testCachedYield": failed to
reproduce cached price:
    calculated: 99.223769
    expected:   99.204505
    error:      0.019264
Exception in "CapFloorTest::testCachedValue": std::exception: 
indexmanager.cpp:30: In function `const QuantLib::History&
QuantLib::IndexManager::getHistory(const std::string&) const':
Euribor6m act/360 history not loaded
Exception in "MoneyTest::testBaseCurrency": std::exception: 
exchangeratemanager.cpp:170: In function `QuantLib::ExchangeRate
QuantLib::ExchangeRateManager::smartLookup(const QuantLib::Currency&,
const QuantLib::Currency&, const QuantLib::Date&, std::list<Integer,
std::allocator<Integer> >) const':
no conversion available from GBP to EUR for December 10th, 2004
Exception in "MoneyTest::testAutomated": std::exception: 
exchangeratemanager.cpp:170: In function `QuantLib::ExchangeRate
QuantLib::ExchangeRateManager::smartLookup(const QuantLib::Currency&,
const QuantLib::Currency&, const QuantLib::Date&, std::list<Integer,
std::allocator<Integer> >) const':
no conversion available from EUR to GBP for December 10th, 2004
piecewiseflatforward.cpp(228): fatal error in
"PiecewiseFlatForwardTest::testObservability": Observer was not
notified of date change
Exception in "SwapTest::testCachedValue": std::exception: 
indexmanager.cpp:30: In function `const QuantLib::History&
QuantLib::IndexManager::getHistory(const std::string&) const':
Euribor6m act/360 history not loaded

These were all run with the Dec 9 gm source dist.

Mark.

[Quantlib-dev] QuantLib Forums

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

Hi all

I've just flagged the Forum feature on for the QuantLib project.

I think that Forum might be useful at least for thread like "QuantLib 0.3.8 
released"

ciao -- Nando

[Quantlib-dev] QuantLib-dev is now a public list

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

Ashish Kulkarni wrote:

> > I would also subscribe you to the mailing list quantlib-dev: should I
> > add ash...@ic... or a different address?
> >
>
>I wasn't aware of the quantlib-dev mailing list: it's not mentioned on
>the website, and after reading the archives I would agree with you that
>it should be opened up.

I've just opened it up as a welcome gift ;-)

>  Could you please add me to both the dev and cvs
>lists with the address as...@ie...?
done

welcome

ciao -- Nando

[Quantlib-dev] [ quantlib-Bugs-1058472 ] How does Euro option Black Scholes support imminent option?

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

Bugs item #1058472, was opened at 2004-11-02 00:18
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1058472&group_id=12740

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: How does Euro option Black Scholes support imminent option?

Initial Comment:
This may be a documentation bug (insufficient info to
figure this out) or something just missing in the
interface, but I am trying to use the European Option
Black Scholes calculation to figure out an option less
than a month away.  Can this be done, and if so, how?

Thanks,
rf...@gr...

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2004-11-04 13:34

Message:
Logged In: YES 
user_id=75450

The issue was moved to the mailing list.

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

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

Re: [Quantlib-dev] QuEP 11: Object Handler

[eric <er...@eh...>]

Hello

No problem, I'll do both of these.

Regards
Eric

On Wed, 2004-11-03 at 17:41, Ferdinando Ametrano wrote:
> Hi Eric
> 
> a couple of observations referring to 
> http://www.ehlers.plus.com/quantlib/quep011.html:
> 
> 2.2) do you plan to add the widget example to the ObjectHandler module code 
> base? QuantLibAddin is an ObjectHandler usage example, but to have a stand 
> alone example for the standalone ObjectHandler module would be nice.
> 
> 3.1) isn't the singleton pattern the most natural way to replace the global 
> variable approach? We have code for the singleton pattern in QuantLib, it's 
> just an hpp file. I would avoid unnecessary QuantLib dependencies and 
> duplicate that file in the ObjectHandler  code base, unless anybody 
> suggests a more elegant solution
> 
> 
> ------------
> ciao -- Nando 

[Quantlib-dev] QuEP 11: Object Handler

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

Hi Eric

a couple of observations referring to 
http://www.ehlers.plus.com/quantlib/quep011.html:

2.2) do you plan to add the widget example to the ObjectHandler module code 
base? QuantLibAddin is an ObjectHandler usage example, but to have a stand 
alone example for the standalone ObjectHandler module would be nice.

3.1) isn't the singleton pattern the most natural way to replace the global 
variable approach? We have code for the singleton pattern in QuantLib, it's 
just an hpp file. I would avoid unnecessary QuantLib dependencies and 
duplicate that file in the ObjectHandler  code base, unless anybody 
suggests a more elegant solution


------------
ciao -- Nando 

[Quantlib-dev] [ quantlib-Patches-1057148 ] This is an autogen.sh file

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

Patches item #1057148, was opened at 2004-10-30 04:05
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1057148&group_id=12740

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: This is an autogen.sh file

Initial Comment:
This is an autogen.sh file which simplies the build from
CVS

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2004-11-03 15:43

Message:
Logged In: YES 
user_id=75450


The script contains unedited references to libxml. This raises 
the suspicion that the code is copyrighted.

The 'bootstrap' script in the repository can be renamed to 
autogen.sh if this is the common practice.


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

Comment By: Luigi Ballabio (lballabio)
Date: 2004-11-03 15:43

Message:
Logged In: YES 
user_id=75450

Unfortunately, we are forced to reject anonymous contributions.
Contributing anonymously makes it impossible to verify and/or 
properly attribute the copyright of the code.


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

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

Re: [Quantlib-dev] Re: ObjectHandler, QuantLibAddin, and QuEPs

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

At 12:36 AM 11/1/2004, eric wrote:
>Unfortunately as I don't have
>Borland and VC7 I'll break these every time I add files etc.,

don't worry about that. I'll catch up as soon as I can. I've just committed 
fixes for Borland, VC7, and Dev-C++


>I've just
>attempted to commit a load of changes to cvs, I'm not sure if they've
>gone through.

They've gone through

I will check later your proposal about the automatic generation of addin 
source code. Anyway for what I am concerned I could summarize this way: go 
ahead...

ciao -- Nando

PS Eric and Jody are now QuantLib-dev subscribers 

[Quantlib-dev] QuantLibAddin automatic generation

[eric <er...@eh...>]

Jody/Nando/all

Please let me know if you have any concerns with the proposed approach
for automatic generation of addin source code as I'm starting work on
this.

http://www.ehlers.plus.com/quantlib/quep012.html

The main issue is a change in the QuantLibAddin design to facilitate
autogeneration of code.  In the current prototype each function is
implemented from scratch in each addin on each platform.  Under the
proposed new design the functions are implemented once in a core library
(the "interface"), with each addin just providing a platform specific
wrapper for the core functions.

Jody, would you be willing to provide sample metadata for a Gnumeric
function?  If so I'll add this to the design doc and incorporate it into
my work.

I plan to tackle the work in 2 phases:
1) Remove the QuantLibAddin functions from the individual addins into
the central library.  This will result in QuantLibAddin still written by
hand but with the same structure as the proposed autogenerated final
product.
2) Get the autogeneration of code working for the existing 3 functions
in the prototype, for the existing platforms (C++, Excel and Calc) plus
a new addin in C to facilitate the Gnumeric work to be done in
collaboration with Jody.

Regards
Eric

[Quantlib-dev] [ quantlib-Bugs-1058472 ] How does Euro option Black Scholes support imminent option?

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

Bugs item #1058472, was opened at 2004-11-01 15:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1058472&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: How does Euro option Black Scholes support imminent option?

Initial Comment:
This may be a documentation bug (insufficient info to
figure this out) or something just missing in the
interface, but I am trying to use the European Option
Black Scholes calculation to figure out an option less
than a month away.  Can this be done, and if so, how?

Thanks,
rf...@gr...

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

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

[Quantlib-dev] Re: ObjectHandler, QuantLibAddin, and QuEPs

[eric <er...@eh...>]

> I've imported ObjectHandler as a separate module in the CVS. In order to 
> reflect this change we could split the QuEP you've submitted into two 
> separate QuEPs, one dedicated to ObjectHandler and the other to the rest.

Here are the revised docs:
http://www.ehlers.plus.com/quantlib/quep011.html
http://www.ehlers.plus.com/quantlib/quep012.html

The latter proposes an approach for automatic generation of source
code.  The doc needs further revision but should be enough to get our
discussion started.

> I've added Borland, VC7, and Dev-C++MinGW support and/or project files for 
> ObjectHandler. I've added the copyright notice (please confirm that I've 
> spelled your name right) plus a couple of minor files and fixes.

Great, and yes you got my name right.  Unfortunately as I don't have
Borland and VC7 I'll break these every time I add files etc., maybe it
will be easier for you to leave them, and fix them once last thing
before the release?

> It look like your ObjectHandler prototype is almost ready for a first 
> release. I might have introduced some problems with the *nix Makefile, but 
> you can check it out and fix them. Hopefully we could autoconf the project 
> before the release, add some Doxygen documentation, and I would provide a 
> Win32 installer.

OK, I'm happy to do the autoconf & documentation.  I'll fix all *nix
makefiles.

> I've already granted you write access to the CVS, so please use the CVS 
> code base for any further development. When we'll publish the QuEPs we will 
> be referring to QuantLib 0.3.8, and the latest version of your code will be 
> available in the CVS for public inspections.

I'll edit the final drafts of the docs to refer to 0.3.8.  I've just
attempted to commit a load of changes to cvs, I'm not sure if they've
gone through.

> BTW I'm going to add er...@eh... to the QuantLib-dev mailing list. 
> Is it ok for you? Would you prefer a different address?

That address is fine, thank you.

> How are you managing the QuantLib-cvs traffic ? ;-)

The team certainly does keep busy :)

Regards
Eric

[Quantlib-dev] [ quantlib-Patches-1057148 ] This is an autogen.sh file

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

Patches item #1057148, was opened at 2004-10-29 19:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1057148&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: This is an autogen.sh file

Initial Comment:
This is an autogen.sh file which simplies the build from
CVS

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

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

[Quantlib-dev] Re: ObjectHandler, QuantLibAddin, and QuEPs

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

Hi all

Jody Goldberg wrote:
>I'm definitely already on some of the quantlib lists, possibly not
>that one please add me.
I've added you and Eric to quantlib-dev

>Gnumeric already has a significant set of financial analytics,
>and I'd like to see that expanded to use quantlib.
this is great news.

>IDL is a non-starter.  It is nowhere near reach enough to supply the
>amount of documentation and detail to generate the code I'd like to
>see.  A config_file and some sort of script, possibly in python
>seems like a reasonable approach.  I've seen it used successfully in
>things like pygtk and gtk#.
I definitively trust you on such an issue.

>   By defining the api using a format we
>control it's possible to get all the relevent information.
>Something as simple as an xml based format would be fine.  The goal
>is to provide things like
>     - name
>     - short func description
>     - per argument name, description, type
>     - Return type
>     - long func description (algorithm, model, possible a url to
>       more docs)
>     - implementation status
>     - testing status
>     - version info (eg first created in QL v?)
>     - Related functions
>     - Possibly a ChangeLog ?
>     - Translations ?
>     - Keywords/Categories to classify function
>     - Samples/Examples
>     - Related functions
I agree with everything but translations. Not that we have to forbid them, 
but imho the financial community doesn't really need them.

Eric wrote:
>I'll send more specific comments on Monday,
>as well as a split QuEP11(/12?) and a draft
>design for the automatic generation of code
I look forward to it.

ciao -- Nando 

[Quantlib-dev] Re: ObjectHandler, QuantLibAddin, and QuEPs

[Jody G. <jo...@gn...>]

On Wed, Oct 27, 2004 at 06:18:49PM +0200, Ferdinando Ametrano wrote:
>
> Are you > interested in joining the QuantLib-dev mailing list?
I'm definitely already on some of the quantlib lists, possibly not
that one please add me.

> Do you plan to personally contribute to the Gnumeric version of
> the QuantLibAddin?
yes.  Gnumeric already has a significant set of financial analytics,
and I'd like to see that expanded to use quantlib.
 
> >What do you think about the autogeneration of code described under
> >"Notes"?  Jody and I agree that autogeneration is the way forward, if
> >you agree I'll do a design doc for that.
> I do agree that autogeneration is the way forward. I'm not sure 
> Python+config_file is the best approach, but I'm not an expert. What about 
> IDL definition and IDL compilers?

IDL is a non-starter.  It is nowhere near reach enough to supply the
amount of documentation and detail to generate the code I'd like to
see.  A config_file and some sort of script, possibly in python
seems like a reasonable approach.  I've seen it used successfully in
things like pygtk and gtk#.  By defining the api using a format we
control it's possible to get all the relevent information.
Something as simple as an xml based format would be fine.  The goal
is to provide things like
    - name
    - short func description
    - per argument name, description, type
    - Return type
    - long func description (algorithm, model, possible a url to
      more docs)
    - implementation status
    - testing status
    - version info (eg first created in QL v?)
    - Related functions
    - Possibly a ChangeLog ?
    - Translations ?
    - Keywords/Categories to classify function
    - Samples/Examples
    - Related functions

With that type of information a spreadsheet can provide a decent
interface for selecting a routine.  Gnumeric has on the order of
500+ functions right now.  That's everything in north american MS
Excel and 150 or extra.  Navigating through that is cumbersome.

[Quantlib-dev] Re: ObjectHandler, QuantLibAddin, and QuEPs

[eric <er...@eh...>]

Hi Nando, Hi All

Just a quick message as I'm running to catch a train.  In general I
agree with all of your points and I'll send more specific comments on
Monday, as well as a split QuEP11(/12?) and a draft design for the
automatic generation of code - I'll look at IDL.

Many thanks for your help, speak to you soon.

Regards
Eric


On Wed, 2004-10-27 at 17:18, Ferdinando Ametrano wrote:
> Hi Eric,
> 
> [I'm CCing QuantLib-dev and Jody Goldberg]
> 
> I've imported ObjectHandler as a separate module in the CVS. In order to 
> reflect this change we could split the QuEP you've submitted into two 
> separate QuEPs, one dedicated to ObjectHandler and the other to the rest.
> 
> I've added Borland, VC7, and Dev-C++MinGW support and/or project files for 
> ObjectHandler. I've added the copyright notice (please confirm that I've 
> spelled your name right) plus a couple of minor files and fixes.
> 
> It look like your ObjectHandler prototype is almost ready for a first 
> release. I might have introduced some problems with the *nix Makefile, but 
> you can check it out and fix them. Hopefully we could autoconf the project 
> before the release, add some Doxygen documentation, and I would provide a 
> Win32 installer.
> 
> As for the rest: I've renamed your ObjectClassLibrary as QuantLibAddin. The 
> CVS QuantLibAddin module includes the QuantLibAddin library plus all the 
> Addins and Clients (C++, Calc, and Excel). I've added Borland, VC7, and 
> Dev-C++MinGW (partial) support and/or project files, (some) copyright 
> notice, and some minor files and fixes. The code is updated to work with 
> the forthcoming 0.3.8 release and the current CVS trunk.
> Once again I might have introduced some problems with the *nix Makefiles: 
> please check them.
> 
> I've already granted you write access to the CVS, so please use the CVS 
> code base for any further development. When we'll publish the QuEPs we will 
> be referring to QuantLib 0.3.8, and the latest version of your code will be 
> available in the CVS for public inspections.
> 
> BTW I'm going to add er...@eh... to the QuantLib-dev mailing list. 
> Is it ok for you? Would you prefer a different address?
> How are you managing the QuantLib-cvs traffic ? ;-)
> 
> Jody: thank you for any help you can provide for Gnumeric. Are you 
> interested in joining the QuantLib-dev mailing list? Do you plan to 
> personally contribute to the Gnumeric version of the QuantLibAddin?
> 
> >What do you think about the autogeneration of code described under
> >"Notes"?  Jody and I agree that autogeneration is the way forward, if
> >you agree I'll do a design doc for that.
> I do agree that autogeneration is the way forward. I'm not sure 
> Python+config_file is the best approach, but I'm not an expert. What about 
> IDL definition and IDL compilers?
> 
> thank you very much for your contribution
> 
> ciao -- Nando
> 
> 
> Eric wrote:
> >I've revised the design doc, and the URL has changed:
> >
> >http://www.ehlers.plus.com/quantlib/quep011.html
> >
> >Here are the html and other files:
> >http://www.ehlers.plus.com/quantlib/quep011.zip
> >http://www.ehlers.plus.com/quantlib/quep011.tar.gz
> >
> >Please let me know if any revisions are needed.  You're welcome to edit
> >the doc directly if that's easier for you.
> >
> >Here's the code:
> >http://www.ehlers.plus.com/quantlib/ObjectHandler.zip
> >http://www.ehlers.plus.com/quantlib/ObjectHandler.tar.gz
> >
> >I'm new to QuantLib and Boost and I'm sure the code has much room for
> >improvement - all feedback is welcome.
> >
> >Regards
> >Eric

[Quantlib-dev] ObjectHandler, QuantLibAddin, and QuEPs

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

Hi Eric,

[I'm CCing QuantLib-dev and Jody Goldberg]

I've imported ObjectHandler as a separate module in the CVS. In order to 
reflect this change we could split the QuEP you've submitted into two 
separate QuEPs, one dedicated to ObjectHandler and the other to the rest.

I've added Borland, VC7, and Dev-C++MinGW support and/or project files for 
ObjectHandler. I've added the copyright notice (please confirm that I've 
spelled your name right) plus a couple of minor files and fixes.

It look like your ObjectHandler prototype is almost ready for a first 
release. I might have introduced some problems with the *nix Makefile, but 
you can check it out and fix them. Hopefully we could autoconf the project 
before the release, add some Doxygen documentation, and I would provide a 
Win32 installer.

As for the rest: I've renamed your ObjectClassLibrary as QuantLibAddin. The 
CVS QuantLibAddin module includes the QuantLibAddin library plus all the 
Addins and Clients (C++, Calc, and Excel). I've added Borland, VC7, and 
Dev-C++MinGW (partial) support and/or project files, (some) copyright 
notice, and some minor files and fixes. The code is updated to work with 
the forthcoming 0.3.8 release and the current CVS trunk.
Once again I might have introduced some problems with the *nix Makefiles: 
please check them.

I've already granted you write access to the CVS, so please use the CVS 
code base for any further development. When we'll publish the QuEPs we will 
be referring to QuantLib 0.3.8, and the latest version of your code will be 
available in the CVS for public inspections.

BTW I'm going to add er...@eh... to the QuantLib-dev mailing list. 
Is it ok for you? Would you prefer a different address?
How are you managing the QuantLib-cvs traffic ? ;-)

Jody: thank you for any help you can provide for Gnumeric. Are you 
interested in joining the QuantLib-dev mailing list? Do you plan to 
personally contribute to the Gnumeric version of the QuantLibAddin?

>What do you think about the autogeneration of code described under
>"Notes"?  Jody and I agree that autogeneration is the way forward, if
>you agree I'll do a design doc for that.
I do agree that autogeneration is the way forward. I'm not sure 
Python+config_file is the best approach, but I'm not an expert. What about 
IDL definition and IDL compilers?

thank you very much for your contribution

ciao -- Nando


Eric wrote:
>I've revised the design doc, and the URL has changed:
>
>http://www.ehlers.plus.com/quantlib/quep011.html
>
>Here are the html and other files:
>http://www.ehlers.plus.com/quantlib/quep011.zip
>http://www.ehlers.plus.com/quantlib/quep011.tar.gz
>
>Please let me know if any revisions are needed.  You're welcome to edit
>the doc directly if that's easier for you.
>
>Here's the code:
>http://www.ehlers.plus.com/quantlib/ObjectHandler.zip
>http://www.ehlers.plus.com/quantlib/ObjectHandler.tar.gz
>
>I'm new to QuantLib and Boost and I'm sure the code has much room for
>improvement - all feedback is welcome.
>
>Regards
>Eric

[Quantlib-dev] 0.3.8 branch and tarballs

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

Hi all,
	I just created a CVS branch for the 0.3.8 release with tag =20
'R000308f0-branch'. You're all invited to check it out and verify that it =20
compiles and runs correctly on your system. Do not commit new code on the =20
branch--only bug fixes and such.

Tentative tarballs for the release are also available at
<http://quantlib.org/gm/>. Packagers can try and work their magic to see =20
that they're in working order--however, note that they're not final.

Later,
	Luigi

[Quantlib-dev] CompoundForward and ExtendedDiscount classes

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

Hi Andre

in the last days I've refactored and cleaned up the YieldTermStructure 
interface, using the new InterestRate class. I haven't finished yet but the 
current code can be checked out from the CVS trunk.

Now I have problems figuring out what CompoundForward and ExtendedDiscount 
classes are exactly meant for. My guess is the new YieldTermStructure 
interface probably makes them obsolete, as interest rate conventions 
(daycount, compounding, etc) are dealt with in the base class.
What is probably left are their constructors which I would support if you 
could describe/document them.

As soon as this issue is solved we would start the 0.3.8 release process.

thank you

ciao -- Nando

PS Luigi: this issue and the flat curve daycount issue, of course

[Quantlib-dev] [ quantlib-Patches-1035879 ] Changing Xibor to index in indexed coupon

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

Patches item #1035879, was opened at 2004-09-28 04:34
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1035879&group_id=12740

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Daniele De Francesco (qq7te)
Assigned to: Luigi Ballabio (lballabio)
Summary: Changing Xibor to index in indexed coupon

Initial Comment:
Hi, 

I had promised a while ago that I would send in this
patch so that IndexedCoupon would only be required to
take an Index and not necessarily a Xibor. 

All the changes seem to work in our set up, compiling
with VC 7.1 on windows. 

-Daniele

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

Comment By: Luigi Ballabio (lballabio)
Date: 2004-09-30 17:21

Message:
Logged In: YES 
user_id=75450

The patch was applied to the code in the cvs repository.
It will be included in next release.
Thank you.


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

Comment By: Luigi Ballabio (lballabio)
Date: 2004-09-29 09:51

Message:
Logged In: YES 
user_id=75450

Daniele,
    thanks. I'll apply the patch to the repository as soon
as I get the chance.

Later,
    Luigi


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

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