quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Question to the Leap function in the Date class

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

>        with this change, one need to link the binary Boost.Date library with
> QuantLib (whereas before this, the library only needed the Boost
> headers.)
>
> I might be fine with this if we used Boost.Date to implement most of our
> Date class, but I wouldn't introduce the dependency just for checking
> leap years beyond 2200...

I agree. I didn't notice the (auto-)linking.
Actually I jumped to this modification in the hope to trigger further
boostification, but this is another issue and would require a stronger
determination

ciao -- Nando

Re: [Quantlib-dev] market models code

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

On Wed, 2009-11-18 at 20:31 +1100, Mark joshi wrote:
> I would suggest sticking with valarray. We all know the issue with
> resizing now.

Ok.

Luigi


-- 

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

Re: [Quantlib-dev] market models code

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

I would suggest sticking with valarray. We all know the issue with
resizing now.

best

Mark


2009/11/18 Luigi Ballabio <lui...@gm...>:
> On Tue, 2009-11-17 at 20:09 +1100, Mark joshi wrote:
>> Well all that really needs to be done is changing all the valarrays I
>> changed to deques and timing the testsuite. The only slight subtlety
>> is that the argument orders tend to be different for valarrays.
>
> Ok, done.  I've run the market-model test cases.  On VC9, deque is about
> 1.5 % faster than vector (about 10 seconds out of 10 minutes) and
> valarray is 2.5% faster than deque (another 15 sec.)  Optimizations were
> as specified in release mode.
> With gcc and -O2, it makes hardly any difference in timing.
>
> So what do we do? Do we switch to deque?
>
> Luigi
>
>
> --
>
> The first thing we do, let's kill all the lawyers.
> -- W. Shakespeare, "King Henry VI, Part II"
>
>
>



-- 
Pricing exotic interest rate derivatives - The LIBOR Market Model in
QuantLib June 2009, London,
http://www.moneyscience.com/training/index.html

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

Re: [Quantlib-dev] market models code

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

On Tue, 2009-11-17 at 20:09 +1100, Mark joshi wrote:
> Well all that really needs to be done is changing all the valarrays I
> changed to deques and timing the testsuite. The only slight subtlety
> is that the argument orders tend to be different for valarrays.

Ok, done.  I've run the market-model test cases.  On VC9, deque is about
1.5 % faster than vector (about 10 seconds out of 10 minutes) and
valarray is 2.5% faster than deque (another 15 sec.)  Optimizations were
as specified in release mode.
With gcc and -O2, it makes hardly any difference in timing.

So what do we do? Do we switch to deque?

Luigi


-- 

The first thing we do, let's kill all the lawyers. 
-- W. Shakespeare, "King Henry VI, Part II" 

Re: [Quantlib-dev] FX Functions Code Contribution

[Dima <dim...@go...>]

Just wanted to add some news regarding the code above. We're documenting it
in a blog here:

http://www.mathfinance.de/forum/?p=346

The rest of the code will be discussed in upcoming discussions. Regards



2009/8/6 Luigi Ballabio <lui...@gm...>

> On Wed, 2009-08-05 at 15:10 +0200, Dima wrote:
> > I discussed it ages ago, but its finally finished. I've uploaded new
> > QuantLib code on www.longvega.com/FxFunctions.zip. [...] I'd be happy
> > to see it somewhere in the trunk soon,
> > so I can use it withing QuantLib.
>
> Dima,
>        thanks for the code.  I'll put it in the repository, but probably
> not
> so soon as I'm trying to stabilize the existing code for the 1.0
> release.  Your code will probably get in the trunk after that.
>
> Thanks again,
>         Luigi
>
>
> --
>
> fix, n.,v.
> What one does when a problem has been reported too many times
> to be ignored.
> -- the Jargon file
>
>
>

Re: [Quantlib-dev] market models code

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

Well all that really needs to be done is changing all the valarrays I
changed to deques and timing the testsuite. The only slight subtlety
is that the argument orders tend to be different for valarrays.

best

mark


2009/11/17 Luigi Ballabio <lui...@gm...>:
> On Tue, 2009-11-17 at 13:03 +1100, Mark joshi wrote:
>> I'll put it on the "todo" list which is rather large right now...
>
> If it's just trying the timing, I can do that (I'd settle the thing for
> the 1.0 release---I'm not in a big hurry, but sometime in the next month
> or so would be nice.)
>
> Luigi
>
>
> --
>
> Father's got the sack from the water-works
> For smoking of his old cherry-briar;
> Father's got the sack from the water-works
> 'Cos he might set the water-works on fire.
>
>
>



