quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] test suite fails when run in debug mode but is successful when run in release mode

[Rahul R. K. <rah...@gm...>]

Hi All,
I have this wierd problem when running test suite. An exception is thrown
when testsuite is run in debug mode. But when run in release mode it is
successfull as some of the asserts are skipped in release mode.

Note: I have checked out latest quantlib using tortoiseSVN and built it.
Finally when i ran testsuite, an exception is thrown. Stack trace is
attached. Could you please let me know if this a known behavior.

Error Message:
==========
First-chance exception at 0x763cc83b in QuantLib-test-suite-vc100-mt-gd.exe:
Microsoft C++ exception: QuantLib::Error at memory location 0x0017a008..

Stack trace is shown below:
=====================
ThrowException
QuantLib-test-suite-vc100-mt-gd.exe!QuantLib::TermStructure::checkRange(double
t, bool extrapolate) Line 77
QuantLib-test-suite-vc100-mt-gd.exe!QuantLib::YieldTermStructure::discount(double
t, bool extrapolate) Line 93
QuantLib-test-suite-vc100-mt-gd.exe!QuantLib::YieldTermStructure::discount(const
QuantLib::Date &d, bool extrapolate) Line 188
QuantLib-test-suite-vc100-mt-gd.exe!QuantLib::DiscountingSwapEngine::calculate()
Line 94
QuantLib-test-suite-vc100-mt-gd.exe!QuantLib::Instrument::performCalculations()
Line 168
QuantLib-test-suite-vc100-mt-gd.exe!QuantLib::LazyObject::calculate() Line
140
QuantLib-test-suite-vc100-mt-gd.exe!QuantLib::Instrument::calculate() Line
155
QuantLib-test-suite-vc100-mt-gd.exe!QuantLib::AssetSwap::fairCleanPrice()
Line 221
QuantLib-test-suite-vc100-mt-gd.exe!AssetSwapTest::testConsistency() Line
163
......
.....

Re: [Quantlib-dev] Reg. Contributing

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

Dexter,
	apologies for the delay.  I've seen you've been suggested some docs to
get familiar with the library, so I won't go through it again.  What
kind of experience do you have?

Later,
	Luigi


On Mon, 2011-07-11 at 11:19 -0400, Dexter Moser wrote:
> I am new to Quantlib. I have heard a lot about contributing to
> open-source projects. But i do not have any prior experience.As i will
> be graduating soon , in order to find a good job, i need to improve my
> skills and develop unique skills like volunteering in open-source
> project. I have good knowledge about the financial products and
> quantitative methods. Having tried the examples, i got interested in
> contributing to the project. 
> 
> 
> Are there any "To-do" lists according to the difficulty level.  
> 
> 
> or any documents to help the new contributors like me. 



-- 

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

[Quantlib-dev] Contact

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

Hi all,
	sorry for a bit of mailing-list administration.  Aubrey Quarcoo, if  
you're reading this, there are emails coming to quantlib-dev for  
resetting the password of your LinkedIn account; is seems that for  
some reason it was associated to the mailing-list address.  Please  
contact me so we can sort it out.

Luigi

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[17823] trunk/QuantLib/ql

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

On Thu, 2011-06-30 at 11:11 +0200, Ferdinando Ametrano wrote:
> > Sorry, it breaks backwards compatibility.  We'll have to think how to go
> > about this, and it's ok to leave it for the time being, but it will have to
> > be reverted.
> 
> mmm... I saw this coming, but wanted to give you a chance at being
> less conservative :-)

Ok.  Since there's little chance of anybody having written any code that
might break, go ahead; but please write a short how-to in the News.txt
file explaining how to change one's own traits and bootstrap.

Ciao,
	Luigi


> jokes aside, let me add few points to think about:
> 
> 1) I broke the backward compatibility of yield/credit/inflation
> traits, but is there anyone using those traits decoupled from QuantLib
> iterative bootstrap? Really hard to believe.. and if such a geek
> exists, please speak up now!
> Anyway I could add the old signature (deprecated) methods back along
> with the new overloads: this would preserve backward compatibility,
> but I see little point besides obfuscating the traits usage
> 
> 2) my refactored iterative bootstrap does use the new traits methods,
> and so I broke any proprietary traits used for bootstrapping
> proprietary curves with QuantLib iterative bootstrap. Frankly I find
> hard to believe that someone able to figure out how to write new
> traits would have problems moving them to their new generalized
> interface. It's much more likely that such a coder would consider the
> huge speedup of the bootstrap worth the few minutes needed for adding
> a curve pointer in the signature
> 
> As for the benefit of this refactoring:
> 
> a) the guess change is to separate guessing from iterative
> boostrapping. To fully delegate guessing to the traits improves
> dramatically the readability of the iterative bootstrap. In the
> previous version of iterative bootstrap the guess logic intervened
> badly with the bootstrap logic.
> Anyway this is mostly a cosmetic change: to revert it would just
> increase the universe entropy and no more
> 
> b) the minValueAfter, maxValueAfter change is the relevant one: to
> give those methods access to the full curve allows for much better
> bracketing of the solution. This is crucial (even when the curve
> previous state is an excellent guess) because the ineffective
> bracketing is currently the major issue slowing down the bootstrap.
> 
> One final note: if we were to agree on this interface change I would
> go further and add the ratehelpers in the new signatures: they might
> be used to improve guess and bracketing, even if I don't plan to use
> them anytime soon
> 
> What do you think about it, Luigi?
> Anyone else willing to contribute his feedback?
> 
> ciao -- Nando

