quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] credit modeling, Issuer, etc.

[Jose Aparicio-N. <ja...@fr...>]

Hi Chris, all
With such a great tool is easy to copy/paste a calibrator in one evening. I
would take the code with a pinch of salt then...  :-)
Its not intended to be added to the lib as it is.

Rather than pricing a digital, which would left me with the problem of finding
data, I have first calibrated the most senior curve hazard rates with a flat
recovery and then switched to a recovery rate term structure calibration for
the remining sniorities.

What I have done is a shortcut to have quick numbers, this is not a
bootstrapping problem but a more complex optimization. A problem that this
library can tackle by the way.
I havent tried but I wonder if I had calibrated in a different order, i.e.
junior
flat RR first I would have obtained curves more often. The "flatteness" impossed
on the first calibration is a huge restriction.

Initially the curves were quoted with these RRs:
SNRFOR   0.4
SUBLT2   0.2
JRSUBUT2 0.2
PREFT1   0.15

Output for the example previously posted (inputs are in the source, it doesn't
dump, this is from the debugger):


	38831	39071	39253	39619	39986	40350	40714	41445	42541
	TODAY
	0.0017	0.0017	0.0031	0.0041	0.0069	0.0128	0.0127	0.0152	0.0221	HRs
		 6M	 1Y	 2Y	 3Y	 4Y	 5Y	 7Y	10Y
SNRFOR	0.9     0.9     0.9     0.9     0.9     0.9     0.9     0.9     0.9
RRs
SUBLT2	0.87    0.87	0.79	0.80	0.90	0.81	0.82	0.77	0.82	RRs
JRSUBUT2 0.82                           0.82            0.84            0.73	RRs
PREFT1	0.55                    0.55                    0.45    0.65    0.56	RRs

	38831	39071	39253	39619	39986	40350	40714	41445	42541
	TODAY
	0.0012	0.0012	0.0021	0.0027	0.0046	0.0085	0.0084	0.0101	0.0145	HRs
		 6M	 1Y	 2Y	 3Y	 4Y	 5Y	 7Y	10Y
SNRFOR	0.85	0.85	0.85	0.85	0.85	0.85	0.85	0.85	0.85	RRs
SUBLT2	0.81	0.81	0.68	0.70	0.85	0.71	0.73	0.65	0.73	RRs
JRSUBUT2 0.73				0.73		0.76		0.60	RRs
PREFT1	0.33			0.33			0.17	0.47	0.34	RRs

	38831	39071	39253	39619	39986	40350	40714	41445	42541
	TODAY
	0.0009	0.0009	0.0016	0.0021	0.0035	0.0064	0.0063	0.0076	0.0108	HRs
		 6M	 1Y	 2Y	 3Y	 4Y	 5Y	 7Y	10Y
SNRFOR	0.8	0.8	0.8	0.8	0.8	0.8	0.8	0.8	0.8	RRs
SUBLT2	0.75	0.75	0.58	0.61	0.80	0.62	0.63	0.53	0.64	RRs
JRSUBUT2 0.63				0.63		0.69		0.47	RRs
PREFT1	NO CALIBRATION								RRs


	38831	39071	39253	39619	39986	40350	40714	41445	42541
	TODAY
	0.0004	0.0004	0.0008	0.0010	0.0017	0.0032	0.0032	0.0038	0.0054	HRs
		 6M	 1Y	 2Y	 3Y	 4Y	 5Y	 7Y	10Y
SNRFOR	0.6	0.6	0.6	0.6	0.6	0.6	0.6	0.6	0.6	RRs
SUBLT2	0.50	0.50	0.15	0.21    0.60	0.23	0.27	0.07	0.27	RRs
JRSUBUT2 NO CALIBRATION          						RRs
PREFT1   NO CALIBRATION								RRs

	38831	39071	39253	39619	39986	40350	40714	41445	42541
	TODAY
	0.0003	0.0003	0.0005	0.0007	0.0012	0.0021	0.0021	0.0025	0.0036	HRs
		 6M	 1Y	 2Y	 3Y	 4Y	 5Y	 7Y	10Y
SNRFOR	0.4	0.4	0.4	0.4	0.4	0.4	0.4	0.4	0.4	RRs
SUBLT2	NO CALIBRATION								RRs
JRSUBUT2NO CALIBRATION   							RRs
PREFT1	NO CALIBRATION								RRs

This last case corresponds to the quoted data and the calibration fails since it
is
not possible to find a RR in the range 0-1 for those probabilities for the given
spread.

A back of envelope calc is possible, since we are freezing the probabilities if
we had one coupon only this would hold: RR_2 = 1-(1-RR_1) S_2/S_1
S_1 is the spread of the curve we use for HR calibration for that tenor and RR_1
is the flat RR.
if one uses this as an approximation RR_2 becomes negative around the points
where
the calibration fails. Since the helpers impose the domain [0-1] it does not cut
the axis.

Using the most junior as a digital (RR close to zero) I cant calibrate any of
the
RR curves unless I increase the RR. I interpret
this as due to the small number of points for that curve combined to the linear
interpolation in the HRs. I have to put this into a wsheet to play easily with
it.

