quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Visual C++ configurations

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

Hi all,
	I've just answered a poor soul on quantlib-users that asked about the  
difference between the various VC++ configurations we've defined. A  
few thoughts:

First: the nomenclature is cryptic. It's not obvious that CRTDLL  
stands for "common runtime dll." We should clarify the names.

Second, and perhaps most important: there's a mismatch between what we  
call release and what the default is for VC++ projects. If one asks  
for a new project, VC++ creates one with a Debug and a Release  
configuration. Unfortunately, they don't correspond to what we call  
release. If a user has compiled QuantLib in Release mode and tries to  
link it to its new application, he'll have an unexpected linking  
error.  What VC++ 7 calls "Release" is what we call "Release  
SingleThread"; what VC++ 8 and 9 calls "Release" is what we call  
"Release CRTDLL".

Needless to say, I'd like to fix this in future releases. For VC++ 8  
and 9, I'd call "Release" the default configuration (crtdll) and  
something like "Release (static runtime)" the current Release. Well,  
actually, I'm not even sure that I'd leave multiple configurations  
instead of just Debug/Release; on the one hand, they're confusing for  
most users, and on the other hand, a user that needs a particular  
runtime is likely to know what settings to change to obtain it. We can  
talk about this; at the very least, I'd switch the names.

For VC++ 7, I'm not so sure. For uniformity, I'd call Release what VC+ 
+ calls Release, i.e., the single-thread configuration. But doing so,  
we'd lose uniformity between VC++ versions; and I'm also concerned  
about QuantLibXL---Eric, does it support single-thread mode, or does  
it require the multi-threaded runtime? If the latter, we might want to  
use the crtdll configuration as default.

Thought anyone?

Later,
	Luigi

Re: [Quantlib-dev] Could someone post or e-mail an example of yield calculation of a fixed rate coupon bond?

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

On Aug 28, 2008, at 11:14 AM, Florent Grenier wrote:
> Yes good idea, I'll do it as soon as I can. Just a small question:  
> do you already know when the next release will take place? I would  
> like to bring my modifications to the example before that release.

I'd like to finalize the release by the end of September (see the mail  
i just posted to QuantLib-users for details.)

Luigi

[Quantlib-dev] [ quantlib-Feature Requests-1941916 ] Asian Average Strike Option

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

Feature Requests item #1941916, was opened at 2008-04-14 12:19
Message generated for change (Comment added) made by aspengler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=1941916&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: abhishek Srivastava (abhiabhi001)
Assigned to: Nobody/Anonymous (nobody)
Summary: Asian Average Strike Option

Initial Comment:
Hi

in the instrument list "Asian Average Strike Option" is not avaialable.

Thanks
Abhishek

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

Comment By: Andreas Spengler (aspengler)
Date: 2008-09-03 20:28

Message:
Logged In: YES 
user_id=437086
Originator: NO

Hi,

I recently implemented an Asian Option on the basis of "moment matching".
As part of getting to know QuantLib, I would be willing to code this, if
the methodology is reasonable for you...

Rgds,

Andreas

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

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

[Quantlib-dev] [ quantlib-Bugs-2091327 ] Legendre basis system is missing

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