-- 

Can't act. Slightly bald. Also dances. 
-- RKO executive, reacting to Fred Astaire's screen test. 
Cerf/Navasky, "The Experts Speak" 

Re: [Quantlib-dev] SwapIndex Calendar issue

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

Hi Luca,
	thanks for the heads-up.  I don't have a fix yet, but I'll let you know
when it's done.

Luigi


On Sat, 2011-06-18 at 09:44 -0400, Luca Billi wrote:
> I just found that when building a term structure from a USD Libor Swap
> Index and then re-evaluating the same Swap Index, the original quote
> is not always recovered.
> 
> This happens only on particular evaluation dates and it seems to be
> caused by a misalignment of the fixing calendars in the underlying
> swaps generated by the classes "SwapIndex" and "SwapRateHelper".
> 
> More precisely, the underlying swap in "SwapRateHelper" inherits the
> fixing calendar from the underlying "IborIndex" not from the
> "SwapIndex". In the case of USD, "IborIndex" and "SwapIndex" calendars
> are different.
> 
> Here's a code sample that illustrates the issue.
> Changing eDate to a different value makes the issue disappear.
> 
> 
> Date eDate(29, Dec, 2011);
> 
> Settings::instance().evaluationDate() = eDate;
> 
> double swaprate = 0.0500;
> Period term = 2*Years;
> 
> boost::shared_ptr<RateHelper> s2y(new SwapRateHelper(swaprate,
> 
> boost::shared_ptr<SwapIndex>(
>                                                            new
> UsdLiborSwapIsdaFixAm(term))));
> 
> std::vector<boost::shared_ptr<RateHelper> > instruments;
> instruments.push_back(s2y);
> 
> boost::shared_ptr<YieldTermStructure> curve(
>             new PiecewiseYieldCurve<Discount,LogLinear>(
>                                     0,
>                                     NullCalendar(),
>                                     instruments,
>                                     ActualActual(ActualActual::ISDA)));
> 
> std::cout << UsdLiborSwapIsdaFixAm(term,
> Handle<YieldTermStructure>(curve)).fixing(eDate) << std::endl;
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 

When I was a boy of fourteen, my father was so ignorant I could hardly 
stand to have the old man around. But when I got to be twenty-one, I 
was astonished at how much the old man had learned in seven years. 
-- Mark Twain 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[17886] trunk/QuantLib

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

> Just wondering if a method would be more explicit---e.g., something like
>
>  Schedule s = originalSchedule.until(d);
>
> might be more readable than
>
>  Schedule s(originalSchedule, d);
>
> Thoughs?

I considered this option and don't have a strong preference between the two.

I favored the constructor just because the QuantLibAddin mapping would
have been a constructor in both cases (as for all methods/functions
returning objects).

Feel free to change it as you prefer

ciao -- nando

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[17886] trunk/QuantLib

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

On Thu, 2011-07-14 at 14:57 +0000, na...@us... wrote:
> Revision: 17886
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=17886&view=rev
> Author:   nando
> Date:     2011-07-14 14:57:02 +0000 (Thu, 14 Jul 2011)
> 
> Log Message:
> -----------
> added truncated Schedule constructor (and removed unused private data member)

Just wondering if a method would be more explicit---e.g., something like

  Schedule s = originalSchedule.until(d);

might be more readable than

  Schedule s(originalSchedule, d);

Thoughs?

	Luigi


-- 

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

[Quantlib-dev] [ quantlib-Bugs-3366336 ] Error in Svensson Fitting Formula

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

Bugs item #3366336, was opened at 2011-07-13 22:42
Message generated for change (Tracker Item Submitted) made by wasix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3366336&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: Wasi (wasix)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in Svensson Fitting Formula

Initial Comment:
The zerorate calculation of the svensson discount function has an error:

109	        Real zeroRate = x[0] + (x[1] + x[2])*
110	                        (1.0 - std::exp(-kappa*t))/
111	                        ((kappa+QL_EPSILON)*(t+QL_EPSILON)) -
112	                        (x[2])*std::exp(-kappa*t) +
113	                        x[3]* (((1.0 - std::exp(-kappa*t))/((kappa_1+QL_EPSILON)*(t+QL_EPSILON)))- std::exp(-kappa_1*t));