-- 
Pricing exotic interest rate derivatives - The LIBOR Market Model in
QuantLib June 2009, London,
http://www.moneyscience.com/training/index.html

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

Re: [Quantlib-dev] market models code

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

On Tue, 2009-11-17 at 13:03 +1100, Mark joshi wrote:
> I'll put it on the "todo" list which is rather large right now...

If it's just trying the timing, I can do that (I'd settle the thing for
the 1.0 release---I'm not in a big hurry, but sometime in the next month
or so would be nice.)

Luigi


-- 

Father's got the sack from the water-works 
For smoking of his old cherry-briar; 
Father's got the sack from the water-works 
'Cos he might set the water-works on fire. 

Re: [Quantlib-dev] market models code

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

I'll put it on the "todo" list which is rather large right now...


2009/11/16 Luigi Ballabio <lui...@gm...>:
> On Fri, 2009-11-13 at 21:52 +0100, Klaus Spanderen wrote:
>> I'm using deque<bool> as a drop-in replacement for vector<bool> because
>> deque<bool> is usually faster than vector<bool> (but needs more memory).
>
> deque looks good. Mark, would you try it out and see whether you get the
> same speed improvement as valarray?
>
> 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
>
>
>



-- 
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] Generalized Hull White model with non-constant parameters

[javit <ca...@vi...>]

1) The code is the same as in Sourceforge. Actually, in my sourceforge post,
I provided a link (not the source code) to my original message in the
quantlib-dev group.

For 3), I'm working on the copyright thing with our group manager. It's
going to take sometime. Meanwhile, I would like to tidy up the code and
write a good example case.

For 2), there is a concern. Sadruddin Rejeb and/or StatPro Italia srl didn't
refer to any material about the trinomial tree generation method used in the
code. Comparing to the documents I have used in coding, the trinomial tree
structures are different by observation. I need some information about the
trinomial tree generation method in the trinomialtree class. Or instead, I
may create another trinomialtree class. In either caser, it would be better
to know more about the current trinomialtree class.

Thank you,
Javit


Luigi Ballabio wrote:
> 
> On Tue, 2009-11-10 at 10:31 -0800, javit wrote:
>> I modified the Black-Karasinski and the Ornstein-Uhlenbcek classes to
>> build a
>> generalized Hull-White model with time-dependent drift and volatility
>> parameters. It consists of four files pasted at the bottom of this
>> message: 
>> GeneralizedOUprocess.hpp, 
>> GeneralizedOUprocess.cpp, 
>> GeneralizedHW.hpp and
>> GeneralizedHW.cpp. 
> 
> Thanks, Javit.  I'll add the files to the library as soon as I get some
> time.  I've a few questions, namely:
> 
> 1) are the files attached here the same as the ones in the Sourceforge
> patch tracker, or is one version more recent than the other?
> 
> 2) it would be nice to have a test case for the new classes to add to
> the test suite.  Do you think you can find some time to code it?
> 
> 3) and finally, there's the usual matter of copyright attribution.
> Should the copyright be attributed to you or your company (if any?)
> And if you're not self-employed, are you sure that your company is ok
> with you contributing code?
> 
> Later,
> 	Luigi
> 
> 
> -- 
> 
> Hanlon's Razor: 
> Never attribute to malice that which is adequately explained 
> by stupidity. 
> 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and focus
> on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> 


-----
Cavit (Javit) Hafizoglu
mailto:jav...@su... mailto:jav...@su... 
-- 
View this message in context: http://old.nabble.com/Generalized-Hull-White-model-with-non-constant-parameters-tp26287370p26378558.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Question to the Leap function in the Date class

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

On Wed, 2009-10-21 at 11:50 +0200, Ferdinando Ametrano wrote:
> I suggest you to just replace the current implementation with
> 
> #include <boost/date_time/gregorian/gregorian.hpp>
> [...]
>    bool Date::isLeap(Year y) {
>        return boost::gregorian::gregorian_calendar::is_leap_year(y);
>    }
> [...]
> 
> I will commit this change unless objections are raised