Bugs item #2091327, was opened at 2008-09-03 17:17
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=2091327&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mustapha MARCHOUD (marcmus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Legendre basis system is missing

Initial Comment:
The Legendre polynomial as basis system is missing in the Monte Carlo American engine even if its implementation was provided.

Suggested solution : 
Add the test for Legendre basis system in the QL_REQUIRE statement inside the constrcutor  AmericanPathPricer::AmericanPathPricer (file : MCAmericanEngine.cpp)

Best regards,

ma...@gm...



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

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

Re: [Quantlib-dev] Some questions about forcing recalculation

[Eric E. <eri...@na...>]

Hi Andrew,

On Thu, August 28, 2008 10:59, a.p. wrote:
> About your example:
>
> "the object can be identified by the raw (literal) string "my_obj" - not
> "my_obj#001" and not a reference to the range in the closed Book1.xls from
> which the object was constructed"
>
> - that's the way i work with QLXL functions, but when the object is updated
> (by user or by external data), how could we force recalculation of
> dependency functions (such as qlYieldTSZeroRate, etc.)?!

My earlier advice to close the workbook in which "my_obj" resides, that was
given on the assumption that "my_obj" can be created just once at startup.

You say that "my_obj" is recreated frequently and these updates must trigger a
recalculation of dependent objects.  In that case, you could use this
approach: Ensure that the book in which "my_obj" is created remains open.  All
objects which depend on "my_obj" refer to it using an Excel range reference to
its cell (and not the raw string "my_obj").  Any time "my_obj" is recreated,
Excel recalculates its dependents.

> You see, Excel
> recalculates UDF only in case of arguments change, but all arguments are
> still the same (so if you hit F9 nothing will be changed)!

Not exactly.  Suppose Range B depends on Range A.  If A's inputs change, Excel
is smart enough to recalculate B, even if A's return value is unchanged.  In
the scenario I describe above, A's return value would in fact change on each
recalculation, as the update counter is incremented - my_obj#0000,
my_obj#0001, etc.  But even without that, B is still recalculated.  If you set
calculation to automatic then you don't even need to hit F9.

> One way to solve
> this problem - to use trigger parameter, but itsn't convinient (see my
> previous topic). So, are there another decisions?

In the approach I describe above, in which the dependents of my_obj use Excel
range references to refer directly to its cell, no trigger parameters are
required.

ObjectHandler 0.9.6 includes an enhancement that also solves this problem. 
The enhancement ensures that all object references are up to date.  Suppose
Object B depends on Object A.  Any time Object B is retrieved, OH checks
whether B is newer then A, if not, OH recreates B before returning it to the
user.

What is the class of your "my_obj"?  I have never witnessed a use case like
the one you describe.  Typically when an object is required globally, it is
something such as a term structure which can be created just once when the
application is initialized, and thereafter updated non-destructively.  If an
object is being recreated frequently, particularly in response to user input,
it is usually something with few or no dependents such as an instrument, and
all of the user-editable inputs are local to the worksheet on which the object
resides.

Regards,
Eric

-------------------------
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
Distributed computing for pricing analytics - Use Microsoft Excel as a client
to the Grid

Re: [Quantlib-dev] default.hpp

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

On Fri, 2008-08-29 at 09:57 +0100, Simon Ibbotson wrote:
> The file ql/default.hpp does not compile under Sun Solaris (g++
> compiler). [...]
> The following lines need to be included (or the enumeration value
> changed) at the top of the file.
> 
> #ifdef SEC
> #undef SEC
> #endif

Done, thanks.

Luigi



-- 

Grabel's Law: 
2 is not equal to 3 -- not even for large values of 2. 

[Quantlib-dev] Generic date offset.

[Simon I. <s.i...@gm...>]

Hi folks,

I've been looking around in QuantLib and cannot find a generic DateOffset
class.
At present - when calculating the spot date, ex-div date or even just the
next date in a sequence - there are many different ways of doing this.

1) Use a Calendar, a Period and a BusinessDayConvention.
2) Use a Calendar and a fixed number of business days.
3) Use a fixed number of calendar days.
4) Use a specified Date.

I know that (2) and (3) can be replicated in (1), but there is a
proliferation of interfaces already in QuantLib. For instance, the parameter
"Natural settlementDays" is common, as is "Date settlementDate".

Also, what if the rules to create a date are not predictable... I'm
particularly referring to calculating the spot date (particularly for FX,
where the conventions are complex) or the ex-dividend date.

In addition, there are complex rules for calculating stub periods. E.g. For
an annual period: "Long last stub, if it doesn't exceed 18 months else short
stub".

In the current setup, the instrument needs to know the rules for calculating
these dates - rather than delegating them to a specific class.

Why isn't there a generic (base?) class for this type of functionality? I'm
guessing there is a reason, but it isn't obvious.

Cheers,

Simon

[Quantlib-dev] [ quantlib-Patches-2076218 ] Period::frequency() changed

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

Patches item #2076218, was opened at 2008-08-26 18:16
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=2076218&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Slava Mazur (shlagbaum)
>Assigned to: Luigi Ballabio (lballabio)
Summary: Period::frequency() changed

Initial Comment:
Handling of week and day time units has changed in Period::frequency(). No exception is thrown in response to incorrect input. NoFrequency is returned instead. The acceptable range of lengths is widen for week and day time units: weeks - 1,2,4,13,26,52; days - 1,7,14,91,182,365.


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