----
The other subject was the data structure, am I the only one having a problem
with
a one to one reltaion between issuer and recovery? Shouldnt we have a
std::map<Seniority, Real-TS-model? > Issuer::recoveryRates and a method
Issuer::getRecovery(date,...) ? This does not include the currency though, since
it will get complex and we are not sure it would include every 'key' to index
the recovery rate. I agree that a class interface is the answer.

Shouldnt we also have (rather than a different engine) a digital flag for the
CDSs and the corresponding argument?

Another point that I think it was Simon who raised a few months ago is to
include the CDSs upfronts.

Regards
Pepe







Quoting Chris Kenyon <chr...@ya...>:

> Dear All,
>
> I'd like to start a bit of a discussion about credit modeling in QL given
> that it is starting to appear and that the credit crisis has done some very
> effective stress-testing of assumptions.  So I'll divide this into high-level
> and technical sections.
>
> High-Level
>
> Term structures are one of the fundamental things in QL, but I'm not sure
> that QL has the right ones for credit.  In the market I can trade a CDS and
> find quotes on Bloomberg.  However, I cannot directly trade a recovery rate
> (except OTC via digital default swaps, or recovery swaps as they are
> sometimes know).  Since the tradelable numbers should, IMNSHO, be fundamental
> QL needs:
>     CdsTermStructure
> and (maybe)
>     RecoveryRateTermStructure
> Only then can we get on with defining default probability term structures.
> Yes, you can argue that the CDS quotes themselves provide the term structure
> (if you add recoveries ...) ... but that is not the same as packaging this
> info up in a useful way.
>     Also, if you want an instrument-based probability of default term
> structure then you should give it recovery swaps as well as CDSs - giving it
> a recovery rate doesn't specify what observable it came from (assumptions
> anyone?).
>
> Technical
>
> The class Issuer currently holds a default probability term structure and a
> recovery rate.  However, if you look on Markit (or one of its competitors)
> then you see that a legal entity can have up to about 10 different CDS spread
> curves quoted - these come from different currencies, seniorities, and
> restructuring/default clauses.
>
> I suggest that the Issuer class should be polymorphic (i.e. lots of
> virtual's) and that it also inherit from Observer/Observable for ease of use
> with the rest of QL.  Then users can add as much complexity as they want for
> different situations.
>
> Well, that's my contribution to starting the dicussion ... all replies
> encouraged!
>
> Best regards,
> Chris

[Quantlib-dev] [ quantlib-Bugs-2617586 ] config error in CSharp SWIG extension for QuantLib_vc8.sln

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

Bugs item #2617586, was opened at 2009-02-19 15:02
Message generated for change (Settings changed) made by grantbirchmeier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2617586&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: Grant Birchmeier (grantbirchmeier)
Assigned to: Nobody/Anonymous (nobody)
>Summary: config error in CSharp SWIG extension for QuantLib_vc8.sln

Initial Comment:
Compiling the CSharp SWIG extension fails for vc8.  The following easy fix is needed:

For both BermudanSwaption_vc8 and EquityOption_vc8
1) right-click -> Properties -> Build Events
2) change
copy "$(SolutionDir)cpp\bin\vc80\$(ConfigurationName)\NQuantLibc.dll" "$(TargetDir)"
to 
copy "$(SolutionDir)csharp\bin\vc80\$(ConfigurationName)\NQuantLib.dll" "$(TargetDir)"

Notice the change from "cpp" to "csharp" and removing the "c" from NQuantLibc.dll.

Rebuild solution and it should compile cleanly.

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

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

[Quantlib-dev] [ quantlib-Bugs-2617586 ] error in CSharp SWIG extension for QuantLib_vc8.sln

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

Bugs item #2617586, was opened at 2009-02-19 15:02
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=2617586&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: Grant Birchmeier (grantbirchmeier)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in CSharp SWIG extension for QuantLib_vc8.sln

Initial Comment:
Compiling the CSharp SWIG extension fails for vc8.  The following easy fix is needed:

For both BermudanSwaption_vc8 and EquityOption_vc8
1) right-click -> Properties -> Build Events
2) change
copy "$(SolutionDir)cpp\bin\vc80\$(ConfigurationName)\NQuantLibc.dll" "$(TargetDir)"
to 
copy "$(SolutionDir)csharp\bin\vc80\$(ConfigurationName)\NQuantLib.dll" "$(TargetDir)"

Notice the change from "cpp" to "csharp" and removing the "c" from NQuantLibc.dll.

Rebuild solution and it should compile cleanly.

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

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

Re: [Quantlib-dev] Compilation problems with SUN CC

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

On Thu, 2009-02-19 at 16:34 +0100, Andreas Spengler wrote:
> > Using "-library=stlport4" (as needed for the compilation of boost, btw.)
> > solved the problem...
> 
> Well, quite; in some files, the math functions like pow have to be
> qualified with std::

Can you send me a list of those?

Thanks,
	Luigi


-- 

The most exciting phrase to hear in science, the one that heralds new 
discoveries, is not "Eureka!" but "That's funny..." 
-- Isaac Asimov 

Re: [Quantlib-dev] Compilation problems with SUN CC

[Andreas S. <an...@sp...>]

Es schrieb Andreas Spengler

> Using "-library=stlport4" (as needed for the compilation of boost, btw.)
> solved the problem...

Well, quite; in some files, the math functions like pow have to be
qualified with std::

