quantlib-dev — Discussion of QuantLib development

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

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

Feature Requests item #2076339, was opened at 2008-08-26 17:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&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
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=362740&aid=2076339&group_id=12740

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

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

Patches item #2076218, was opened at 2008-08-26 12:16
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=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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Slava Mazur (shlagbaum)
Assigned to: Nobody/Anonymous (nobody)
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.


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

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

Re: [Quantlib-dev] Fatal error in test suite "QuantLib test suite" in QuantLib 0.9.6

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

On Sun, 2008-08-24 at 12:54 -0500, Dirk Eddelbuettel wrote:
> On 24 August 2008 at 10:14, Georgy Jikia wrote:
> | I did not see this error being posted yet:
> | 
> | ./optionletstripper.cpp(361): fatal error in
> | "QuantLib::detail::quantlib_test_case(&OptionletStripperTest::testTermVolatilityStripping1)":
> | 
> | option tenor:       20Y
> | strike:             4.000000 %
> | stripped vol price: 8.178939 %
> | constant vol price: 8.180508 %
> | error:              0.001569 %
> | tolerance:          0.001500 %
> | 
> | I think the error was not present in QuantLib 0.9.5.
> 
> What platform / compiler / settings / ... ?  
> 
> For the Debian builds (which I do on x86 using gcc/g++, currently at upstream
> version 4.3.1), the standard 0.9.6 release also showed this (and similar "is
> past max curve time" messages in more places) :

No, the "is past max curve time" messages are not related---they were
some kind of compiler issue with Debian unstable which I haven't seen on
other compilers.  On the other hand, I did see the error reported by
Georgy---on some dates (the test passed in the past weeks and started
failing recently) the stripping error goes slightly above the tolerance
set in the test.  We'll have to see how the input accuracy is used and
whether the tolerance is too small.

Luigi



-- 

Poets have been mysteriously silent on the subject of cheese. 
-- Gilbert K. Chesterton 

Re: [Quantlib-dev] projects??

[adam99 <ada...@gm...>]

Thanks Luigi,

Code review sounds like a good way to start. Could you provide me the link
(and some information) for the code to look at

Adam
-- 
View this message in context: http://www.nabble.com/Re%3A-projects---tp19163254p19163528.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] projects??

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

On Sun, 2008-08-24 at 12:46 -0700, adam99 wrote:
> I am taking off from work for a while. Are there any projects that I could
> help? My experience is mainly on fixed income (bonds and interest rate
> models)

Adam,
	thanks for the offer.  As for projects I have in mind, there's not
much---these days, I'm mostly interested in consolidating the code for
release 1.0.  Are you familiar with the current code base, especially
with respect to interest rates?  Is there anything that strikes you as
missing?  Another possibility is that you help me doing code review on a
few contributions I received; in particular, there was one about
amortizing bonds that I still haven't had the time to look at.
Let me know what you think.

Later (and thanks again,)
	Luigi


-- 

The box said "Use Windows 95 or better," so I got a Macintosh. 

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

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

Hello,

On Mon, August 25, 2008 09:52, a.p. wrote:
>
> Hello guys.
> Thank you for your priveous help - it was relly useful.

With pleasure.

> Currently, i try to solve one popular Excel problem - force recalculation
> within UDFs (in this case - QLXL functions). The main problem is string (ID)
> referring to QL add-inn objects. In QLXL there is one sophisticated way to
> force the correct dependency recalculation - usage trigger method for
> observable objects. Unfortunately this way is not relly convinient when you
> work within Excel workbook which contains a lot of objects (such as option
> trader workbooks) and data (so Ctrl+Alt+F9 method is also unaffordable).

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.  You're absolutely right that in a
live desktop trading environment it should not ever be necessary for the user
to hit Ctrl-Alt-F9 to force a full recalculation.

The design of QLXL favors the performance of member functions over
constructors, and constructors are allowed certain more expensive operations
which are not called from members.  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.  Even better, construct objects by
deserializing them from XML initialization data that you create in advance,
constructing objects this way is many times faster than constructing them from
worksheet formulas.  The objective is a workbook which is hooked up to the
live data feed with calculation set to automatic, prices recalculated in real
time, and any objects updated non-destructively.

> Could you suggest any decisions to clear this obstacle?
> 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.

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

> P.S. Am i right that the only way to solve this problem via C++ is to use
> trigger method?

Triggers are the best way to maintain object dependencies that are not
apparent to Excel, for example where QuantLib's Observer/Observable pattern is
exploited (http://quantlib.org/quantlibaddin/observer.html).

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] [QuantLib-svn] SF.net SVN: quantlib:[15403] trunk/QuantLib

[Roland L. <rol...@go...>]

Hi all,I will have a look at the problem in the next week or two and make
the necessary fixes.
Best,
Roland

On Thu, Aug 21, 2008 at 2:55 PM, Ferdinando Ametrano <na...@am...>wrote:

> On Wed, Aug 20, 2008 at 12:40 PM,  <lba...@us...>
> wrote:
> > Log Message:
> > -----------
> > Added experimental CDO implementation (thanks to Roland Lichters)
>
> the unit-test fails on Windows XP SP2, VC8 SP1, boost 1.36:
>
> 1>Testing CDO premiums against Hull-White values...
> 1>./cdo.cpp(173): error in "CdoTest::testHW": tolerance 0.03|2
> exceeded in: 0.10 -1 -1  0.06  0.10       93       89     3.60    4.0
> 1
>
> ciao -- Nando
>
> -------------------------------------------------------------------------
> 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
>

[Quantlib-dev] Some questions about forcing recalculation

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

Hello guys.
Thank you for your priveous help - it was relly useful.
Currently, i try to solve one popular Excel problem - force recalculation
within UDFs (in this case - QLXL functions). The main problem is string (ID)
referring to QL add-inn objects. In QLXL there is one sophisticated way to
force the correct dependency recalculation - usage trigger method for
observable objects. Unfortunately this way is not relly convinient when you
work within Excel workbook which contains a lot of objects (such as option
trader workbooks) and data (so Ctrl+Alt+F9 method is also unaffordable).
Could you suggest any decisions to clear this obstacle? 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.
P.S. Am i right that the only way to solve this problem via C++ is to use
trigger method?
-- 
View this message in context: http://www.nabble.com/Some-questions-about-forcing-recalculation-tp19140076p19140076.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?

[adam99 <ada...@gm...>]

Hi Florent

your settlement days are 3, but fixing days are 2. If you make both 3, you
will get same results in your floater check

Thanks
Adam


Florent Grenier wrote:
> 
> Dear Luigi, quantlib-users,
> 
> I'm currently in the process of writing such a sample (it's almost over in
> fact). I'm still having small discrepancies between direct calculations of
> the prices and yields, and the results of yield to price/price to yield
> computations. I'm going to investigate them as soon as I have some time.
> 
> By the way I enclosed the code I wrote to this e-mail (as well as the
> result
> of its execution). It gives a good idea on how Maria could compute the
> yield
> of her bond.
> 
> If someone has some remarks regarding the quality or the completeness of
> my
> sample, do not hesitate to tell me. Just to add that my code compiles
> against Quantlib 0.9.6
> 
> Thanks,
> Florent
> 
> 
> 
> 2008/8/18 Luigi Ballabio <lui...@gm...>
> 
>>
>> On Aug 17, 2008, at 3:47 AM, maria vieira wrote:
>> > I am a very experienced programmer in fortran, but I know very
>> > little of objected oriented programming.To help me to get started
>> > using QuantLib, could someone post or send to me
>> > (mar...@ya...) a simple example of yield calculation of a
>> > fixed rate coupon bond? I was told to look at the "test suite" but I
>> > am so new to all this, including QuantLib, that this advice did not
>> > help me much. I need a complete code such as the
>> > "ConvertibleBonds.cpp", which comes in the QuantLib package. That
>> > is, a code in which I just have to compile and run. Of course, I
>> > would also appreciate receiving other examples of code, but the one
>> > mentioned above would already be very helpful. Thanks!
>>
>> A quick note: if anyone wants to write a bond example, post it here---
>> I'll be happy to include it in next release.
>>
>> Thanks,
>>        Luigi
>>
>> P.S. Maria: in the meantime, you can start looking at the file test-
>> suite/bonds.cpp.
>> It cannot be compiled as it is, but chances are that you can can take
>> any of the functions in there, copy it in a separate file, rename it
>> as main() and obtain a running program. (You'll probably have to
>> remove the BOOST_ERROR function calls, too.)
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
> 
>  
> 
> Today: Wednesday, June 18th, 2008
> Settlement date: Friday, June 20th, 2008
> 
>                           ZC     Fixed  Floating
> ------------------------------------------------
>  Net present value     94.24     99.66    101.49
>        Clean price     94.24     99.18    101.09
>        Dirty price     94.24     99.66    101.49
>     Accrued coupon      0.00      0.48      0.40
>    Previous coupon    0.00 %    4.50 %    5.23 %
>        Next coupon       xxx    4.50 %    2.67 %
>              Yield    4.22 %    4.60 %    3.64 %
> 
> Sample indirect computations (for the floating rate bond):
> ------------------------------------------------
> Yield to Clean Price: 101.08
> Clean Price to Yield: 3.63 %
> 
> Run completed in 0 s
> 
> 
> -------------------------------------------------------------------------
> 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
> 
> 

