Warming up for 0.3.5

[Luigi Ballabio-2]

Hi all,
        it'd be nice to roll out release 0.3.5 sometime during March  
(you know, spring and all that :)
What is the status? Is anybody working (or about to work) on something  
he'd like to finish before the 0.3.5 branch is created?

Later,
        Luigi

[Ferdinando M. Ametrano-3]

At 10:27 AM 2/13/2004, Luigi Ballabio wrote:
>         it'd be nice to roll out release 0.3.5 sometime during March
It's ok with me. I would go for a freeze in late February or early March,
with target release date late March.

>What is the status?
Few tests fail with Borland because of some 0/0 in the code.
The same (?) tests fail with Visual C++ if _controlfp(_EM_INEXACT, _MCW_EM
) is enforced (see
http://www.wilmott.com/messageview.cfm?catid=10&threadid=9481)
I think we should solve this issue.

There are 3 open bugs:
http://sourceforge.net/tracker/?group_id=12740&atid=112740
The last one it's easy to fix, the first two are open since April and
September 2002 :(

There are also 2 feature requests
(http://sourceforge.net/tracker/?group_id=12740&atid=362740): the first one
will stay open for a long time, what about the second one?

>  Is anybody working (or about to work) on something
>he'd like to finish before the 0.3.5 branch is created?
Yes, I would like to finish few things about interpolation I was working
on. Of course should it take longer than the end of February it will ship
in 0.3.6

For 0.3.5 I would prefer not to ship binaries. My idea is that QuantLib is
for quantitative developers that must be able to recompile the library, and
should be able to compile and run the test suite. What do you think about it?

I will try to upgrade the Win32 installer to NSIS 2

If I got it right boost is going to be optional for 0.3.5. I for one vote
to have it as requirement for 0.3.6: if everybody agree we should make
clear that 0.3.5 is transitional toward boost. BTW Luigi: any chance about
using the boost test suite instead of cppunit? Have you ever compared the
two approaches?

Last but not least the multi-dimensional Monte Carlo simulation framework
should probably be labelled as beta for the time being, at least until it
is proven to work with Brownian Bridge + low discrepancy sequences

ciao -- Nando

[Luigi Ballabio-2]

On 2004.02.16 10:25, Ferdinando Ametrano wrote:
> For 0.3.5 I would prefer not to ship binaries. My idea is that  
> QuantLib is for quantitative developers that must be able to  
> recompile the library, and should be able to compile and run the test  
> suite. What do you think about it?

I second that. As a matter of fact, I've been arguing that for quite  
some time :)

> If I got it right boost is going to be optional for 0.3.5. I for one  
> vote to have it as requirement for 0.3.6: if everybody agree we  
> should make clear that 0.3.5 is transitional toward boost.

Yes, that was the idea.

> BTW Luigi: any chance about using the boost test suite instead of  
> cppunit? Have you ever compared the two approaches?

Yes, I've been looking at the boost test framework for another project.  
It should be relatively painless to switch.

Later,
        Luigi

[Liguo Song]

On Mon, 16 Feb 2004, Luigi Ballabio wrote:

> On 2004.02.16 10:25, Ferdinando Ametrano wrote:
> > For 0.3.5 I would prefer not to ship binaries. My idea is that  
> > QuantLib is for quantitative developers that must be able to  
> > recompile the library, and should be able to compile and run the test  
> > suite. What do you think about it?
>
> I second that. As a matter of fact, I've been arguing that for quite  
> some time :)
RPM source package should be OK, right? It is just that managing
installation and upgrade is much easier with RPM. Recompiling and
running test suite is all part of the source RPM.

[Luigi Ballabio-2]

On 2004.02.17 00:47, Liguo Song wrote:
> RPM source package should be OK, right?

Yes, they should. However, I'll make the usual test tarball before  
release. We can check at that time.

Later,
        Luigi

[Luigi Ballabio-2]

On 2004.02.16 10:25, Ferdinando Ametrano wrote:
> At 10:27 AM 2/13/2004, Luigi Ballabio wrote:
>>         it'd be nice to roll out release 0.3.5 sometime during March
> It's ok with me. I would go for a freeze in late February or early  
> March, with target release date late March.

Hi all,
        it might be time for a quick check.

>> What is the status?
> Few tests fail with Borland because of some 0/0 in the code.
> The same (?) tests fail with Visual C++ if _controlfp(_EM_INEXACT,  
> _MCW_EM ) is enforced (see  
> http://www.wilmott.com/messageview.cfm?catid=10&threadid=9481)
> I think we should solve this issue.

Hmm. Tricky. One should run the tests in the debugger until he finds  
the division by zero. But I'm not sure that I have the time to do it  
right now. Unless someone volunteers to tackle it, it's going to be  
fixed in the release after this one.

What I would do in any case is add a list of known bugs to the  
distribution.

> There are 3 open bugs:  
> http://sourceforge.net/tracker/?group_id=12740&atid=112740
> The last one it's easy to fix, the first two are open since April and  
> September 2002 :(

Ditto. Known bugs---except for the Veteran Day thing which is small  
enough.

> There are also 2 feature requests  
> (http://sourceforge.net/tracker/?group_id=12740&atid=362740): the  
> first one will stay open for a long time, what about the second one?

Well, what can I say? The mere thought of automatically replacing  
double with Real throughout fill me with dread :)

Were I to do it, at least I would use the occasion to go through the  
class interfaces and check whether a given double should be replaced  
with a generic Real or a more specific Rate, DiscountFactor, Spread,  
Volatility (do we have this one?) or whatever. Then I could set loose  
an automatic replace on the remaining doubles (those inside method and  
function bodies.)

But this takes time too, so it would probably be done best bit by bit.  
Needless to say, it wouldn't be done for this release :)

> Last but not least the multi-dimensional Monte Carlo simulation  
> framework should probably be labelled as beta for the time being, at  
> least until it is proven to work with Brownian Bridge + low  
> discrepancy sequences

Ok for me.

Thoughts? Any other issue? When should we create the 0.3.5 branch?

Later,
        Luigi