in line 113 kappa is used instead of kappa_1

correct is this:
109	        Real zeroRate = x[0] + (x[1] + x[2])*
110	                        (1.0 - std::exp(-kappa*t))/
111	                        ((kappa+QL_EPSILON)*(t+QL_EPSILON)) -
112	                        (x[2])*std::exp(-kappa*t) +
113	                        x[3]* (((1.0 - std::exp(-kappa_1*t))/((kappa_1+QL_EPSILON)*(t+QL_EPSILON)))- std::exp(-kappa_1*t));



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

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

[Quantlib-dev] TrinomialTree: braching probabilities

[YuHong <hy...@ho...>]

I have been studying 'ql/methods/lattices/trinomialtree.cpp'.  About the branching probabilities, Hull&White in their papers mentioned three types of branchings.  May I ask, which among the three brachings with the probabilities have been implemented in QuantLib?  Thanks a lot!

Regards,

Hong Yu

 		 	   		  

Re: [Quantlib-dev] error message in testing QuantLib 1.1

[Dennis Z. <zhy...@gm...>]

Luigi, thanks for your explanation and it works as a charm. 

Thanks,
Dennis

[Quantlib-dev] Reg. Contributing

[Dexter M. <dmo...@gm...>]

Hi,

I am new to Quantlib. I have heard a lot about contributing to open-source
projects. But i do not have any prior experience.As i will be graduating
soon , in order to find a good job, i need to improve my skills and develop
unique skills like volunteering in open-source project. I have good
knowledge about the financial products and quantitative methods. Having
tried the examples, i got interested in contributing to the project.

Are there any "To-do" lists according to the difficulty level.

or any documents to help the new contributors like me.

Thanks in advance.

Regards,

dmoser

Re: [Quantlib-dev] error message in testing QuantLib 1.1

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

Hi Dennis,
	the warning C4819 is not a problem; the compiler is simply telling you