-- 
View this message in context: http://www.nabble.com/Could-someone-post-or-e-mail-an-example-of-yield-calculation-of-a-fixed-rate-coupon-bond--tp19016811p19138186.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] projects??

[adam99 <ada...@gm...>]

I am taking off from work for a while. Are there any projects that I could
help? My experience is mainly on fixed income (bonds and interest rate
models)

Thanks
Adam
-- 
View this message in context: http://www.nabble.com/projects---tp19134042p19134042.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Fatal error in test suite "QuantLib test suite" in QuantLib 0.9.6

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

On 24 August 2008 at 10:14, Georgy Jikia wrote:
| I did not see this error being posted yet:
| 
| ./optionletstripper.cpp(361): fatal error in
| "QuantLib::detail::quantlib_test_case(&OptionletStripperTest::testTermVolatilityStripping1)":
| 
| option tenor:       20Y
| strike:             4.000000 %
| stripped vol price: 8.178939 %
| constant vol price: 8.180508 %
| error:              0.001569 %
| tolerance:          0.001500 %
| 
| I think the error was not present in QuantLib 0.9.5.

What platform / compiler / settings / ... ?  

For the Debian builds (which I do on x86 using gcc/g++, currently at upstream
version 4.3.1), the standard 0.9.6 release also showed this (and similar "is
past max curve time" messages in more places) :

[...]
Testing nested optimizations...
Testing forward/forward vol stripping from flat term vol surface using optionletstripper1...
Testing forward/forward vol stripping from non-flat term vol surface using optionletstripper1...
Testing forward/forward vol stripping from flat term vol surface using optionletstripper2...
unknown location(0): fatal error in "OptionletStripperTest::testFlatTermVolatilityStripping2": std::exception: time (10.0055) is past max curve time (10.0055)
nthtodefault.cpp(296): last checkpoint
Testing forward/forward vol stripping from non-flat term vol surface using optionletstripper2...
unknown location(0): fatal error in "OptionletStripperTest::testTermVolatilityStripping2": std::exception: time (30.0192) is past max curve time (30.0192)
nthtodefault.cpp(296): last checkpoint
[...]

whereas after applying a patch (see below) from Luigi

[...]
Testing nested optimizations...
Testing forward/forward vol stripping from flat term vol surface using optionletstripper1...
Testing forward/forward vol stripping from non-flat term vol surface using optionletstripper1...
Testing forward/forward vol stripping from flat term vol surface using optionletstripper2...
Testing forward/forward vol stripping from non-flat term vol surface using optionletstripper2...
Testing 1-D path generation against cached values...
[...]

things are more peachy.  The simple patch is below, see if that helps. Thanks
as always to Luigi for a quick response when I reported that earlier in an
off-list email, and thanks to you for reporting this too -- looks like it may
be a more generally relevant issue.

Cheers, Dirk


--- quantlib-0.9.6.orig/ql/termstructure.cpp
+++ quantlib-0.9.6/ql/termstructure.cpp
@@ -18,6 +18,7 @@
 */
 
 #include <ql/termstructure.hpp>
+#include <ql/math/comparison.hpp>
 
 namespace QuantLib {
 
@@ -77,7 +78,7 @@
                                    bool extrapolate) const {
         QL_REQUIRE(t >= 0.0,
                    "negative time (" << t << ") given");
-        QL_REQUIRE(extrapolate || allowsExtrapolation() || t <= maxTime(),
+        QL_REQUIRE(extrapolate || allowsExtrapolation() || t <= maxTime() || close_enough(t, maxTime()),
                    "time (" << t << ") is past max curve time ("
                             << maxTime() << ")");
     }



-- 
Three out of two people have difficulties with fractions.

[Quantlib-dev] Fatal error in test suite "QuantLib test suite" in QuantLib 0.9.6

[Georgy J. <geo...@gm...>]

I did not see this error being posted yet:

./optionletstripper.cpp(361): fatal error in
"QuantLib::detail::quantlib_test_case(&OptionletStripperTest::testTermVolatilityStripping1)":

option tenor:       20Y
strike:             4.000000 %
stripped vol price: 8.178939 %
constant vol price: 8.180508 %
error:              0.001569 %
tolerance:          0.001500 %

I think the error was not present in QuantLib 0.9.5.

Regards,
Georgy

Re: [Quantlib-dev] precision in cubicsplineinterpolation (and in general)

[Sylvain B. <syl...@gm...>]

Hi Luigi,


On Fri, Aug 22, 2008 at 11:52 AM, Luigi Ballabio
<lui...@gm...>wrote:

>
> Possibly. It would make the Matrix code quite a bit more complicated,
> though.  Do you think it would be possible to improve the accuracy of
> matrix calculations while keeping the double type? Maybe by using some
> smarter algorithms instead of the naive ones we used?
>
>
That sounds unlikely. Here we're talking about basic algebra, it's not an
"optimization with constraint" problem.
Would a generic (real) matrix template not be useful though?
I agree it would probably involve a significant amount of work in that
class, but not outside if by default we consider Matrix as Matrix<QL_REAL>.

Let me know what you think.

Sylvain

Re: [Quantlib-dev] precision in cubicsplineinterpolation (and in general)

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

Hi Sylvain,
	apologies for the long silence.

On Mon, 2008-08-04 at 11:55 -0400, Sylvain Bertrand wrote:
> As the implementation relies heavily on matrix operations, I would
> need to use only long double matrices, which work if I set QL_REAL to
> long double for the whole library, since matrices are forced to the
> QL_REAL type.
>  
> "QL_REAL = long double" would then have to be the default for QL
> releases, otherwise the user would run the risk of using the cubic
> splines with very poor results (in that case there should also be a
> warning to prevent the user from changing the setting back to double
> and use the splines).
>  
> Is that something that would be acceptable? I personally don't think
> of it as the best option.

You're right, this is not a good option.

> Another option would be to transform the current Matrix class into a
> template to support different types, which would give each piece of
> code the freedom to use the default QL_REAL or use more precision when
> needed.

Possibly. It would make the Matrix code quite a bit more complicated,
though.  Do you think it would be possible to improve the accuracy of
matrix calculations while keeping the double type? Maybe by using some
smarter algorithms instead of the naive ones we used?

Later,
	Luigi


-- 

The rule on staying alive as a forecaster is to give 'em a number or 
give 'em a date, but never give 'em both at once. 
-- Jane Bryant Quinn 

Re: [Quantlib-dev] Period to frequency conversion.

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

On Thu, 2008-07-31 at 15:58 -0400, Slava Mazur wrote:
> Is there any particular reason for restrictions in Period::frequency()
> method on the length in weeks and days?

Not really---I guess it was so that we could return a frequency. Since
in most cases this is only a cosmetic requirement, we could get away by
returning an unknown frequency instead of throwing an exception. Would
this be ok for you? Are you willing to write a patch?

Later,
	Luigi


-- 

It is better to know some of the questions than all of the answers. 
-- James Thurber 

Re: [Quantlib-dev] How to output into Excel cell an error message directly from qlxl function call?

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

Hello,

On Thu, August 21, 2008 13:40, a.p. wrote:
>
> Hello.
> I try to return an error message directly from any OPER* function. Usually,
> in any catch section (at the end of XLL_DEC function description) error
> message are logged by logError() function. So return value is 0, or #NUM in
> Excel cell. Is there any way to return an error message during function
> call, instead of usage retrieveError function (like in QLXL framework by
> "Display error" option)? I tried to create a local XLOPER variable in catch
> section, such as:
>
> catch (const std::exception &e) {
>     XLOPER returnValue;
>     const std::string str = e.what();
>     ObjectHandler::scalarToOper(str, returnValue);
>     return &returnValue;
> }
> but of course it doesn't work cause the returnValue variable is local.
> Thanks.

You just need to declare returnValue as a static variable.

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] [QuantLib-svn] SF.net SVN: quantlib:[15403] trunk/QuantLib

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

On Wed, Aug 20, 2008 at 12:40 PM,  <lba...@us...> wrote:
> Log Message:
> -----------
> Added experimental CDO implementation (thanks to Roland Lichters)

the unit-test fails on Windows XP SP2, VC8 SP1, boost 1.36:

1>Testing CDO premiums against Hull-White values...
1>./cdo.cpp(173): error in "CdoTest::testHW": tolerance 0.03|2
exceeded in: 0.10 -1 -1  0.06  0.10       93       89     3.60    4.0
1

ciao -- Nando

[Quantlib-dev] How to output into Excel cell an error message directly from qlxl function call?

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

Hello.
I try to return an error message directly from any OPER* function. Usually,
in any catch section (at the end of XLL_DEC function description) error
message are logged by logError() function. So return value is 0, or #NUM in
Excel cell. Is there any way to return an error message during function
call, instead of usage retrieveError function (like in QLXL framework by
"Display error" option)? I tried to create a local XLOPER variable in catch
section, such as:

catch (const std::exception &e) {
    XLOPER returnValue;
    const std::string str = e.what();
    ObjectHandler::scalarToOper(str, returnValue);
    return &returnValue;
} 
but of course it doesn't work cause the returnValue variable is local.
Thanks.
-- 
View this message in context: http://www.nabble.com/How-to-output-into-Excel-cell-an-error-message-directly-from-qlxl-function-call--tp19087896p19087896.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Error calling xlfGetDef Excel API function from Objecthandler's FunctionCall::callerName()

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

Hi Slava,

On Wed, August 20, 2008 15:01, Slava Mazur wrote:
> Hi Eric,
>
> Thank you for the explanation. Looks like the issue is boiled down to a
> new ObjectHandler requirement missed by me at some point: from now on
> one cannot define two different objects in different Excel cells and
> having the same user id. Depending on "overwrite" parameter the result
> would be either exception or the second object substitutes the first one
> in the object map.
>
> Please confirm that the above statement is correct.

Confirmed!

> If so, then yes, I agree, ObjectHandler is not as badly broken. What is
> badly broken, however, is backward compatibility, since now I have to
> redesign all my spreadsheets which worked fine with previous version of
> ObjectHandler (the one that used '~' as a key separator) to make sure
> uniqueness of all object ids defined. Right?

Probably yes.  I remember the ~ thing, that was a long time ago.  I can't
remember whether unique IDs were enforced in whatever version of OH that was,
but if you tell me they weren't I believe you.  I apologize for the
frustration caused by the lack of backward compatibility.

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] Cannot build QuantLibAddin with QuantLib 0.9.6

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