Nando,
	with this change, one need to link the binary Boost.Date library with
QuantLib (whereas before this, the library only needed the Boost
headers.)

I might be fine with this if we used Boost.Date to implement most of our
Date class, but I wouldn't introduce the dependency just for checking
leap years beyond 2200...

Luigi



-- 

I hate quotations. 
-- Ralph Waldo Emerson 

Re: [Quantlib-dev] Generalized Hull White model with non-constant parameters

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

On Tue, 2009-11-10 at 10:31 -0800, javit wrote:
> I modified the Black-Karasinski and the Ornstein-Uhlenbcek classes to build a
> generalized Hull-White model with time-dependent drift and volatility
> parameters. It consists of four files pasted at the bottom of this message: 
> GeneralizedOUprocess.hpp, 
> GeneralizedOUprocess.cpp, 
> GeneralizedHW.hpp and
> GeneralizedHW.cpp. 

Thanks, Javit.  I'll add the files to the library as soon as I get some
time.  I've a few questions, namely:

1) are the files attached here the same as the ones in the Sourceforge
patch tracker, or is one version more recent than the other?

2) it would be nice to have a test case for the new classes to add to
the test suite.  Do you think you can find some time to code it?

3) and finally, there's the usual matter of copyright attribution.
Should the copyright be attributed to you or your company (if any?)
And if you're not self-employed, are you sure that your company is ok
with you contributing code?

Later,
	Luigi


-- 

Hanlon's Razor: 
Never attribute to malice that which is adequately explained 
by stupidity. 

Re: [Quantlib-dev] market models code

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

On Fri, 2009-11-13 at 21:52 +0100, Klaus Spanderen wrote:
> I'm using deque<bool> as a drop-in replacement for vector<bool> because 
> deque<bool> is usually faster than vector<bool> (but needs more memory).

deque looks good. Mark, would you try it out and see whether you get the
same speed improvement as valarray?

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 

Re: [Quantlib-dev] market models code

[Dominick S. <dsa...@De...>]

I discovered this odd property of valarray just weeks ago.

In his book Bjarne Stroustrup says the C++ standard on
valarray gives compiler writers much latitude so that they can use
tricks behind the scenes to speed up code.

Thus there may be a reason for this madness.

This is too bad, because valarray gives a nice way to do vector
processing and selecting (using valarray<bool>). Unfortunately,
you need to know how many items will be selected before the
code is run that does the selection! This greatly reduces the
utility and elegance of the approach.

Dominick

Mark joshi wrote:
> Ok you've convinced me that valarray is bad. I hate classes where =
> doesn't do what you expect!
>
> vector<bool> is bad too.
>
> Maybe we should be using a boost class for arrays of bools.
>
> best
>
> mark
>
>
> 2009/11/13 Luigi Ballabio <lui...@gm...>:
>   
>> On Tue, 2009-11-10 at 14:07 +1100, Mark joshi wrote:
>>     
>>> as you'll have noticed I've been doing some fiddling with the market
>>> models code.
>>>       
>> Mark,
>>        just for future reference: when using gcc, the test suite was failing
>> hard (access violations and such.)  It turns out that according to the C
>> ++ standard, the valarray assignment operator is only required to work
>> when the two sides of the assignment have the same size (yes, one never
>> ends learning C++.)   More details in the standard and at
>> <http://groups.google.com/group/comp.lang.c
>> ++/browse_thread/thread/b9ac323fd7f5578b/dba133d7b15e91e0?hl=en&ie=UTF-8>.
>>
>> Therefore, when one writes
>>
>> valarray<Foo> v1;
>> v1 = some_function();
>>
>> where some_function returns a (presumably not empty) valarray, the
>> behavior is undefined (the above effectively occurs, for instance, when
>> a valarray data member is initialized in the constructor body.)  Visual
>> C++ tries to help the average programmer and does what one would expect
>> (i.e., resize v1 and copy.)  Instead, gcc silently ignore the assignment
>> so that v1 ends up still empty.  You say it's kind of snob of gcc? My
>> reaction exactly.  Well, my second reaction.  The first involved a lot
>> of cursing.
>>
>> Conclusion: I committed a few changes to keep the code portable.
>> Basically, one has to include a few valarray.resize() calls before
>> assignment. Unfortunately, we'll have to keep that in mind when we write
>> new valarray code.
>>
>> Luigi
>>
>>
>> P.S. About the MarketModel example: please whistle in my general
>> direction when it's done, so I can backport it to the 1.0 branch.
>> Thanks.
>>
>>
>>
>> --
>>
>> I'd never join any club that would have the likes of me as a member.
>> -- Groucho Marx
>>
>>
>>
>>     
>
>
>
>   