that there are non-ASCII characters in the source and that this might be
a problem (but actually it's not, because they're in the comments: we
acknowledge the author of the original code, that goes by the name of
Jäckel.  The umlaut is what's giving the compiler the fits.)

The actual linking error is unrelated, and is due to a mismatch of
settings between your project and the library you compiled.   The linker
is looking for QuantLib-vc90-mt-gd.lib, which is the debug version of
the library.  You might have compiled the release version, which has a
different name (you can check it in the c:\quantlib\quantlib-1.1\lib
folder.)  The thing should work once you compile your project in release
mode, too.

Luigi



On Mon, 2011-07-11 at 02:41 +0000, Dennis Zhang wrote:
> I am using QuantLib 1.1 and Boost 1.46 with VC++ 2008 on Win 7 Professional
> system. When I am trying to do the example TestingQuantLib at the following
> link, it failed by giving the error message below. Also when I build the
> QuantLib before running the example, error 4819 also exists but the build
> process is successful though.
> 
> may be it is more useful to post the error log here. I am sorry if this is
> bothering.
> 
> ...
> 1>c:\quantlib\quantlib-1.1\ql\math\randomnumbers\primitivepolynomials.h :
> warning C4819: The file contains a character that cannot be represented in the
> current code page (936). Save the file in Unicode format to prevent data loss
> ...
> 1>c:\quantlib\quantlib-1.1\ql\math\matrix.hpp(570) : warning C4996:
> 'std::transform': Function call with parameters that may be unsafe - this call
> relies on the caller to check that the passed values are correct. To disable
> this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use
> Visual C++ 'Checked Iterators'
> ...
> 1>Compiling manifest to resources...
> 1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
> 1>Copyright (C) Microsoft Corporation.  All rights reserved.
> 1>Linking...
> 1>LINK : fatal error LNK1104: cannot open file 'QuantLib-vc90-mt-gd.lib'
> 1>Build log was saved at "file://c:\Users\zhyp\Documents\Visual Studio
> 2008\Projects\TestingQuantLib\TestingQuantLib\Debug\BuildLog.htm"
> 1>TestingQuantLib - 1 error(s), 122 warning(s)
> ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
> 
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 

Debugging is twice as hard as writing the code in the first place. 
Therefore, if you write the code as cleverly as possible, you are, 
by definition, not smart enough to debug it. 
-- Brian W. Kernighan 

[Quantlib-dev] error message in testing QuantLib 1.1

[Dennis Z. <zhy...@gm...>]

Hi,

I am using QuantLib 1.1 and Boost 1.46 with VC++ 2008 on Win 7 Professional
system. When I am trying to do the example TestingQuantLib at the following
link, it failed by giving the error message below. Also when I build the
QuantLib before running the example, error 4819 also exists but the build
process is successful though.

may be it is more useful to post the error log here. I am sorry if this is
bothering.

...
1>c:\quantlib\quantlib-1.1\ql\math\randomnumbers\primitivepolynomials.h :
warning C4819: The file contains a character that cannot be represented in the
current code page (936). Save the file in Unicode format to prevent data loss
...
1>c:\quantlib\quantlib-1.1\ql\math\matrix.hpp(570) : warning C4996:
'std::transform': Function call with parameters that may be unsafe - this call
relies on the caller to check that the passed values are correct. To disable
this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use
Visual C++ 'Checked Iterators'
...
1>Compiling manifest to resources...
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>Linking...
1>LINK : fatal error LNK1104: cannot open file 'QuantLib-vc90-mt-gd.lib'
1>Build log was saved at "file://c:\Users\zhyp\Documents\Visual Studio
2008\Projects\TestingQuantLib\TestingQuantLib\Debug\BuildLog.htm"
1>TestingQuantLib - 1 error(s), 122 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

Re: [Quantlib-dev] error message in testing QuantLib 1.1

[Hong Y. <hy...@ho...>]

May I have an unhelpful comment: you referred to warnings, not errors.

Regards,

Hong Yu



-----Original Message----- 
From: Dennis Zhang
Sent: Monday, July 11, 2011 9:57 AM
To: qua...@li...
Subject: [Quantlib-dev] error message in testing QuantLib 1.1

Hi,

I am using QuantLib 1.1 and Boost 1.46 with VC++ 2008 on Win 7 Professional
system. When I am trying to do the example TestingQuantLib at the following
link, it failed by giving the error message below. Also when I build the
QuantLib before running the example, error 4819 also exists but the build
process is successful though.

1>c:\quantlib\quantlib-1.1\ql\currency.hpp : warning C4819: The file 
contains a
character that cannot be represented in the current code page (936). Save 
the
file in Unicode format to prevent data loss
1>c:\quantlib\quantlib-1.1\ql\math\array.hpp(227) : warning C4996: 
'std::copy':
Function call with parameters that may be unsafe - this call relies on the
caller to check that the passed values are correct. To disable this warning, 
use
-D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 
'Checked
Iterators'
1>        c:\program files (x86)\microsoft visual studio
9.0\vc\include\xutility(2576) : see declaration of 'std::copy' .......


I wonder if you have ever seen this before and I appreciate it if you can 
direct
me in solving the problem.

Thanks,
Dennis




------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev 

[Quantlib-dev] error message in testing QuantLib 1.1

[Dennis Z. <zhy...@gm...>]

Hi,

I am using QuantLib 1.1 and Boost 1.46 with VC++ 2008 on Win 7 Professional
system. When I am trying to do the example TestingQuantLib at the following
link, it failed by giving the error message below. Also when I build the
QuantLib before running the example, error 4819 also exists but the build
process is successful though.

1>c:\quantlib\quantlib-1.1\ql\currency.hpp : warning C4819: The file contains a
character that cannot be represented in the current code page (936). Save the
file in Unicode format to prevent data loss
1>c:\quantlib\quantlib-1.1\ql\math\array.hpp(227) : warning C4996: 'std::copy':
Function call with parameters that may be unsafe - this call relies on the
caller to check that the passed values are correct. To disable this warning, use
-D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked
Iterators'
1>        c:\program files (x86)\microsoft visual studio
9.0\vc\include\xutility(2576) : see declaration of 'std::copy' .......


I wonder if you have ever seen this before and I appreciate it if you can direct
me in solving the problem.

Thanks,
Dennis

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[17854] trunk/QuantLib/ql

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

On Thu, 2011-07-07 at 09:30 +0200, Luigi Ballabio wrote:
> On Wed, 2011-07-06 at 15:49 +0000, na...@us... wrote:
> > Log Message:
> > -----------
> > - introduced new define for compile-time parametrization of sticky/floating Settings evaluation date

Ouch.  Wrong reply button before coffee.  Sorry, folks.

Luigi


-- 

Quote me as saying I was misquoted. 
-- Groucho Marx 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[17854] trunk/QuantLib/ql

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

On Wed, 2011-07-06 at 15:49 +0000, na...@us... wrote:
> Log Message:
> -----------
> - introduced new define for compile-time parametrization of sticky/floating Settings evaluation date

Ma ti prego.  Hai introdotto una define dove basta settare la data, e
pure con un comportamento di default che da' sorprese.

Se proprio hai il problema di non chiamare funzioni volatili, queste
sono le cose per cui una ditta si tiene delle patch in casa invece di
basarsi sul tronco di un repository esterno...

Ci si,
	Luigi


-- 

Flon's Law: 
There is not now, and never will be, a language in 
which it is the least bit difficult to write bad programs. 

[Quantlib-dev] QuantLib: ql/termstructures/inflation/inflationtraits.hpp

[YuHong <hy...@ho...>]

Minor issue:

When I was compiling a sample program with QuantLib build from trunk-source, it complained missing header file 'ql/termstructures/inflation/inflationtraits.hpp'.

Therefore, I would suggest to add the header filename 'nflationtraits.hpp' to the 'Makefile.am' file under the  'QuantLib/ql/termstructures/inflation/' directory.

Hope the info helps.

Regards,

Hong Yu

 		 	   		  

Re: [Quantlib-dev] QuantLibAddIn: error from command 'make distclean': did not remove all 'Makefile'

[Hong Y. <hy...@ho...>]

My pleasure :)