Hi Slava

> The QuantLibAddin project doesn't compile with QuantLib 0.9.6. I downloaded
> all the projects from corresponding SourceForge page. The version of
> QuantLibAddin project is 0.9.0.
this is expected, as you would need QuantLibAddin 0.9.6 which should
be released shortly.

If you want to compile it by yourself you should check out from our
repository the R000905-branch tag (the 5 is correct, even if the
release is 0.9.6)

Even better: just work on the trunk of our repository and you will get
the most recent code base

ciao -- Nando

Re: [Quantlib-dev] addition to QuantLib-SWIG/SWIG/stochasticprocess.i

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

On Sun, 2008-08-17 at 12:18 -0700, Tito Ingargiola wrote:
> Could someone kindly add the below code to
> QuantLib-SWIG/SWIG/stochasticprocess.i 

Done, thanks.

Luigi


-- 

A programming language is low-level when its programs require attention 
to the irrelevant. 
-- Alan Perlis 

Re: [Quantlib-dev] Error calling xlfGetDef Excel API function from Objecthandler's FunctionCall::callerName()

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

Hi Eric,

Thank you for the explanation. Looks like the issue is boiled down to a
new ObjectHandler requirement missed by me at some point: from now on
one cannot define two different objects in different Excel cells and
having the same user id. Depending on "overwrite" parameter the result
would be either exception or the second object substitutes the first one
in the object map.