Re: [Quantlib-dev] market models code

[Klaus S. <kl...@sp...>]

Hi Mark,

On Friday 13 November 2009 21:01:57 Mark joshi wrote:
> Ok you've convinced me that valarray is bad. I hate classes where =
> doesn't do what you expect!
>
> vector<bool> is bad too.
>
> Maybe we should be using a boost class for arrays of bools.

I'm using deque<bool> as a drop-in replacement for vector<bool> because 
deque<bool> is usually faster than vector<bool> (but needs more memory).

cheers 
 Klaus

Re: [Quantlib-dev] market models code

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

Ok you've convinced me that valarray is bad. I hate classes where =
doesn't do what you expect!

vector<bool> is bad too.

Maybe we should be using a boost class for arrays of bools.

best

mark


2009/11/13 Luigi Ballabio <lui...@gm...>:
> On Tue, 2009-11-10 at 14:07 +1100, Mark joshi wrote:
>> as you'll have noticed I've been doing some fiddling with the market
>> models code.
>
> Mark,
>        just for future reference: when using gcc, the test suite was failing
> hard (access violations and such.)  It turns out that according to the C
> ++ standard, the valarray assignment operator is only required to work
> when the two sides of the assignment have the same size (yes, one never
> ends learning C++.)   More details in the standard and at
> <http://groups.google.com/group/comp.lang.c
> ++/browse_thread/thread/b9ac323fd7f5578b/dba133d7b15e91e0?hl=en&ie=UTF-8>.
>
> Therefore, when one writes
>
> valarray<Foo> v1;
> v1 = some_function();
>
> where some_function returns a (presumably not empty) valarray, the
> behavior is undefined (the above effectively occurs, for instance, when
> a valarray data member is initialized in the constructor body.)  Visual
> C++ tries to help the average programmer and does what one would expect
> (i.e., resize v1 and copy.)  Instead, gcc silently ignore the assignment
> so that v1 ends up still empty.  You say it's kind of snob of gcc? My
> reaction exactly.  Well, my second reaction.  The first involved a lot
> of cursing.
>
> Conclusion: I committed a few changes to keep the code portable.
> Basically, one has to include a few valarray.resize() calls before
> assignment. Unfortunately, we'll have to keep that in mind when we write
> new valarray code.
>
> Luigi
>
>
> P.S. About the MarketModel example: please whistle in my general
> direction when it's done, so I can backport it to the 1.0 branch.
> Thanks.
>
>
>
> --
>
> I'd never join any club that would have the likes of me as a member.
> -- Groucho Marx
>
>
>



-- 
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-Patches-2897358 ] Generalized Hull White model with non-constant parameters

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

Patches item #2897358, was opened at 2009-11-13 17:38
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=2897358&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: Generalized Hull White model with non-constant parameters

Initial Comment:
Generalized Hull White model with non-constant parameters
I modified the Black-Karasinski and the Ornstein-Uhlenbcek classes to build a generalized Hull-White model with time-dependent drift and volatility parameters. It consists of four files pasted at the bottom of this message: 
GeneralizedOUprocess.hpp, 
GeneralizedOUprocess.cpp, 
GeneralizedHW.hpp and 
GeneralizedHW.cpp. 

These files need an addition/modification to the parameter class. Change the NoConstraint() condition in PiecewiseConstantParameter class to PositiveConstraint(). Or define another class in the parameter.hpp and name it PiecewiseConstantParameter2. This is how I did it. I changed the code in PiecewiseConstantParameter class 

from -------- 
     public: 
        PiecewiseConstantParameter(const std::vector<Time>& times) 
        : Parameter(times.size()+1, 
                    boost::shared_ptr<Parameter::Impl>( 
                                 new PiecewiseConstantParameter2::Impl(times)), 
                    NoConstraint()) 