-----Original Message----- 
From: Eric Ehlers
Sent: Tuesday, July 05, 2011 2:27 AM
To: YuHong
Cc: qua...@li...
Subject: Re: [Quantlib-dev] QuantLibAddIn: error from command 'make 
distclean': did not remove all 'Makefile'

Hello Hong Yu,

Quoting YuHong <hy...@ho...>:

> For this minor error, I have modified two 'Makefile.am' files, in  the 
> main directory and in the 'qlo/index/' directory respectively,  attached 
> as well.  Wish the info helpful to the project.

Many thanks, I will have a look and let you know how it goes.

Kind Regards,
Eric

Re: [Quantlib-dev] QuantLibAddIn: error from command 'make distclean': did not remove all 'Makefile'

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

Hello Hong Yu,

Quoting YuHong <hy...@ho...>:

> For this minor error, I have modified two 'Makefile.am' files, in  
> the main directory and in the 'qlo/index/' directory respectively,  
> attached as well.  Wish the info helpful to the project.

Many thanks, I will have a look and let you know how it goes.

Kind Regards,
Eric

Re: [Quantlib-dev] destructor performance, observables with large observer lists

[Peter C. <pca...@vo...>]

Thanks for thinking about it, first of all.

>the design of QuantLib never required that the Observers are to be
>notified in the order of registration

I agree. Just wanted to point out that if a potential bug shows up or not
depending on this order, it might be hard to reproduce (even on the same
machine as the example shows) and to locate.

>Observers will always have different (and immutable) pointers and it is
>not possible to "lose" an Observer from the set
...
>a hypothetical C++ runtime might keep track of all pointers to
>this block and change the pointers accordingly when the block's address
>changes and as we are using Observer*, the runtime will have to change the
>pointer to the Observer contained in the set

In order to have O(log size) complexity for std::set.find() the ordering
among the pointers stored in the set must be used by the implementation
(some binary search) and therefore must be invariant during the whole
execution. In your hypothetical runtime it is therefore enough to have p<q
at t1 and q<p at t2 for two pointers p, q stored in the set to loose a
pointer, i.e. not being able to find it any more. Unless the runtime will
not only adjust the pointers in the set, but also triggers the set to
"re-sort" its elements, which sounds unlikely to happen. But as we are
talking about a hypothetical runtime, this is most probably really not
relevant...

Thanks a lot, Peter

-----Ursprüngliche Nachricht-----
Von: Plamen Neykov [mailto:pla...@re...] 
Gesendet: Sonntag, 3. Juli 2011 03:21
An: qua...@li...
Cc: Peter Caspers
Betreff: Re: [Quantlib-dev] destructor performance, observables with large
observer lists

I guess, it is safe to say, that C++ (potentially with the exception of the
MS 
.NET managed C++), guarantees that the pointer to an allocated memory block 
(from the viewpoint of the loaded executable image) will never change during

the current execution of that image.
Further, it is guaranteed that the pointers to different memory blocks will 
always be different. In the context of std::set<Observer*>, this means that
two 
Observers will always have different (and immutable) pointers and it is not 
possible to "lose" an Observer from the set.

However, the pointer to a block allocated after another block might compare 
less than the pointer to the previously allocated block (this is an OS and 
runtime dependent behaviour). In our case here, this will only have as a 
consequence that the order of the notification of the registered observers
can 
not be determined - however, my impression was that the design of QuantLib 
never required that the Observers are to be notified in the order of 
registration.

(please note that I'm making here a distinction between the address and the 
pointer to a memory block - it is possible to imagine that the address might

change, but a hypothetical C++ runtime might keep track of all pointers to 
this block and change the pointers accordingly when the block's address 
changes and as we are using Observer*, the runtime will have to change the 
pointer to the Observer contained in the set and in the list so that your 
"notFound" case cannot occur - however I'm not aware of the existence of any

such C++ runtime)

Cheers,
Plamen