STLport has no "using" statements to put those into the global namespace...

Rgds,

Andreas

Re: [Quantlib-dev] Compilation problems with SUN CC

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

On Thu, 2009-02-19 at 16:05 +0100, Andreas Spengler wrote:
> Using "-library=stlport4" (as needed for the compilation of boost, btw.)
> solved the problem...
> 
> Sorry for the fuss,

No problem.  It's good to know in case someone else stumbles into it.

Luigi



-- 

So little done, so much to do. 
-- Cecil Rhodes 

Re: [Quantlib-dev] Compilation problems with SUN CC

[Andreas S. <an...@sp...>]

Hi,

> std::vector is supposed to have a constructor taking two
> iterators but your compiler's STL implementation, apparently, does not
> provide it.

Appearantly, the SUN CC standard stl implementation is bollocks.

Using "-library=stlport4" (as needed for the compilation of boost, btw.)
solved the problem...


Sorry for the fuss,

Andreas

Re: [Quantlib-dev] Bates Engine for American Options

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

On Wed, 2009-02-18 at 22:04 -0800, uptotibet wrote:
> Hey Guys - I've looked through the list and was just wondering if anyone has
> used the Bates Model to price American Options?  I started down this path
> trying to find some connection for GARCH-based option pricing.  After a lot
> of meandering around, I realized I don't need "garch" per-se, but some type
> of stochastic volatility model.

Not that I know of.  The pieces might be there, though; you could fit a
Bates process onto a MCLongstaffSchwartzEngine.  You can probably use
MCAmericanEngine as an example of using Longstaff-Schwartz, and
MCEuropeanHestonEngine as an example of using a Heston or Bates process
for building a MonteCarlo.

Luigi


-- 

The purpose of abstraction is not to be vague, but to create a new 
semantic level in which one can be absolutely precise. 
-- W.E. Dijkstra 

Re: [Quantlib-dev] Compilation problems with SUN CC

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

On Thu, 2009-02-19 at 11:10 +0100, Andreas Spengler wrote:
> removing the "-template=wholeclass" switch now takes me through to the
> experimental subdir and dies at fdmstepconditioncomposite.cpp:
> 
> libtool: compile:  CC -DHAVE_CONFIG_H -I. -I. -I../../../ql -I../../..
> -I../../.. -I/home/spenglan/local/include/boost-1_38
> -erroff=wvarhidemem,hidevf,hidevfinvb,wbadinitl,badargtypel2w -errtags=yes
> -KPIC -features=rtti -instances=global -fast
> -library=Cstd,iostream,no%stlport4,Crun -xarch=v8plusa -fsimple=1 -mt
> -Drindex=rindex -Dindex=index -D__solaris_sparc__ -c
> fdmstepconditioncomposite.cpp  -KPIC -DPIC -o
> .libs/fdmstepconditioncomposite.o
> "fdmstepconditioncomposite.cpp", line 37: Error, nomatchoverin: Could not
> find a match for std::vector<double>::vector(__rwstd::__rb_tree<double,
> double, __rwstd::__ident<double, double>, std::less<double>,
> std::allocator<double>>::const_iterator, __rwstd::__rb_tree<double,
> double, __rwstd::__ident<double, double>, std::less<double>,
> std::allocator<double>>::const_iterator) needed in
> QuantLib::FdmStepConditionComposite::FdmStepConditionComposite(const
> std::list<std::vector<double> >&, const
> std::list<boost::shared_ptr<QuantLib::StepCondition<QuantLib::Array>> >&).
> 1 Error(s) and 4 Warning(s) detected.

std::vector is supposed to have a constructor taking two
iterators---which is called in the offending line, viz.

stoppingTimes_ = std::vector<Time>(allStoppingTimes.begin(),
                                   allStoppingTimes.end());

but your compiler's STL implementation, apparently, does not provide it.
(Which is a bit strange---how old is it?  May you check the <vector>
header?)  You can work around it by rewriting the above line, for
instance as:

stoppingTimes_ = std::vector<Time>();
std::copy(allStoppingTimes.begin(), allStoppingTimes.end(),
          std::back_inserter(stoppingTimes_));

or as an explicit loop that inserts into stoppingTimes_ all the elements
of allStoppingTimes---whatever you feel more comfortable with.

> I am a bit at my wits end here... Would it perhaps be possible to disable
> experimental code in the first place?

Possibly (it's might be a bit harder to disable it in the test-suite,
though) but you'll probably find calls to that constructor in the core
library, too.  You'll have to fix them in the same way.

Luigi


-- 

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

Re: [Quantlib-dev] Compilation problems with SUN CC

[Andreas S. <an...@sp...>]

Ok,

> I looked up this in the Sun compiler C++ user reference - and will try
> it out tomorrow:

removing the "-template=wholeclass" switch now takes me through to the
experimental subdir and dies at fdmstepconditioncomposite.cpp:

libtool: compile:  CC -DHAVE_CONFIG_H -I. -I. -I../../../ql -I../../..
-I../../.. -I/home/spenglan/local/include/boost-1_38
-erroff=wvarhidemem,hidevf,hidevfinvb,wbadinitl,badargtypel2w -errtags=yes
-KPIC -features=rtti -instances=global -fast
-library=Cstd,iostream,no%stlport4,Crun -xarch=v8plusa -fsimple=1 -mt
-Drindex=rindex -Dindex=index -D__solaris_sparc__ -c
fdmstepconditioncomposite.cpp  -KPIC -DPIC -o
.libs/fdmstepconditioncomposite.o
"../../../ql/math/array.hpp", line 544: Warning (Anachronism),
badargtype2w: Formal argument x of type double(*)(double) in call to
std::ptr_fun<double, double>(double(*)(double)) is being passed extern "C"
double(*)(double).
"../../../ql/math/array.hpp", line 551: Warning (Anachronism),
badargtype2w: Formal argument x of type double(*)(double) in call to
std::ptr_fun<double, double>(double(*)(double)) is being passed extern "C"
double(*)(double).
"../../../ql/math/array.hpp", line 558: Warning (Anachronism),
badargtype2w: Formal argument x of type double(*)(double) in call to
std::ptr_fun<double, double>(double(*)(double)) is being passed extern "C"
double(*)(double).
"../../../ql/math/array.hpp", line 565: Warning (Anachronism),
badargtype2w: Formal argument x of type double(*)(double) in call to
std::ptr_fun<double, double>(double(*)(double)) is being passed extern "C"
double(*)(double).
"fdmstepconditioncomposite.cpp", line 37: Error, nomatchoverin: Could not
find a match for std::vector<double>::vector(__rwstd::__rb_tree<double,
double, __rwstd::__ident<double, double>, std::less<double>,
std::allocator<double>>::const_iterator, __rwstd::__rb_tree<double,
double, __rwstd::__ident<double, double>, std::less<double>,
std::allocator<double>>::const_iterator) needed in
QuantLib::FdmStepConditionComposite::FdmStepConditionComposite(const
std::list<std::vector<double> >&, const
std::list<boost::shared_ptr<QuantLib::StepCondition<QuantLib::Array>> >&).
1 Error(s) and 4 Warning(s) detected.


I am a bit at my wits end here... Would it perhaps be possible to disable
experimental code in the first place?


Rgds,

Andreas

[Quantlib-dev] Bates Engine for American Options

[uptotibet <db...@ic...>]

Hey Guys - I've looked through the list and was just wondering if anyone has
used the Bates Model to price American Options?  I started down this path
trying to find some connection for GARCH-based option pricing.  After a lot
of meandering around, I realized I don't need "garch" per-se, but some type
of stochastic volatility model.

I want to be able to handle the skews on options more accurately for
portfolio optimizations.  I don't care about arbing this stuff, but I dont
want to get arbed - if that makes sense.


Any thoughts?
-- 
View this message in context: http://www.nabble.com/Bates-Engine-for-American-Options-tp22094505p22094505.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Compilation problems with SUN CC

[Andreas S. <an...@sp...>]

Hi Luigi,

Luigi Ballabio schrieb:

> Looking at your command line:
> 
>> libtool: compile:  CC -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../..
>> -I/home/spenglan/local/include/boost-1_38
>> -erroff=wvarhidemem,hidevf,hidevfinvb,wbadinitl,badargtypel2w -errtags=yes
>> -KPIC -features=rtti -template=wholeclass -instances=global -g -xs -fast
>> -library=rwtools7,iostream,no%stlport4,Crun -xarch=v8plusa -fsimple=1 -mt
>> -Drindex=rindex -Dindex=index -D__solaris_sparc__ -O3 -c
>> exchangeratemanager.cpp  -KPIC -DPIC -o .libs/exchangeratemanager.o
> 
> a likely candidate would be -template=wholeclass. I don't have a Solaris
> box available to check it, but if it tells the compiler to instantiate
> all methods in a template class instead of just the ones that are used,
> then it would cause the error above.  May you have a look at your
> compiler documentation and check whether the above works as I guessed
> (and if so, how can you specify the correct behavior instead?)

I should have guessed it. Unfortunately I somehow thought, that
memberwise comparison is added implicitly (like the copy constructor and
assignment operator are)...

I looked up this in the Sun compiler C++ user reference - and will try
it out tomorrow:

"When the compiler implicitly instantiates a template class, it
instantiates the static data members, the constructor, and the
destructor. However, the compiler does not implicitly instantiate any
other member function unless the function is explicitly referenced. To
force the compiler to instantiate all member functions when implicitly
instantiating a class, use the -template=wholeclass compiler option. To
turn this option off, specify -template=no%wholeclass, which is the
default."


Rgds,

Andreas

Re: [Quantlib-dev] Compilation problems with SUN CC

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

On Wed, 2009-02-18 at 17:03 +0100, Andreas Spengler wrote:
> I am trying to compile Quantlib on SUN Solaris 10 using SUN CC (I tried
> v5.7, v5.8 and v5.10, btw...)
> 
> Appearantly the SUN compiler is somehow missing operator== implementations
> for e.g. ExchangeRateManager, because I get the following error:
> 
> "/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list.cc", line 173: Error,
> badbinaryop: The operation "QuantLib::ExchangeRateManager::Entry == const
> QuantLib::ExchangeRateManager::Entry" is illegal.
> "/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list", line 468:    
> Where, temwhileinst: While instantiating
> "std::list<QuantLib::ExchangeRateManager::Entry>::remove(const
> QuantLib::ExchangeRateManager::Entry&)".