>Comment By: Luigi Ballabio (lballabio)
Date: 2008-09-02 11:55

Message:
Logged In: YES 
user_id=75450
Originator: NO

The modifications:
1) Instead of using NoFrequency, a further enum (OtherFrequency) was
added. This specifies some unknown but regular frequency, while NoFrequency
stands for no frequency at all.
2) The known range of lengths was not widened. I preferred to keep the
invariant that Period(Frequency(p)) either fails or returns the original p.
This would not have been the case if the acceptable lengths were increased;
for instance, Period(Frequency(26*Weeks)) would have returned 6*Months
which doesn't equal 26*Weeks.

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

Comment By: Luigi Ballabio (lballabio)
Date: 2008-09-02 11:55

Message:
Logged In: YES 
user_id=75450
Originator: NO

The patch was applied (with some modifications) to the code repository.
It will be included in next release.
Thank you.


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

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

Re: [Quantlib-dev] [Quantlib-users] Using QuantLibXL

[Eric E. <eri...@na...>]

Hi Slava,

On Mon, September 1, 2008 20:51, Slava D wrote:
> However, having checked QuantLibObjectHandler xll-s (they are not required
> for static QuantLibXL, but they are good points to check), I have noticed
> that there is an error there that "MSVCR80.dll" is not found.
>
> I believe that there are some problems with the manifest for
> QuantLibObjectHandler - I have used full rebuild (on the net there are a
> couple of ways to fix it in the right way). Some blogs on the net are
> claiming that the problems with "MSVCR80.dll" are coming when you do a full
> rebuild.

Compiled with VC8 configuration "Release CRTDLL", the XLL will have a run time
dependency on MSVCR80.dll.  Certainly if the dependency walker indicates that
that dependency is unsatisfied then it would explain the error "not a valid
add-in".  Normally if you test the XLL on the same machine on which it was
compiled then this error doesn't occur.  I have never heard of this problem
being triggered by a full rebuild.

> I will also try to use the link you sent to me for the trunk - before I was
> using
>
> http://quantlib.svn.sourceforge.net/viewvc/quantlib/
>
> there I took your files for QuantLibObjetHandler and QuantLibXL with your
> comments that you fixed static stuff.

The best is to use TortoiseSVN to check out the root directory of the
repository trunk as described in my earlier message.

> Let me try to everything again an I will let you know how things are.
>
> However, I do believe that we would converge pretty soon to something
> reasonable.
>
> thanks for you help again,

No problem, happy to help, I'm optimistic that a clean start will fix the
problem, please keep me posted.

Regards,
Eric

-------------------------
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
Distributed computing for pricing analytics - Use Microsoft Excel as a client
to the Grid

[Quantlib-dev] [ quantlib-Patches-2077710 ] Fix compile errors when using xlc on Linux

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Anton Blanchard (antonb)
>Assigned to: Luigi Ballabio (lballabio)
Summary: Fix compile errors when using xlc on Linux

Initial Comment:
quantlib fails to build when using the IBM xlc compiler on Linux. While the gcc compiler is OK, xlc complains that it cant resolve ShortRateDynamics:

class CoxIngersollRoss::Dynamics : public ShortRateDynamics {

The following patch (against latest SVN) fixes it:

    class CoxIngersollRoss::Dynamics : public OneFactorModel::ShortRateDynamics {

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

Comment By: Luigi Ballabio (lballabio)
Date: 2008-09-02 10:07

Message:
Logged In: YES 
user_id=75450
Originator: NO

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


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

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

Re: [Quantlib-dev] [Quantlib-users] Using QuantLibXL

[Slava D <sla...@go...>]

Hi Eric,

thank you very much for your e-mail.

I will try everything again.

However, having checked QuantLibObjectHandler xll-s (they are not required
for static QuantLibXL, but they are good points to check), I have noticed
that there is an error there that "MSVCR80.dll" is not found.

I believe that there are some problems with the manifest for
QuantLibObjectHandler - I have used full rebuild (on the net there are a
couple of ways to fix it in the right way). Some blogs on the net are
claiming that the problems with "MSVCR80.dll" are coming when you do a full
rebuild.

I will also try to use the link you sent to me for the trunk - before I was
using

http://quantlib.svn.sourceforge.net/viewvc/quantlib/

there I took your files for QuantLibObjetHandler and QuantLibXL with your
comments that you fixed static stuff.

Let me try to everything again an I will let you know how things are.

However, I do believe that we would converge pretty soon to something
reasonable.

thanks for you help again,

Slava


On Mon, Sep 1, 2008 at 10:54 AM, Eric Ehlers <eri...@na...>wrote:

> Hi Slava,
>
> Picking up the thread that started in quantlib-users...
>
> The error you reported initially - "QuantLibXL-vc80-MT-S-0_9_5.xll is not a
> valid add-in" - this was a known problem, which I was observing on my
> machine,
> and which was resolved by svn revision 15471.  Can we take a second to make
> sure you got the fix?
>
> On Fri, August 29, 2008 17:01, Slava D wrote:
> > Hi Eric,
> >
> > thank you very much for your attempt to help me.
> >
> > Unfortunately, it did not work -  I have downloaded the updates you made
> for
> > QuantLibObjectHandler and for QuantLibXL. I did not update QuantLibAddIn
> as
> > all its changes were quite before your changes to fix static at the
> > solutions abiove.
>
> I'm slightly confused when you talk about downloads, and about updating
> some
> projects and not others.
>
> We're working with the latest snapshot of the svn trunk.  Normally you
> would
> use Tortoise SVN to do svn checkout from
>
>    https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk
>
> To a directory on your hard drive e.g.
>
>    C:\projects\trunk
>
> The fix as I mentioned was svn revision 15471 which was applied Thursday.
>  So
> what you should now do is right click on your local root directory e.g.
> C:\projects\trunk and do svn update.  This brings your local copy of the
> trunk
> up to date, which at the time of this writing is revision 15476.
>
> You would then rebuild the solution.  For this particular fix an
> incremental
> rebuild should suffice, a full rebuild isn't required.
>
> > I am still getting the same error message:
> >
> > *Warning: At least one module has an unresolved import due to a missing
> > export function in a delay-load dependent module.*
> >
> >
> > ar MPR.dll for function WNetRestoreConnectionA.
> >
> > guys,
> >
> > Do you know how this problem is coming?
> >
> > Before I had error mesage "Missing msjava.dll".
>
> Those messages are from the dependency walker and can be ignored, see the
> FAQ
> for more info:
>
>    http://www.dependencywalker.com/faq.html
>
> More important, when you start Excel and load
> QuantLibXL-vc80-mt-s-0_9_5.xll,
> do you still get a run time error?
>
> I assume you're using the XLL on the same machine on which it was compiled?
>
> Regards,
> Eric
>
> -------------------------
> Eric Ehlers
> nazcatech sprl | Brussels | http://www.nazcatech.be
> Distributed computing for pricing analytics - Use Microsoft Excel as a
> client
> to the Grid
>
>

Re: [Quantlib-dev] QuantLibXL / ObjectHandler 0.9.6 Prerelease Files

[Eric E. <eri...@na...>]

Hi All,

Many thanks for the feedback received to date.

With regard to example workbooks, the only useful ones at present are
YieldCurveBootstrapping.xls and InterestRateDerivatives.xls.  I am aware that
many of the others are out of date.  Before the release I will fix as many of
them as possible and the others I will exclude from the release.  There is
probably no point in reporting individual errors to me and I apologize to
those who lost time on that.

On the other hand if anyone would be available to edit the books and bring
them up to date that would be of enormous help.

Regards,
Eric

On Thu, August 28, 2008 15:02, Eric Ehlers wrote:
> Hi All,
>
> The prerelease files for version 0.9.6 of QuantLibAddin, QuantLibXL,
> ObjectHandler and gensrc are available at this link:
>
> http://quantlib.org/prerelease/oh-qla.html
>
> I'd be grateful to anyone who could spare some time to test the files and let
> me know how it goes.
>
> Kind Regards,
> Eric
>
> -------------------------
> Eric Ehlers
> nazcatech sprl | Brussels | http://www.nazcatech.be
> Distributed computing for pricing analytics - Use Microsoft Excel as a client
> to the Grid
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] [Quantlib-users] Using QuantLibXL

[Eric E. <eri...@na...>]

Hi Slava,

Picking up the thread that started in quantlib-users...

The error you reported initially - "QuantLibXL-vc80-MT-S-0_9_5.xll is not a
valid add-in" - this was a known problem, which I was observing on my machine,
and which was resolved by svn revision 15471.  Can we take a second to make
sure you got the fix?

On Fri, August 29, 2008 17:01, Slava D wrote:
> Hi Eric,
>
> thank you very much for your attempt to help me.
>
> Unfortunately, it did not work -  I have downloaded the updates you made for
> QuantLibObjectHandler and for QuantLibXL. I did not update QuantLibAddIn as
> all its changes were quite before your changes to fix static at the
> solutions abiove.

I'm slightly confused when you talk about downloads, and about updating some
projects and not others.

We're working with the latest snapshot of the svn trunk.  Normally you would
use Tortoise SVN to do svn checkout from