Please confirm that the above statement is correct.

If so, then yes, I agree, ObjectHandler is not as badly broken. What is
badly broken, however, is backward compatibility, since now I have to
redesign all my spreadsheets which worked fine with previous version of
ObjectHandler (the one that used '~' as a key separator) to make sure
uniqueness of all object ids defined. Right?

Thanks again,

Slava Mazur

-----Original Message-----
From: Eric Ehlers [mailto:eri...@na...] 
Sent: Wednesday, August 20, 2008 7:23 AM
To: Slava Mazur
Cc: qua...@li...
Subject: RE: [Quantlib-dev] Error calling xlfGetDef Excel API function
from Objecthandler's FunctionCall::callerName()

Hi Slava,

On Tue, August 19, 2008 19:53, Slava Mazur wrote:
> Thank you for the information and for the insides of ObjectHandler
functionality which have been really helpful to pinpoint the problem.

OK!  I'll help however I can to promote the use of OH as a standalone
app.

> Objects are stored in objectMap_ using object ID as a key (see
> std::string Repository::storeObject).
>
> ObjectXL class returns a user defined id ignoring the calling range
and this
id is used as a key in the object map (see ObjectXL::id() and
RepositoryXL::storeObject()).
>
> This is obviously a problem - if we create two different objects in
different Excel cells they will definitely substitute each other in the
object map.