On Saturday 02 Jul 2011 19:44:19 Peter Caspers wrote:
> Though probably of marginal importance, I spent some further time in
> googling and experiments on the questions below.
> 
> I tried to stress the situation with the attached small test code. It has
3
> parameters one can play with (the #define's) and two outputs.
> 
> "notFound" counts pointers that are put in a set and not found later on.
If
> this number is not zero there is a serious problem. However I did not
> manage to provoke this on my environment, even with fat and/or many
> objects allocated.
> 
> "fingerprint" counts the number of subsequently allocated pointers p and q
> with not p < q. Different fingerprints (with same parameters) mean that
> code relying on the ordering of pointers may show non deterministic or
> system dependent behaviour. In fact I can produce different fingerprints
> with the same executable on my system e.g. by starting it from a shell
> (2755), from the IDE (3142) or double clicking in windows explorer (3193).
> Not very nice.
> 
> There might be real problems with the ordering of pointers on systems
> without virtualized memory allocation. Like on dos or win3.x, but this is
> not relevant any more for current systems, is it?
> 
> Finally the C99 standard actually does explicitly mention pointer
> comparision in 6.5.8.
> 
> Peter
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Peter Caspers [mailto:pca...@vo...]
> Gesendet: Sonntag, 26. Juni 2011 20:28
> An: 'Ferdinando Ametrano'
> Cc: 'qua...@li...'
> Betreff: RE: [Quantlib-dev] destructor performance, observables with large
> observer lists
> 
> Hi,
> 
> the main reason for the map<long,pointer> approach was to avoid using
> comparison between pointers, which is to my understanding comparison of
> memory addresses.
> 
> What if two objects pointed to do not stay in the same memory block for
> example? Is the behaviour still well defined then? Even if it works
> technically, program execution will probably depend on many things not
> covered by the language specifications. It may be hard to get reproducible
> results then?
> 
> Thank you and regards
> Peter
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Ferdinando Ametrano [mailto:na...@am...]
> Gesendet: Sonntag, 26. Juni 2011 18:58
> An: Plamen Neykov
> Cc: qua...@li...; lui...@gm...
> Betreff: Re: [Quantlib-dev] destructor performance, observables with large
> observer lists
> 
> On Sat, Jun 25, 2011 at 5:48 PM, Plamen Neykov
> 
> <pla...@re...> wrote:
> > wouldn't it be simpler just to use std::set<Observer*> and save you the
> 
> trouble with the long id or am I missing something here?
> 
> great minds think alike... as a matter of fact in the trunk it has
> already been switched to std:set on June 7th :-)
> 
> see
>
http://quantlib.svn.sourceforge.net/viewvc/quantlib?view=revision&revision=
> 1 7788
> 
> I was more concerned with possible non-unique elements than
> destructor's performance reason, and that's why I would keep it at
> std::set instead of having it as template parameter.
> 
> Roland could you confirm that the trunk solution is OK for you?
> 
> BTW in the current trunk there is a MAJOR performance improvement if
> you work in a real time environment with many changing rate quotes
> between recalculations: I patched a bug which triggered many useless
> notifications
> 
> thanks to all for the report and help: it's refreshing to have
> contributors really stressing the library.
> 
> ciao -- Nando
> 
>
---------------------------------------------------------------------------
> - --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] destructor performance, observables with large observer lists

[Plamen N. <pla...@re...>]

I guess, it is safe to say, that C++ (potentially with the exception of the MS 
.NET managed C++), guarantees that the pointer to an allocated memory block 
(from the viewpoint of the loaded executable image) will never change during 
the current execution of that image.
Further, it is guaranteed that the pointers to different memory blocks will 
always be different. In the context of std::set<Observer*>, this means that two 
Observers will always have different (and immutable) pointers and it is not 
possible to "lose" an Observer from the set.

However, the pointer to a block allocated after another block might compare 
less than the pointer to the previously allocated block (this is an OS and 
runtime dependent behaviour). In our case here, this will only have as a 
consequence that the order of the notification of the registered observers can 
not be determined - however, my impression was that the design of QuantLib 
never required that the Observers are to be notified in the order of 
registration.

(please note that I'm making here a distinction between the address and the 
pointer to a memory block - it is possible to imagine that the address might 
change, but a hypothetical C++ runtime might keep track of all pointers to 
this block and change the pointers accordingly when the block's address 
changes and as we are using Observer*, the runtime will have to change the 
pointer to the Observer contained in the set and in the list so that your 
"notFound" case cannot occur - however I'm not aware of the existence of any 
such C++ runtime)

Cheers,
Plamen