    https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk

To a directory on your hard drive e.g.

    C:\projects\trunk

The fix as I mentioned was svn revision 15471 which was applied Thursday.  So
what you should now do is right click on your local root directory e.g.
C:\projects\trunk and do svn update.  This brings your local copy of the trunk
up to date, which at the time of this writing is revision 15476.

You would then rebuild the solution.  For this particular fix an incremental
rebuild should suffice, a full rebuild isn't required.

> I am still getting the same error message:
>
> *Warning: At least one module has an unresolved import due to a missing
> export function in a delay-load dependent module.*
>
>
> ar MPR.dll for function WNetRestoreConnectionA.
>
> guys,
>
> Do you know how this problem is coming?
>
> Before I had error mesage "Missing msjava.dll".

Those messages are from the dependency walker and can be ignored, see the FAQ
for more info:

    http://www.dependencywalker.com/faq.html

More important, when you start Excel and load QuantLibXL-vc80-mt-s-0_9_5.xll,
do you still get a run time error?

I assume you're using the XLL on the same machine on which it was compiled?

Regards,
Eric

-------------------------
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
Distributed computing for pricing analytics - Use Microsoft Excel as a client
to the Grid

[Quantlib-dev] [ quantlib-Feature Requests-2023353 ] CUDA port

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: CUDA port

Initial Comment:
Hello,

A great feature would be a CUDA port of QuantLib.
Thanks !

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

Comment By: Jose Luis San Martin (jlsanmartin)
Date: 2008-08-31 18:31

Message:
Logged In: YES 
user_id=2198063
Originator: NO

Hi All,

I'm interested in the Cuda port for QuantLib, at the moment i'm looking
for an open source project with high performance requirements. I have no
idea about quantitative finance but i have no problem with learn about it.

The first thing i need is some advice to know where to start, which module
could be easy to understand to start analyzing code to evaluate if is
possible the Cuda port.

Thanks in advance.

-- 

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

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

Re: [Quantlib-dev] STL compliant containers for XLOPER

[Slava M. <Sla...@ro...>]

Hi Eric,

>The contribution would be welcome.  I understand that you would need to
do
>some negotiating on your side, please keep me posted.  Would you be
able to
>provide a statement authorizing the release of this code under the
QuantLib
>license?  Depending on you contract and the laws in your country it may
be
>that your thoughts are the property of your employer ;) in which case
the
>statement would have to come from them.

Negotiations are still in progress. Waiting for a decision from a higher
level management. Lower level is okay.

>It would be good to get some example applications for XLL Containers,
maybe
>showing the usage of the classes with and without ObjectHandler?

I think, a good one is how QuantLibXL::operToQlArray() could be
implemented with the help of XLL array. Consider the following, more
concise and more intuitive IMHO (BTW you might want to consider passing
the second parameter by const reference):