ObjectHandler is not as badly broken as that!  ;)

Try an experiment:
- Start Excel
- Load your favorite OH-derived XLL - ExampleXLLStatic, QLXL,
  your own app, whatever
- In cell A1, create an object with ID foo
- In cell A2, create an object with ID foo

The constructor in A2 fails with this error message:

    ohCustomer - Cannot create object with ID 'foo' in cell
    [exampleStatic.xls]Feuil1!L2C1 because an object with that ID
already
    resides in cell [exampleStatic.xls]Feuil1!L1C1

See RepositoryXL::storeObject().

All the QLXL constructors have an autogenerated parameter Overwrite
which you
can set to True if you really want to do that.

> Another problem is CallingRange::updateCount_. Since it's a non-static
member then it's possible to generate the same ObjectXL::idFull_ for
different objects with the same user defined id (see
> ObjectXL::setCallingRange()).

idFull_ takes the form abcd#0000 where

1) abcd is either the string supplied by the user, or the value
obj_12345
generated by OH if the user passed a null string.  As far as the user is
concerned, the 12345 is just a value which OH guarantees to be unique.
In
practice it is the key of the calling range.

2) 0000 is the update count for the calling range

As explained above, 1) is guaranteed to be unique, whether the value is
provided by the user or autogenerated by OH.