On Saturday 02 Jul 2011 19:44:19 Peter Caspers wrote:
> Though probably of marginal importance, I spent some further time in
> googling and experiments on the questions below.
> 
> I tried to stress the situation with the attached small test code. It has 3
> parameters one can play with (the #define's) and two outputs.
> 
> "notFound" counts pointers that are put in a set and not found later on. If
> this number is not zero there is a serious problem. However I did not
> manage to provoke this on my environment, even with fat and/or many
> objects allocated.
> 
> "fingerprint" counts the number of subsequently allocated pointers p and q
> with not p < q. Different fingerprints (with same parameters) mean that
> code relying on the ordering of pointers may show non deterministic or
> system dependent behaviour. In fact I can produce different fingerprints
> with the same executable on my system e.g. by starting it from a shell
> (2755), from the IDE (3142) or double clicking in windows explorer (3193).
> Not very nice.
> 
> There might be real problems with the ordering of pointers on systems
> without virtualized memory allocation. Like on dos or win3.x, but this is
> not relevant any more for current systems, is it?
> 
> Finally the C99 standard actually does explicitly mention pointer
> comparision in 6.5.8.
> 
> Peter
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Peter Caspers [mailto:pca...@vo...]
> Gesendet: Sonntag, 26. Juni 2011 20:28
> An: 'Ferdinando Ametrano'
> Cc: 'qua...@li...'
> Betreff: RE: [Quantlib-dev] destructor performance, observables with large
> observer lists
> 
> Hi,
> 
> the main reason for the map<long,pointer> approach was to avoid using
> comparison between pointers, which is to my understanding comparison of
> memory addresses.
> 
> What if two objects pointed to do not stay in the same memory block for
> example? Is the behaviour still well defined then? Even if it works
> technically, program execution will probably depend on many things not
> covered by the language specifications. It may be hard to get reproducible
> results then?
> 
> Thank you and regards
> Peter
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Ferdinando Ametrano [mailto:na...@am...]
> Gesendet: Sonntag, 26. Juni 2011 18:58
> An: Plamen Neykov
> Cc: qua...@li...; lui...@gm...
> Betreff: Re: [Quantlib-dev] destructor performance, observables with large
> observer lists
> 
> On Sat, Jun 25, 2011 at 5:48 PM, Plamen Neykov
> 
> <pla...@re...> wrote:
> > wouldn't it be simpler just to use std::set<Observer*> and save you the
> 
> trouble with the long id or am I missing something here?
> 
> great minds think alike... as a matter of fact in the trunk it has
> already been switched to std:set on June 7th :-)
> 
> see
> http://quantlib.svn.sourceforge.net/viewvc/quantlib?view=revision&revision=
> 1 7788
> 
> I was more concerned with possible non-unique elements than
> destructor's performance reason, and that's why I would keep it at
> std::set instead of having it as template parameter.
> 
> Roland could you confirm that the trunk solution is OK for you?
> 
> BTW in the current trunk there is a MAJOR performance improvement if
> you work in a real time environment with many changing rate quotes
> between recalculations: I patched a bug which triggered many useless
> notifications
> 
> thanks to all for the report and help: it's refreshing to have
> contributors really stressing the library.
> 
> ciao -- Nando
> 
> ---------------------------------------------------------------------------
> - --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] destructor performance, observables with large observer lists

[Peter C. <pca...@vo...>]

Though probably of marginal importance, I spent some further time in
googling and experiments on the questions below.

I tried to stress the situation with the attached small test code. It has 3
parameters one can play with (the #define's) and two outputs. 

"notFound" counts pointers that are put in a set and not found later on. If
this number is not zero there is a serious problem. However I did not manage
to provoke this on my environment, even with fat and/or many objects
allocated.

"fingerprint" counts the number of subsequently allocated pointers p and q
with not p < q. Different fingerprints (with same parameters) mean that code
relying on the ordering of pointers may show non deterministic or system
dependent behaviour. In fact I can produce different fingerprints with the
same executable on my system e.g. by starting it from a shell (2755), from
the IDE (3142) or double clicking in windows explorer (3193). Not very nice.

There might be real problems with the ordering of pointers on systems
without virtualized memory allocation. Like on dos or win3.x, but this is
not relevant any more for current systems, is it?

Finally the C99 standard actually does explicitly mention pointer
comparision in 6.5.8.

Peter


-----Ursprüngliche Nachricht-----
Von: Peter Caspers [mailto:pca...@vo...] 
Gesendet: Sonntag, 26. Juni 2011 20:28
An: 'Ferdinando Ametrano'
Cc: 'qua...@li...'
Betreff: RE: [Quantlib-dev] destructor performance, observables with large
observer lists

Hi,

the main reason for the map<long,pointer> approach was to avoid using
comparison between pointers, which is to my understanding comparison of
memory addresses.

What if two objects pointed to do not stay in the same memory block for
example? Is the behaviour still well defined then? Even if it works
technically, program execution will probably depend on many things not
covered by the language specifications. It may be hard to get reproducible
results then?

Thank you and regards
Peter


-----Ursprüngliche Nachricht-----
Von: Ferdinando Ametrano [mailto:na...@am...] 
Gesendet: Sonntag, 26. Juni 2011 18:58
An: Plamen Neykov
Cc: qua...@li...; lui...@gm...
Betreff: Re: [Quantlib-dev] destructor performance, observables with large
observer lists

On Sat, Jun 25, 2011 at 5:48 PM, Plamen Neykov
<pla...@re...> wrote:
> wouldn't it be simpler just to use std::set<Observer*> and save you the
trouble with the long id or am I missing something here?

great minds think alike... as a matter of fact in the trunk it has
already been switched to std:set on June 7th :-)

see
http://quantlib.svn.sourceforge.net/viewvc/quantlib?view=revision&revision=1
7788