QuantLib::Array operToQlArray(const OPER &xVector, 
   const std::string paramName) {
   try {
     xll::CellPtrConst<boost::any> pxVector(&xVector);

     OH_REQUIRE(!(pxVector->isError()), 
                "input value '" << paramName << "' has type=error");
     if (pxVector->isMissingArg() || pxVector->isNil()) {
        return QuantLib::Array();
     } else if (pxVector->isArray()) {
        xll::VectorPtrConst<double> pv(&xVector);
        QuantLib::Array a(pv->size());
        std::copy (pv->begin(), pv->end(), a.begin());
        return a;
     } else if (pxVector->isString()) {
        using namespace boost::algorithm;
        xll::VectorPtrScoped<double> pv;
 
split(*pv,(std::string)*xll::CellPtrConst<std::string>(&xVector), 
            is_any_of(",;"));
        QuantLib::Array a(pv->size());
        std::copy(pv->begin(), pv->end(), a.begin());
        return a;
     } else {
        xll::VectorPtrScopedExcel<double> pv(&xVector);
        QuantLib::Array a(pv->size());
        std::copy (pv->begin(), pv->end(), a.begin());
        return a;
     }
  } catch (const std::bad_cast &e) {
     OH_FAIL("operToVector: error converting parameter '" << paramName
<< "' : " << e.what());
  }
}

There are also several general examples in html files I sent to you
previously. Another one converts input sequence of numbers in a string
format to a double array and returns it as a range to Excel:

XLOPER * sequence2doubleArray (const char *input) {
   xll::VectorPtrWeakExcel<double> res;
   try {
      using namespace boost::algorithm;
      split(*res, input, is_any_of(",;"));
   } catch (const std::bad_cast &e) {
      res->setError();
   }
   return res;
}

>As you observe, for ObjectHandler 0.9.6, boost::any is replaced
everywhere >by
>property_t, which wraps boost::variant, because the latter is supported
>natively by boost::serialization.  I'm not sure how this change impacts
>your
>classes, which also use boost::any but in a different context.

I'm having a problem with such a design. Previously, when property value
type was boost::any and you handled OPER case as one of possible type a
property can have, I could use xll::CellPtrSharedExcel<boost::any> class
in my extension of ValueObject like the following and the function
ohPropertyValue worked correctly:

void MyValueObject::setProperty(const std::string& name, 
   const boost::any& value)
{
   iterator it = properties_.find (name);
   if (it == properties_.end())
      throw PropertyNotFound;
   if (value.type() == typeid(OPER*))
      it->second = xll::CellPtrSharedExcel<boost::any>(value);
   else
      it->second = value;
}

boost::any MyValueObject::getProperty(const std::string& name) const
{
   iterator it = properties_.find (name);
   if (it == properties_.end())
      throw PropertyNotFound;
   boost::any w = it->second;
   if (w.type() == typeid(xll::CellPtrSharedExcel<boost::any>))
      return (OPER*)boost::any_cast <
xll::CellPtrSharedExcel<boost::any> >        (w);
   else return w;
}

My idea was to propose introduction of
xll::CellPtrSharedExcel<boost::any> as one of possible property type.
This way one could avoid unneccessary casts, transformations, and
duplication of data. However, with introduction of property_t you've
actually eliminated OPER and related types from the list of possible
types a property can have.

Now I have to convert my original data from OPER to one of acceptable
property_t type and thus to create a copy of data just to satisfy more
rigid property_t requrements. Note that by nature of my projects I'm
dealing with time series data, so creating unneccessary copies is highly
undesirable.
I'm wondering is it possible to generalize property_t concept making it
a template which depends on a variable list of types?

Thanks,

Slava Mazur

[Quantlib-dev] default.hpp

[Simon I. <s.i...@gm...>]

The file ql/default.hpp does not compile under Sun Solaris (g++ compiler).
The offending line is :

    enum Seniority { SEN, SUB, SEC, TI0, TI1, PCL, AnySeniority };

This is due to the enumeration value SEC already being declared as a numeric
constant.
The following lines need to be included (or the enumeration value changed)
at the top of the file.

#ifdef SEC
#undef SEC
#endif


Cheers,

Simon

[Quantlib-dev] QuantLibXL / ObjectHandler 0.9.6 Prerelease Files

[Eric E. <eri...@na...>]

Hi All,

The prerelease files for version 0.9.6 of QuantLibAddin, QuantLibXL,
ObjectHandler and gensrc are available at this link:

http://quantlib.org/prerelease/oh-qla.html

I'd be grateful to anyone who could spare some time to test the files and let
me know how it goes.

Kind Regards,
Eric

-------------------------
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
Distributed computing for pricing analytics - Use Microsoft Excel as a client
to the Grid

Re: [Quantlib-dev] Some questions about forcing recalculation