Andreas,
	the compiler does not generate operator==, but that's the expected
behavior.  The problem is that your compiler is trying to instantiate
list::remove, which requires an operator==.  But that's wrong, since
list::remove is not being used and hence should not be instantiated.

> Perhaps I am using a bad compiler switch.

Maybe. Looking at your command line:

> libtool: compile:  CC -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../..
> -I/home/spenglan/local/include/boost-1_38
> -erroff=wvarhidemem,hidevf,hidevfinvb,wbadinitl,badargtypel2w -errtags=yes
> -KPIC -features=rtti -template=wholeclass -instances=global -g -xs -fast
> -library=rwtools7,iostream,no%stlport4,Crun -xarch=v8plusa -fsimple=1 -mt
> -Drindex=rindex -Dindex=index -D__solaris_sparc__ -O3 -c
> exchangeratemanager.cpp  -KPIC -DPIC -o .libs/exchangeratemanager.o

a likely candidate would be -template=wholeclass. I don't have a Solaris
box available to check it, but if it tells the compiler to instantiate
all methods in a template class instead of just the ones that are used,
then it would cause the error above.  May you have a look at your
compiler documentation and check whether the above works as I guessed
(and if so, how can you specify the correct behavior instead?)

Luigi


-- 

I've finally learned what `upward compatible' means. It means we 
get to keep all our old mistakes. 
-- Dennie van Tassel 

[Quantlib-dev] Compilation problems with SUN CC

[Andreas S. <an...@sp...>]

Hi,

I am trying to compile Quantlib on SUN Solaris 10 using SUN CC (I tried
v5.7, v5.8 and v5.10, btw...)

Appearantly the SUN compiler is somehow missing operator== implementations
for e.g. ExchangeRateManager, because I get the following error:

libtool: compile:  CC -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../..
-I/home/spenglan/local/include/boost-1_38
-erroff=wvarhidemem,hidevf,hidevfinvb,wbadinitl,badargtypel2w -errtags=yes
-KPIC -features=rtti -template=wholeclass -instances=global -g -xs -fast
-library=rwtools7,iostream,no%stlport4,Crun -xarch=v8plusa -fsimple=1 -mt
-Drindex=rindex -Dindex=index -D__solaris_sparc__ -O3 -c
exchangeratemanager.cpp  -KPIC -DPIC -o .libs/exchangeratemanager.o

"/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list.cc", line 173: Error,
badbinaryop: The operation "QuantLib::ExchangeRateManager::Entry == const
QuantLib::ExchangeRateManager::Entry" is illegal.
"/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list", line 468:    
Where, temwhileinst: While instantiating
"std::list<QuantLib::ExchangeRateManager::Entry>::remove(const
QuantLib::ExchangeRateManager::Entry&)".
"/home/spenglan/SUNWspro/prod/include/CC/Cstd/./list", line 468:    
Where, teminstend: Instantiated from non-template code.
1 Error(s) detected.

Perhaps I am using a bad compiler switch.

When I add an operator== in Quantlib::ExchangeRateManager::Entry (doing
memberwise comparison), I get the same error above for
Quantlib::ExchangeRateManager

This can't be correct that the compiler does not generate implicit
operator== methods himself, right?

Rgds,

Andreas

[Quantlib-dev] [ quantlib-Bugs-1767957 ] make error

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

Bugs item #1767957, was opened at 2007-08-05 18:19
Message generated for change (Settings changed) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1767957&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: Out of Date
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Luigi Ballabio (lballabio)
Summary: make error