But note that 2) is for informational purposes only and we don't rely on
the
uniqueness of 2) to ensure the uniqueness of idFull_.  Any time an
object ID
is used for internal processing, it is passed to getStub() which strips
off
the #0000 suffix if present.

Also class ObjectXL last appeared in OH version 0.9.0 and is replaced by
ObjectWrapperXL in 0.9.6.  Once you get down to implementation you will
probably want to work from the svn trunk.

> Note that if a user doesn't specify their id, everything works fine
because
in this case internally generated id takes into account a calling range
(see
again ObjectXL::setCallingRange()).

Yes, an autogenerated ID is guaranteed unique by incorporating
CalingRange::key(), which I represented as 12345 above.

> I think this can be fixed in two ways. For my quick fix I changed the
logic
of ObjectXL::id() - it generates id upending calling range key
regardless of
whether a user passed a valid id or not.

Based on the above I think no fix is necessary, unless you have found a
bug
which breaks the test I described.  Your resolution would be effective
in such
a situation, though I wouldn't use it as a permanent solution since I
think
the user would be surprised to find his key altered.  I understand you
have
this as just a quick fix.

> However, as far as I understood, one of motivations for the current
design
was to hide calling range keys from the users and handle them
internally. In
this case one needs to figure out a caller range key and generate a key
to
find an object in the map out of a user defined id and the calling range
key. I'm not sure how to do that. And also, in this case one needs to
make
CallingRange::updateCount_ static. Otherwise a user will be able to
generate
the same object ids for different objects, which although will be
handled
correctly internally (since calling ranges are different) would look
misleading from the user's perspective.