[a.p. <an...@gm...>]

Hello Eric, 
thank you for participation

"Please review the documentation below:

    http://www.objecthandler.org/references.html
    http://www.quantlibaddin.org/observer.html"

I could say, that i'm a big fan of QL, so of course i've already read all
useful articles :)

About your example:

"the object can be identified by the raw (literal) string "my_obj" - not
"my_obj#001" and not a reference to the range in the closed Book1.xls from
which the object was constructed" 

- that's the way i work with QLXL functions, but when the object is updated
(by user or by external data), how could we force recalculation of
dependency functions (such as qlYieldTSZeroRate, etc.)?! You see, Excel
recalculates UDF only in case of arguments change, but all arguments are
still the same (so if you hit F9 nothing will be changed)! One way to solve
this problem - to use trigger parameter, but itsn't convinient (see my
previous topic). So, are there another decisions?
-- 
View this message in context: http://www.nabble.com/Some-questions-about-forcing-recalculation-tp19140076p19197537.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Could someone post or e-mail an example of yield calculation of a fixed rate coupon bond?

[Florent G. <flo...@gm...>]

Hi Luigi,

Yes good idea, I'll do it as soon as I can. Just a small question: do you
already know when the next release will take place? I would like to bring my
modifications to the example before that release.

Thanks,
Florent

2008/8/27 Luigi Ballabio <lui...@gm...>

>
> On Aug 27, 2008, at 7:21 PM, Florent Grenier wrote:
>
>> I send you the corrected code.
>>
>
> Florent,
>        I see that you're using a depo-swap curve for forecasting LIBOR
> fixings and for dscounting.  If you have time to do so, and if you think
> that it makes sense, it might be interesting to use a bond curve for
> discounting instead; you can build one with a few FixedRateBondHelpers.
>
> Other than that, the example looks ok.  I'll add it to the library when you
> think it's finalized.
>
> Thanks,
>        Luigi
>
>
>

Re: [Quantlib-dev] Some questions about forcing recalculation

[Eric E. <eri...@na...>]

Hi Andrew,

Please review the documentation below:

    http://www.objecthandler.org/references.html
    http://www.quantlibaddin.org/observer.html

On Wed, August 27, 2008 10:29, a.p. wrote:
>
> "I wouldn't say that triggers are inconvenient - I would say that your Excel
> application should be carefully designed to ensure that object dependencies
> are maintained through the use of triggers."
>
> In fact object dependencies are absolutly maintained through the use of
> triggers, but this usage is inconvenient. For example, you've created an
> object ("my_obj") and calculate some functions (maybe dozens) with this
> object as a parameter. So the user of created application should directly
> reference to the cell with returning string ID (for instance "my_obj#001")
> through trigger argument.

In Book1.xls, create the object with ID "my_obj", then close Book1.xls.

Now, from anywhere else in the Excel session, when that object is required as
an input to a function, the object can be identified by the raw (literal)
string "my_obj" - not "my_obj#001" and not a reference to the range in the
closed Book1.xls from which the object was constructed.

The fact that Book1.xls is closed, prevents "my_obj" from being recreated
and spares you the hassle of ensuring that dependents of "my_obj" are updated
after "my_obj" is recreated.