to ---------- 
     public: 
        PiecewiseConstantParameter2(const std::vector<Time>& times) 
        : Parameter(times.size(), 
                    boost::shared_ptr<Parameter::Impl>( 
                                 new PiecewiseConstantParameter2::Impl(times)), 
                    PositiveConstraint()) 

You will obviously nedd to make some changes to the paths in the include commands. 

I would like these to be added to the quantlib library in the future. Please let me know what you think and also what I should do to make it a non-experimental contribution. 

Thank you, 
Javit 

Please follow this link for the source : 
http://old.nabble.com/Generalized-Hull-White-model-with-non-constant-parameters-td26287370.html



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

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

Re: [Quantlib-dev] doc comment in Poisson distribution

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

On Wed, 2009-11-11 at 19:20 +0100, Jose Aparicio-Navarro wrote:
> silly one really but the short Doxygen doc for the class PoissonDistribution
> states it is the Normal distribution function.

Fixed, thanks.

Luigi


-- 

There are no rules of architecture for a castle in the clouds. 
-- Gilbert K. Chesterton 

Re: [Quantlib-dev] market models code

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

On Tue, 2009-11-10 at 14:07 +1100, Mark joshi wrote:
> as you'll have noticed I've been doing some fiddling with the market
> models code.

Mark,
	just for future reference: when using gcc, the test suite was failing
hard (access violations and such.)  It turns out that according to the C
++ standard, the valarray assignment operator is only required to work
when the two sides of the assignment have the same size (yes, one never
ends learning C++.)   More details in the standard and at
<http://groups.google.com/group/comp.lang.c
++/browse_thread/thread/b9ac323fd7f5578b/dba133d7b15e91e0?hl=en&ie=UTF-8>.

Therefore, when one writes

valarray<Foo> v1;
v1 = some_function();

where some_function returns a (presumably not empty) valarray, the
behavior is undefined (the above effectively occurs, for instance, when
a valarray data member is initialized in the constructor body.)  Visual
C++ tries to help the average programmer and does what one would expect
(i.e., resize v1 and copy.)  Instead, gcc silently ignore the assignment
so that v1 ends up still empty.  You say it's kind of snob of gcc? My
reaction exactly.  Well, my second reaction.  The first involved a lot
of cursing.

Conclusion: I committed a few changes to keep the code portable.
Basically, one has to include a few valarray.resize() calls before
assignment. Unfortunately, we'll have to keep that in mind when we write
new valarray code.

Luigi


P.S. About the MarketModel example: please whistle in my general
direction when it's done, so I can backport it to the 1.0 branch.
Thanks.



-- 

I'd never join any club that would have the likes of me as a member. 
-- Groucho Marx 

Re: [Quantlib-dev] Prerelease tarballs : Change in HestonModelHelper

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

On Thu, 2009-11-12 at 08:50 -0800, javit wrote:
> I believe you would agree that developers shouldn't rewrite/debug their codes
> for every new release.

Yes, sorry.  But for some reason (probably because I remembered your
name from some previous posts) I assumed you had followed the discussion
here in the past few months.  My mistake.  For this release (the 0.9.9,
leading to 1.0) we decided to leave backward compatibility and to fix a
number of design issues that we felt were just wrong.  From 1.0 onwards,
backward compatibility will be maintained.  Apologies for the problems
this may cause, but as we approached 1.0 we felt it was better not to
take forward too much of our cruft...

Luigi



-- 

The young man knows the rules, but the old man knows the exceptions. 
-- O. W. Holmes 

Re: [Quantlib-dev] Prerelease tarballs : Change in HestonModelHelper

[javit <ca...@vi...>]

I believe you would agree that developers shouldn't rewrite/debug their codes
for every new release. Instead of replacing the last variable in
HestonModelHelper and changing  it to

      HestonModelHelper(const Period& maturity,
                          const Calendar& calendar,
                          const Real s0,
                          const Real strikePrice,
                          const Handle& volatility,
                          const Handle<YieldTermStructure>& riskFreeRate,
                          const Handle<YieldTermStructure>& dividendYield,
                          CalibrationHelper::CalibrationErrorType errorType
                                    =
CalibrationHelper::RelativePriceError);

The last variable might very well be added rather than being a replacement.
If it were an additional optional variable, then old codes utilizing
quantlib may work without adjustments. From your message, I understood that
backwards compatibility is not fully-respected by newer quantlib releases.
Actually, this is not something new, I observed similar incompabilities in
quantlibxl. Maybe, I shouldn't have complained about it now.