Initial Comment:
I am getting this error when making quantLib using cygwin: 
make[4]: Entering directory 
`/cygdrive/c/back_testing/quantLib/QuantLib-0.8.1/ql/indexes' 
/bin/sh ../../libtool --tag=CXX --mode=link g++  -g -O2 -Wall   
-L/usr/local/lib -o libIndexes.la   iborindex.lo indexman 
ager.lo interestrateindex.lo swapindex.lo ibor/libIborIndexes.la 
swap/libSwapIndexes.la 
rm -fr  .libs/libIndexes.lax 
rm -fr .libs/libIndexes.lax 
mkdir .libs/libIndexes.lax 
rm -fr .libs/libIndexes.lax/libIborIndexes.a 
mkdir .libs/libIndexes.lax/libIborIndexes.a 
(cd .libs/libIndexes.lax/libIborIndexes.a && ar x 
/cygdrive/c/back_testing/quantLib/QuantLib-0.8.1/ql/indexes/ibor/.libs 
/libIborIndexes.a) 
libtool: link: ERROR: object name conflicts: 
.libs/libIndexes.lax/libIborIndexes.a//cygdrive/c/back_testing/quantLib/Qua 
ntLib-0.8.1/ql/indexes/ibor/.libs/libIborIndexes.a 
make[4]: *** [libIndexes.la] Error 1 
make[4]: Leaving directory 
`/cygdrive/c/back_testing/quantLib/QuantLib-0.8.1/ql/indexes' 
make[3]: *** [all-recursive] Error 1 
make[3]: Leaving directory 
`/cygdrive/c/back_testing/quantLib/QuantLib-0.8.1/ql/indexes' 
make[2]: *** [all-recursive] Error 1 
make[2]: Leaving directory 
`/cygdrive/c/back_testing/quantLib/QuantLib-0.8.1/ql' 
make[1]: *** [all] Error 2 
make[1]: Leaving directory 
`/cygdrive/c/back_testing/quantLib/QuantLib-0.8.1/ql' 
make: *** [all-recursive] Error 1 

Configure seamed to work. This was the line to configure: 
./configure --with-boost-include=/usr/local/boost_1_34_1 
--with-boost-lib=/usr/local/lib --with-gnu-ld 




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

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

[Quantlib-dev] [ quantlib-Bugs-1830694 ] QuantLib::YieldTermStructure problem

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

Bugs item #1830694, was opened at 2007-11-12 22:42
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1830694&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: Wont Fix
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Luigi Ballabio (lballabio)
Summary: QuantLib::YieldTermStructure problem

Initial Comment:
Please, review attached file with compiler error.

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2009-02-17 11:03

Message:
You can try reducing the optimization level.
Other than that, the compiler doesn't give enough information for us to
make any sensible change.

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

Comment By: Luigi Ballabio (lballabio)
Date: 2007-11-13 18:12

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

It's a compiler bug. What compiler (including version) and operating
system are you using?


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

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

[Quantlib-dev] [ quantlib-Bugs-2477785 ] QuantLib fails to compile on vc++ 2003

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

Bugs item #2477785, was opened at 2008-12-30 22:58
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2477785&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: Wont Fix
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Luigi Ballabio (lballabio)
Summary: QuantLib fails to compile on vc++ 2003

Initial Comment:
c:\OpenSource\QuantLib-0.9.7\ql\money.cpp(201): fatal error C1001: INTERNAL COMPILER ERROR
        (compiler file 'msc1.cpp', line 2708) 
         Please choose the Technical Support command on the Visual C++ 
         Help menu, or open the Technical Support help file for more information

ojo...@pr...

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2009-02-17 11:00

Message:
You can try reducing the optimization level--or, as suggested, change Boost
version.
Other than that, the compiler doesn't give enough information for us to
make any sensible change.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-12 19:16

Message:
I had the same problem using boost 1.38 - just use an earlier version of
Boost and the problem disappears

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

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

[Quantlib-dev] [ quantlib-Bugs-2534054 ] Line 409: svd.cpp

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

Bugs item #2534054, was opened at 2009-01-25 00:57
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2534054&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: Wont Fix
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Luigi Ballabio (lballabio)
Summary: Line 409: svd.cpp

Initial Comment:
The comparison (I think) is against p-1, not p.

ks starts at p-1 and goes backwards so it can NEVER be equal to p anyway.

- Damian

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2009-02-17 10:57

Message:
It looks like an excess of caution.  The comparison against p is, I think,
so that we don't access the e array out of bounds. As you say, it's not
going to happen since ks starts at p-1. But it doesn't hurt either.

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

Comment By: Luigi Ballabio (lballabio)
Date: 2009-01-26 10:40

Message:
Do you mean line 309?

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

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

[Quantlib-dev] [ quantlib-Bugs-2340504 ] QuantLib fails to compile on Fedora 9

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

Bugs item #2340504, was opened at 2008-11-25 00:00
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2340504&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: Wont Fix
Priority: 5
Private: No
Submitted By: Patrick McEvoy (mccraic)
>Assigned to: Luigi Ballabio (lballabio)
Summary: QuantLib fails to compile on Fedora 9

Initial Comment:
Hello,

I am trying to compile QuantLib-0.9.7 on a Fedora 9 X86_64 box using gcc-4.3.0-8.x86_64 and gcc-c++-4.3.0-8.x86_64.  Everything compiles fine until I get the following error.  

Making all in test-suite
make[1]: Entering directory `Quantlib/QuantLib-0.9.7/test-suite'
if g++ -DHAVE_CONFIG_H -I. -I. -I../ql  -I.. -I.. -DQL_WORKING_BOOST_STREAMS   -g -O2 -Wall -MT riskstats.o -MD -MP -MF ".deps/riskstats.Tpo" -c -o riskstats.o riskstats.cpp; \
	then mv -f ".deps/riskstats.Tpo" ".deps/riskstats.Po"; else rm -f ".deps/riskstats.Tpo"; exit 1; fi
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
make[1]: *** [riskstats.o] Error 1
make[1]: Leaving directory `Quantlib/QuantLib-0.9.7/test-suite'
make: *** [all-recursive] Error 1
[root@R2T2 QuantLib-0.9.7]#

Any ideas on how to fix this?

Thanks,

Patrick

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2009-02-17 10:53

Message:
You can try reducing the optimization level.
Other than that, the compiler doesn't give enough information for us to
make any sensible change.

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

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

Re: [Quantlib-dev] building under x64

[Bojan N. <bo...@bn...>]

Hi Mark,

Mark joshi <mar...@gm...> writes:

> Ok I tried inserting
>
> template <>
>     class Null<Size> {
>       public:
>         Null() {}
>         operator Size() const { return Size(QL_NULL_INTEGER); }
>     };
>
> into null.hpp and it didn't help.

I guess you tried combining this with:

    //! template class providing a null value for a given type.
    template <class Type>
    class Null;

to check no further compilation errors come up? 

> As far as i can tell, the template specialization did nothing.

You should be able to just printing the Null value to check it is not
zero, i.e., std::cout<< Null<Size>();
c
Without a Windows setup this is now all guess work, but :

In termstructure.cpp:

> namespace QuantLib {
>
>     TermStructure::TermStructure(const DayCounter& dc)
>     : moving_(false),
>       updated_(true),
>       settlementDays_(Null<Size>()),
>       dayCounter_(dc) {}

Here we try to convert Size to Natural as settlementDays_ is declared Natural

>     TermStructure::TermStructure(const Date& referenceDate,
>                                  const Calendar& cal,
>                                  const DayCounter& dc)
>     : moving_(false), calendar_(cal),
>       referenceDate_(referenceDate), updated_(true),
>       settlementDays_(Null<Natural>()),
>       dayCounter_(dc) {}

Here we use Natural to assign to Natural

> 
> // rest of file

I would try replacing the first settlementDays_(Null<Size>()) with
settlementDays_(Null<Natural>())


Best,
Bojan

-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk

Re: [Quantlib-dev] building under x64

[Mark j. <mar...@gm...>]

Ok I tried inserting

template <>
    class Null<Size> {
      public:
        Null() {}
        operator Size() const { return Size(QL_NULL_INTEGER); }
    };

into null.hpp and it didn't help.

As far as i can tell, the template specialization did nothing.

Mark


2009/2/17 Mark joshi <mar...@gm...>:
> OK I tried Luigi's null.hpp
>
>  error C2514: 'QuantLib::Null<Type>' : class has no constructors
> 1>        with
> 1>        [
> 1>            Type=QuantLib::Size
> 1>        ]
>
>   Type=QuantLib::IntervalPrice
>    Type=QuantLib::Array
>
> These seem to be the only 3.
>
> WIN32 is defined for 32 bit projects so we could use it to test for 64
> bit, I guess.
>
> best
>
> mark
>
>
>
> 2009/2/16 Luigi Ballabio <lui...@gm...>:
>> On Mon, 2009-02-16 at 08:23 +0000, Bojan Nikolic wrote:
>>> If you are getting zeros as the NULL template values the most likely
>>> reason is that the template null hasn't been specialised for a type
>>> that is being used.
>>
>> True.  Mark, can you run a compilation after replacing
>> <ql/utilities/null.hpp> with the one I'm attaching?  You'll get a number
>> of errors saying that Null<T> is undefined for a few types.  I'm
>> interested in knowing for what built-in type(s) it fails.
>>
>> Also, is there any #define we can check to see if we're compiling for 64
>> bits?
>>
>> Luigi
>>
>> P.S. re the other 64-bit fix (atoi vs lexical_cast): it compiles, but it
>> changes behavior.  If the input is, say, "foo", lexical_cast raises an
>> exception, whereas atoi quietly returns 0.  I'd prefer a solution that
>> keeps the old behavior.
>>
>>
>> --
>>
>> The young man knows the rules, but the old man knows the exceptions.
>> -- O. W. Holmes
>>
>>
>
>
>
> --
> Quant Job Interview Questions and Answers is now out: www.markjoshi.com
>
> Assoc Prof Mark Joshi
> Centre for Actuarial Studies
> University of Melbourne
> My website is www.markjoshi.com
>



-- 
Quant Job Interview Questions and Answers is now out: www.markjoshi.com

Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

Re: [Quantlib-dev] building under x64

[Mark j. <mar...@gm...>]

OK I tried Luigi's null.hpp

 error C2514: 'QuantLib::Null<Type>' : class has no constructors
1>        with
1>        [
1>            Type=QuantLib::Size
1>        ]

   Type=QuantLib::IntervalPrice
    Type=QuantLib::Array

These seem to be the only 3.

WIN32 is defined for 32 bit projects so we could use it to test for 64
bit, I guess.

best

mark



2009/2/16 Luigi Ballabio <lui...@gm...>:
> On Mon, 2009-02-16 at 08:23 +0000, Bojan Nikolic wrote:
>> If you are getting zeros as the NULL template values the most likely
>> reason is that the template null hasn't been specialised for a type
>> that is being used.
>
> True.  Mark, can you run a compilation after replacing
> <ql/utilities/null.hpp> with the one I'm attaching?  You'll get a number
> of errors saying that Null<T> is undefined for a few types.  I'm
> interested in knowing for what built-in type(s) it fails.
>
> Also, is there any #define we can check to see if we're compiling for 64
> bits?
>
> Luigi
>
> P.S. re the other 64-bit fix (atoi vs lexical_cast): it compiles, but it
> changes behavior.  If the input is, say, "foo", lexical_cast raises an
> exception, whereas atoi quietly returns 0.  I'd prefer a solution that
> keeps the old behavior.
>
>
> --
>
> The young man knows the rules, but the old man knows the exceptions.
> -- O. W. Holmes
>
>



-- 
Quant Job Interview Questions and Answers is now out: www.markjoshi.com

Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

[Quantlib-dev] [ quantlib-Bugs-2599416 ] Failure to compile on ubuntu

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

Bugs item #2599416, was opened at 2009-02-14 12:11
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2599416&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: Failure to compile on ubuntu 

Initial Comment:
Hello,

  I am compiling QuantLib 0.9.7 on my ubuntu machine.
The procedure that I am running is:

$ tar zxvf QuantLib-0.9.7.tar.gz
$ cd QuantLib-0.9.7
$ ./configure
$ make

  but then I will get the following errors at the very ending of the compilation:

make[3]: Entering directory `/tmp/QuantLib-0.9.7/ql'
/bin/bash ../libtool --tag=CXX --mode=link g++  -g -O2 -Wall   -o libQuantLib.la -rpath /usr/local/lib -release 0.9.7 currency.lo default.lo discretizedasset.lo errors.lo exchangerate.lo exercise.lo index.lo interestrate.lo issuer.lo money.lo position.lo prices.lo settings.lo stochasticprocess.lo termstructure.lo timegrid.lo cashflows/libCashFlows.la currencies/libCurrencies.la experimental/libExperimental.la indexes/libIndexes.la instruments/libInstruments.la legacy/libLegacy.la math/libMath.la methods/libMethods.la models/libModels.la pricingengines/libPricingEngines.la processes/libProcesses.la quotes/libQuotes.la termstructures/libTermStructures.la time/libTime.la utilities/libUtilities.la
libtool: link: g++ -shared -nostdlib /usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.2.4/crtbeginS.o  .libs/currency.o .libs/default.o .libs/discretizedasset.o .libs/errors.o .libs/exchangerate.o .libs/exercise.o .libs/index.o .libs/interestrate.o .libs/issuer.o .libs/money.o .libs/position.o .libs/prices.o .libs/settings.o .libs/stochasticprocess.o .libs/termstructure.o .libs/timegrid.o  -Wl,--whole-archive cashflows/.libs/libCashFlows.a currencies/.libs/libCurrencies.a experimental/.libs/libExperimental.a indexes/.libs/libIndexes.a instruments/.libs/libInstruments.a legacy/.libs/libLegacy.a math/.libs/libMath.a methods/.libs/libMethods.a models/.libs/libModels.a pricingengines/.libs/libPricingEngines.a processes/.libs/libProcesses.a quotes/.libs/libQuotes.a termstructures/.libs/libTermStructures.a time/.libs/libTime.a utilities/.libs/libUtilities.a -Wl,--no-whole-archive  -L/usr/lib/gcc/i486-linux-gnu/4.2.4 -L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i486-linux-gnu/4.2.4/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib/crtn.o    -Wl,-soname -Wl,libQuantLib-0.9.7.so -o .libs/libQuantLib-0.9.7.so
collect2: ld returned 1 exit status
make[3]: *** [libQuantLib.la] Error 1
make[3]: Leaving directory `/tmp/QuantLib-0.9.7/ql'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/QuantLib-0.9.7/ql'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/QuantLib-0.9.7/ql'
make: *** [all-recursive] Error 1

The development environment that I am using is:

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)

  I have libboost installed, and the version is 1.34.1-4ubuntu3 (I install the ubuntu package)

  Any solutions?
  Thank you very much.

WONG Hang.
won...@gm...





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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-16 14:32

Message:
You are not getting an direct error message from the compiler / linker but
just a failure message.  Could you have other issues like bad ram?  Could
the compile have been killed for excessive ram usage?  Building QL is quite
demanding.

I don't think there is a reason it should not build on Ubuntu has the
Debian packages have built fine on a number of compiler and linker
releases.

Dirk (Debian maintainer for QL)

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

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

Re: [Quantlib-dev] building under x64

[Mark j. <mar...@gm...>]

I'll do some more experimenting tomorrow -- I did try specializing
Null for Size but this didn't seem to fix the problem...



2009/2/16 Luigi Ballabio <lui...@gm...>:
> On Mon, 2009-02-16 at 08:23 +0000, Bojan Nikolic wrote:
>> If you are getting zeros as the NULL template values the most likely
>> reason is that the template null hasn't been specialised for a type
>> that is being used.
>
> True.  Mark, can you run a compilation after replacing
> <ql/utilities/null.hpp> with the one I'm attaching?  You'll get a number
> of errors saying that Null<T> is undefined for a few types.  I'm
> interested in knowing for what built-in type(s) it fails.
>
> Also, is there any #define we can check to see if we're compiling for 64
> bits?
>
> Luigi
>
> P.S. re the other 64-bit fix (atoi vs lexical_cast): it compiles, but it
> changes behavior.  If the input is, say, "foo", lexical_cast raises an
> exception, whereas atoi quietly returns 0.  I'd prefer a solution that
> keeps the old behavior.
>
>
> --
>
> The young man knows the rules, but the old man knows the exceptions.
> -- O. W. Holmes
>
>



-- 
Quant Job Interview Questions and Answers is now out: www.markjoshi.com

Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

Re: [Quantlib-dev] 0.9.0 release branch

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

On Sun, 2009-02-15 at 12:46 -0800, uptotibet wrote:
> The same thing happens with WINDOWS6, VC9, BOOST 1.38, and QL-0.9.7.
> 
> Where could I find the trunk you are referring to or does this need more
> coding?

It does need more coding.

> I'll continue to investigate.

Yes, please do.

Luigi


-- 

I have yet to see any problem, however complicated, which, when you 
looked at it in the right way, did not become still more complicated. 
-- Poul Anderson