I haven't explicitly set out to hide keys from the user.  They can be
accessed
by function ohObjectCallerKey() and are written to the log file by
function
ohLogAllObjects().  I find that very helpful for troubleshooting but I
doubt
anyone else ever used it so yes in general the keys are not displayed to
the
user.

Again I think that the uniqueness of object IDs is already enforced,
without
the need to make updateCount unique.  Please review this and let me know
- if
you have found a bug in the current implementation then we can work out
a fix.

> Eric, I know I owe you my reply regarding XLL containers. Thank you
for your
appreciation and interest. I still don't have any feedback from my
employer
regarding the source code (perhaps because of vacation time and Olympic
Games of course :), but it looks like they won't object. As for
technical
details, I'll definitely get back to you as soon as I sort out all
existing
issues with ObjectHandler.

No hurry at all.  I'm glad to hear that the early signs are encouraging
and I
look forward to getting into the details when the time comes.

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] Error calling xlfGetDef Excel API function from Objecthandler's FunctionCall::callerName()

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

Hi Slava,

On Tue, August 19, 2008 19:53, Slava Mazur wrote:
> Thank you for the information and for the insides of ObjectHandler
functionality which have been really helpful to pinpoint the problem.

OK!  I'll help however I can to promote the use of OH as a standalone app.

> Objects are stored in objectMap_ using object ID as a key (see
> std::string Repository::storeObject).
>
> ObjectXL class returns a user defined id ignoring the calling range and this
id is used as a key in the object map (see ObjectXL::id() and
RepositoryXL::storeObject()).
>
> This is obviously a problem - if we create two different objects in
different Excel cells they will definitely substitute each other in the
object map.

ObjectHandler is not as badly broken as that!  ;)

Try an experiment:
- Start Excel
- Load your favorite OH-derived XLL - ExampleXLLStatic, QLXL,
  your own app, whatever
- In cell A1, create an object with ID foo
- In cell A2, create an object with ID foo

The constructor in A2 fails with this error message:

    ohCustomer - Cannot create object with ID 'foo' in cell
    [exampleStatic.xls]Feuil1!L2C1 because an object with that ID already
    resides in cell [exampleStatic.xls]Feuil1!L1C1

See RepositoryXL::storeObject().

All the QLXL constructors have an autogenerated parameter Overwrite which you
can set to True if you really want to do that.

> Another problem is CallingRange::updateCount_. Since it's a non-static
member then it's possible to generate the same ObjectXL::idFull_ for
different objects with the same user defined id (see
> ObjectXL::setCallingRange()).

idFull_ takes the form abcd#0000 where

1) abcd is either the string supplied by the user, or the value obj_12345
generated by OH if the user passed a null string.  As far as the user is
concerned, the 12345 is just a value which OH guarantees to be unique.  In
practice it is the key of the calling range.

2) 0000 is the update count for the calling range

As explained above, 1) is guaranteed to be unique, whether the value is
provided by the user or autogenerated by OH.

But note that 2) is for informational purposes only and we don't rely on the
uniqueness of 2) to ensure the uniqueness of idFull_.  Any time an object ID
is used for internal processing, it is passed to getStub() which strips off
the #0000 suffix if present.

Also class ObjectXL last appeared in OH version 0.9.0 and is replaced by
ObjectWrapperXL in 0.9.6.  Once you get down to implementation you will
probably want to work from the svn trunk.

> Note that if a user doesn't specify their id, everything works fine because
in this case internally generated id takes into account a calling range (see
again ObjectXL::setCallingRange()).

Yes, an autogenerated ID is guaranteed unique by incorporating
CalingRange::key(), which I represented as 12345 above.

> I think this can be fixed in two ways. For my quick fix I changed the logic
of ObjectXL::id() - it generates id upending calling range key regardless of
whether a user passed a valid id or not.