Thank you,
Javit


Luigi Ballabio wrote:
> 
> On Tue, 2009-11-10 at 14:02 -0800, javit wrote:
>> I'm currently using 9.7. HestonModelHelper is not working due to code
>> change.
>> 
>> Erase the last variable in your HestonModelHelper and it works fine.
> 
> I'm confused. Of course code written for 0.9.7 won't work with the
> latest tarballs. May you elaborate?
> 
> Luigi
> 
> 
> -- 
> 
> Hofstadter's Law: 
> It always takes longer than you expect, even when you take 
> Hofstadter's Law into account. 
> 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and focus
> on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> 


-----
Cavit (Javit) Hafizoglu
mailto:jav...@su... mailto:jav...@su... 
-- 
View this message in context: http://old.nabble.com/Prerelease-tarballs-tp26027318p26322172.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Update version of experimental/mcbasket

[Klaus S. <kl...@sp...>]

Hi

can you do me a favour and send me your ql/experimental/mcbasket directory as 
a tar-ball? (the diff doesn't work out on my machine here.).

thanks

Klaus 

On Monday 09 November 2009 14:34:24 Andrea wrote:
> On 11/10/09 19:46, Andrea wrote:
> > 1) it currently skips all paths that give a non positive exercise value.
> > this because it assumes the continuation value will always be positive,
> > and there is no point to accept a negative exercise. it might not be the
> > case always and it is hard to dynamically detect this lower bound (0.0).
> > so the payoff has a function to return the lower bound of the
> > continuation value or -INF if absent
>
> It is actually possible to dynamically detect what an out of the money
> option is. Since we go backward, we just remember what the lowest payoff
> is, and never exercise if the early termination value is less or equal to
> that value.
>
> In this updated version of the mcbasket experimental patch, I've
> implemented it. In my (simple) tests it worked properly.

[Quantlib-dev] doc comment in Poisson distribution

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

Hi,
silly one really but the short Doxygen doc for the class PoissonDistribution
states it is the Normal distribution function.

Best Regards
pp

Re: [Quantlib-dev] gensrc support for valarray

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

On Wed, Nov 11, 2009 at 10:44 AM, Mark joshi <mar...@gm...> wrote:
> sorry about this.

no reason to be sorry. While having a broad overview is appreciated,
nobody is requested to be master of everything. Such glitches on the
trunk are to be expected.

IMO the only stringent requirement is to never break the test-suite

ciao -- Nando

[Quantlib-dev] gensrc support for valarray

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

Dear All,

sorry about this.

The reason I did it is that vector<bool> is specialized to be
optimized for efficient storage -- this results in very inefficient
access.

best

Mark


-------------------------------------------------------
Date: Wed, 11 Nov 2009 07:49:19 +0000
From: "Plamen Neykov" <pla...@re...>
Subject: Re: [Quantlib-dev] gensrc support for valarray
To: "Ferdinando Ametrano" <na...@am...>, "QuantLib developers"
       <qua...@li...>
Cc: Eric Ehlers <eri...@gm...>,
       pla...@us...
Message-ID:
       <185...@bd...>

Content-Type: text/plain; charset="Windows-1252"

I'll put it in - will be done today or tomorrow - hope that's ok?
------Original Message------
From: Ferdinando Ametrano
To: QuantLib developers
Cc: Eric Ehlers
Cc: pla...@us...
Subject: [Quantlib-dev] gensrc support for valarray
Sent: 10 Nov 2009 17:26

Hi all

the latest commit on the trunk from Mark broke QLXL as there is no
support in gensrc for valarray.
While I've been able to manually code an easy workaround this of
course isn't satisfactory, but I have little idea how to add valarray
support.
Any volunteer ?

ciao -- Nando

Re: [Quantlib-dev] Prerelease tarballs : Change in HestonModelHelper

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

On Tue, 2009-11-10 at 14:02 -0800, javit wrote:
> I'm currently using 9.7. HestonModelHelper is not working due to code change.
> 
> Erase the last variable in your HestonModelHelper and it works fine.

I'm confused. Of course code written for 0.9.7 won't work with the
latest tarballs. May you elaborate?

Luigi


-- 

Hofstadter's Law: 
It always takes longer than you expect, even when you take 
Hofstadter's Law into account.