I was more concerned with possible non-unique elements than
destructor's performance reason, and that's why I would keep it at
std::set instead of having it as template parameter.

Roland could you confirm that the trunk solution is OK for you?

BTW in the current trunk there is a MAJOR performance improvement if
you work in a real time environment with many changing rate quotes
between recalculations: I patched a bug which triggered many useless
notifications

thanks to all for the report and help: it's refreshing to have
contributors really stressing the library.

ciao -- Nando

----------------------------------------------------------------------------
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[17823] trunk/QuantLib/ql

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

> Sorry, it breaks backwards compatibility.  We'll have to think how to go
> about this, and it's ok to leave it for the time being, but it will have to
> be reverted.

mmm... I saw this coming, but wanted to give you a chance at being
less conservative :-)

jokes aside, let me add few points to think about:

1) I broke the backward compatibility of yield/credit/inflation
traits, but is there anyone using those traits decoupled from QuantLib
iterative bootstrap? Really hard to believe.. and if such a geek
exists, please speak up now!
Anyway I could add the old signature (deprecated) methods back along
with the new overloads: this would preserve backward compatibility,
but I see little point besides obfuscating the traits usage

2) my refactored iterative bootstrap does use the new traits methods,
and so I broke any proprietary traits used for bootstrapping
proprietary curves with QuantLib iterative bootstrap. Frankly I find
hard to believe that someone able to figure out how to write new
traits would have problems moving them to their new generalized
interface. It's much more likely that such a coder would consider the
huge speedup of the bootstrap worth the few minutes needed for adding
a curve pointer in the signature

As for the benefit of this refactoring:

a) the guess change is to separate guessing from iterative
boostrapping. To fully delegate guessing to the traits improves
dramatically the readability of the iterative bootstrap. In the
previous version of iterative bootstrap the guess logic intervened
badly with the bootstrap logic.
Anyway this is mostly a cosmetic change: to revert it would just
increase the universe entropy and no more

b) the minValueAfter, maxValueAfter change is the relevant one: to
give those methods access to the full curve allows for much better
bracketing of the solution. This is crucial (even when the curve
previous state is an excellent guess) because the ineffective
bracketing is currently the major issue slowing down the bootstrap.

One final note: if we were to agree on this interface change I would
go further and add the ratehelpers in the new signatures: they might
be used to improve guess and bracketing, even if I don't plan to use
them anytime soon

What do you think about it, Luigi?
Anyone else willing to contribute his feedback?

ciao -- Nando

[Quantlib-dev] Proposal to incorporate portfolio analytics

[Amir A. A. <phd...@ya...>]

Hi All,
 
I would like to propose the inclusion of portfolio optimization into Quantlib. First of all, a little dose of reality:
 
 
Current Landscape:
------------------------
 
As far as I know, portfolio optimization as it currently stands involves the maximization of the following function:
 
U = Alpha - Risk / RAP - Transaction Cost / Amortization - Taxes / Amortization - Penalties,
 
where Risk is computed from a multi-factor risk model.
 
Without naming names, here are two commercial approaches to tackling the problem:
 
1. 'Linearize' the risk component and the penalties component, then pose the problem as an integer programming problem and solve it through CPLEX. I have no idea how the linearization works but I have some intuitive hunches.
 
2. Utilize an iterative sub-gradient optimization procedure which tries to push the portfolio within the feasible region on each step by swapping a pair of securities.
 
If anyone knows about other ways, then I would love to hear about them.
 
Pros and Cons:
------------------
 
The proponents of approach 1 say the value of U from their method will usually best other industry approaches although they do not recommend using this approach when your problem is a simple non-constrained maximization problem. They say their approach can model arbitrarily complex constraints by linear piecewise approximation. I am not able to verify this, but my hunch is that any realistic linear piecewise approximation of a complex curve would slow down the algorithm. But note this is ONLY MY HUNCH.
 
Approach 2 can handle things like non-linear transaction costs in its stride. Unfortunately, the quadratic penalties can spoil the positive definiteness of the risk matrix and the algorithm would tend to converge on a local maxima. Even with the positive definiteness in tact, since the buy and sell amount has to be same on each iteration, the algorithm is limited to making 45 degree turns, which can again limit it to a local maxima on corners of the feasible region.
 
DISCLAIMER: The above discussion has been knowingly phrased in generic terms and contains only public domain knowledge. The intention is simply an open discussion to further the field. The intention is NOT to suggest one approach or the other or divulge internal/secret information. Any associaton with an actual company's product is the reader's own flight of fantasy. The author does not claim to be discussing any specific product.
 
Proposal:
-----------
 
We are not trying to mimick the behavior that is already there. So let us try and follow a third approach. We simply solve the linear inequalities to find a point within the feasible region. And then we proceed with either gradient ascent, OR the sub-gradient approach, ensuring on each iteration that we remain within the feasible region.
 
 
Would love to hear everybody's thoughts.
 
- Amir