(In fact ObjectHandler 0.9.6 includes an enhancement to prevent such problems
but let's not get into that now).

In this simple example you don't even need any triggers of any kind.

> In case of you example:
>
> "Construct objects as a separate step, when the application is initialized
> or in response to menu events.  Workbooks containing constructors should be
> opened once, calculated and closed to prevent unnecessary object
> reconstruction."
>
> it becomes impossible at all, cause object workbook have been closed.

Sounds like you're using a reference to the range in the closed book from
which "my_obj" was constructed.  Use instead the string "my_obj".

> Is
> this another way to reference all necessary objects as trigger argument when
> the application is initialized or maybe some other algorithm to prevent user
> from referencing trigger cell every time he calculates new function? Maybe,
> i missed smth, but i don't know what to do :(

So far we haven't even gotten into a case where triggers are required.  An
example of that is in the docs I referenced above, please get back to me if
it's unclear.

> "The XLL can use xlcOnRecalc to trap the recalculation event but I would
> strongly advise against that in this situation."
>
> Absolutely agree with you.

Ooops.  I mentioned xlcOnRecalc in response to this comment of yours:

> For example, i tried
> to constuct a VBA UDFs with QLXL functions call and force recalculation in
> case of hitting F9 or Shift+F9, but i couldn't.

But I misread - you're trying to implement the UDF not in the XLL but in VBA.
I wouldn't do that either ;-)

Regards,
Eric

-------------------------
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
Distributed computing for pricing analytics - Use Microsoft Excel as a client
to the Grid

Re: [Quantlib-dev] Could someone post or e-mail an example of yield calculation of a fixed rate coupon bond?

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

On Aug 27, 2008, at 7:21 PM, Florent Grenier wrote:
> I send you the corrected code.

Florent,
	I see that you're using a depo-swap curve for forecasting LIBOR  
fixings and for dscounting.  If you have time to do so, and if you  
think that it makes sense, it might be interesting to use a bond curve  
for discounting instead; you can build one with a few  
FixedRateBondHelpers.

Other than that, the example looks ok.  I'll add it to the library  
when you think it's finalized.

Thanks,
	Luigi

[Quantlib-dev] [ quantlib-Bugs-2076339 ] QuantLib::Brazil date correction

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

Bugs item #2076339, was opened at 2008-08-26 19:28
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2076339&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Luigi Ballabio (lballabio)
Summary: QuantLib::Brazil date correction

Initial Comment:
Im just starting to use QuantLib.

But I saw an error on QuantLib::Brazil Calendar:
Our Independence Day is NOT September 21th BUT
September 7th.

Thanks and nice work!
Andre Derraik (ade...@gm...)

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2008-08-27 16:18

Message:
Logged In: YES 
user_id=75450
Originator: NO

Thanks for the report---it was correct in the implementation but wrong in
the docs.
It is fixed now.

Luigi


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

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

[Quantlib-dev] [ quantlib-Bugs-2076339 ] QuantLib::Brazil date correction

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

Bugs item #2076339, was opened at 2008-08-26 19:28
Message generated for change (Settings changed) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2076339&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: QuantLib::Brazil date correction

Initial Comment:
Im just starting to use QuantLib.

But I saw an error on QuantLib::Brazil Calendar:
Our Independence Day is NOT September 21th BUT
September 7th.

Thanks and nice work!
Andre Derraik (ade...@gm...)

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

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

Re: [Quantlib-dev] Some questions about forcing recalculation

[a.p. <an...@gm...>]

"I wouldn't say that triggers are inconvenient - I would say that your Excel
application should be carefully designed to ensure that object dependencies
are maintained through the use of triggers."

In fact object dependencies are absolutly maintained through the use of
triggers, but this usage is inconvenient. For example, you've created an
object ("my_obj") and calculate some functions (maybe dozens) with this
object as a parameter. So the user of created application should directly
reference to the cell with returning string ID (for instance "my_obj#001")
through trigger argument. In case of you example:

"Construct objects as a separate step, when the application is initialized
or in response to menu events.  Workbooks containing constructors should be
opened once, calculated and closed to prevent unnecessary object
reconstruction."

it becomes impossible at all, cause object workbook have been closed. Is
this another way to reference all necessary objects as trigger argument when
the application is initialized or maybe some other algorithm to prevent user
from referencing trigger cell every time he calculates new function? Maybe,
i missed smth, but i don't know what to do :(

"The XLL can use xlcOnRecalc to trap the recalculation event but I would
strongly advise against that in this situation."

Absolutely agree with you.

Regards,
Andrew
-- 
View this message in context: http://www.nabble.com/Some-questions-about-forcing-recalculation-tp19140076p19177532.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] [ quantlib-Patches-2077710 ] Fix compile errors when using xlc on Linux

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

Patches item #2077710, was opened at 2008-08-27 17:17
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=2077710&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anton Blanchard (antonb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix compile errors when using xlc on Linux

Initial Comment:
quantlib fails to build when using the IBM xlc compiler on Linux. While the gcc compiler is OK, xlc complains that it cant resolve ShortRateDynamics:

class CoxIngersollRoss::Dynamics : public ShortRateDynamics {

The following patch (against latest SVN) fixes it:

    class CoxIngersollRoss::Dynamics : public OneFactorModel::ShortRateDynamics {

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

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