Based on the above I think no fix is necessary, unless you have found a bug
which breaks the test I described.  Your resolution would be effective in such
a situation, though I wouldn't use it as a permanent solution since I think
the user would be surprised to find his key altered.  I understand you have
this as just a quick fix.

> However, as far as I understood, one of motivations for the current design
was to hide calling range keys from the users and handle them internally. In
this case one needs to figure out a caller range key and generate a key to
find an object in the map out of a user defined id and the calling range
key. I'm not sure how to do that. And also, in this case one needs to make
CallingRange::updateCount_ static. Otherwise a user will be able to generate
the same object ids for different objects, which although will be handled
correctly internally (since calling ranges are different) would look
misleading from the user's perspective.

I haven't explicitly set out to hide keys from the user.  They can be accessed
by function ohObjectCallerKey() and are written to the log file by function
ohLogAllObjects().  I find that very helpful for troubleshooting but I doubt
anyone else ever used it so yes in general the keys are not displayed to the
user.

Again I think that the uniqueness of object IDs is already enforced, without
the need to make updateCount unique.  Please review this and let me know - if
you have found a bug in the current implementation then we can work out a fix.

> Eric, I know I owe you my reply regarding XLL containers. Thank you for your
appreciation and interest. I still don't have any feedback from my employer
regarding the source code (perhaps because of vacation time and Olympic
Games of course :), but it looks like they won't object. As for technical
details, I'll definitely get back to you as soon as I sort out all existing
issues with ObjectHandler.

No hurry at all.  I'm glad to hear that the early signs are encouraging and I
look forward to getting into the details when the time comes.

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] boost 1.36 and the forthcoming release of QLXL 0.96

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

Hi Nando,

On Tue, August 19, 2008 18:12, Ferdinando Ametrano wrote:
> Hi Eric,
>
> I've switched today to boost 1.36 and noticed that while QL 0.96 has no
problem with it, this is not the case for OH 0.96:

OK I see you and Kim Kuen Tang just fixed that one on R000905-branch.  The
same fix was created in branch oh_functions courtesy of our colleague Sun Quan
aka June with some feedback from the eagle eyed Luigi.  I'll delete branch
oh_functions and the fix will appear on the trunk when I merge the
R000905-branch.

> ok, so we're now only left with
>
>> warning C4251: 'ObjectHandler::ProcessorFactory::processorMap_' : class
'std::map<_Kty,_Ty>' needs to have dll-interface to be used by clients of
class
>> 'ObjectHandler::ProcessorFactory'
>> c:\Projects\DevEnv\R000905-branch\ObjectHandler\oh\processor.hpp        107

Class Repository already employs a workaround to allow std::map in a DLL,
we'll invesitgate whether the the same fix can be used for ProcessorFactory.

> BTW what compiler do you (plan to) use for the binaries to be
> distributed with QLXL? I'm currently using VC8 SP1, just because the runtime
libraries of VC9 are missing from the default configuration of most of the
(non-developer) workstation I work with (XP SP2; it might be the case those
dlls are available in XP SP3, I'm not sure. Again: any clue from anyone?). Of
course this is not relevant if we
> distribute the static xll.

The binary QLXL release is compiled with /MT so there is no issue with run
time dependencies.  On my machine I have
1) VC8 Standard + SP1
2) VC9 Express
I'm not aware of any reason to favor one over the other for the binary release
and am planning to use 1).

For other purposes I use the dynamically linked XLLs which require /MD and in
that case I use 1) just because the run time DLLs are more widely distributed,
though in any case if they're missing you can use the relevant vcredist
package as Luigi pointed out.

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] boost 1.36 and the forthcoming release of QLXL 0.96

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

ok, so we're now only left with

> warning C4251: 'ObjectHandler::ProcessorFactory::processorMap_' :
> class 'std::map<_Kty,_Ty>' needs to have dll-interface to be used by
> clients of class
> 'ObjectHandler::ProcessorFactory'       c:\Projects\DevEnv\R000905-branch\ObjectHandler\oh\processor.hpp        107

the Help clarify:
> To minimize the possibility of data corruption when exporting a class with __declspec(dllexport), ensure that:
>
> All your static data is access through functions that are exported from the DLL.

but since I'm not familiar with that code I'll leave this one to Eric
or anyone knowledgeable about it.

ciao -- Nando