quantlib-users Mailing List for QuantLib (Page 621)

Hi all,

At 11:11 AM 12/21/00 +0100, Gilbert Peffer wrote:
>There is a bug in the date::isLeap member function. The impact though is
>minimal:
>
>A year is a leap year if it is dividable by 4, EXCEPT if it is dividable by
>100. Additionally, if it is dividable by 400, it is a leap year again.
>
>Thus 1900 and 2100 are not leap years.
>
>Although this won't possibly have an impact on any calculation, they are
>things people (users) love to check out.

Gilbert,
         sorry. We were aware of the thing, but we should have remembered 
to document it.
We knew that 1900 and 2100 aren't leap years - the problem is, the two most 
widely used spreadsheets around (Excel and Applix) both think that 1900 is.
Propagating such bug into our code was the quick and dirty method we chose 
to correctly interpret the serial numbers passed by such spreadsheets in 
view of a possible future Excel or Applix add-in based on QuantLib.
However, I now personally think that we should have the right thing into 
our library, and move this correction into the external layer reading from 
the spreadsheets - expecially since we don't have any such thing yet.

As usual, any ideas are welcome.

Bye for now,
                 Luigi

Hi,
There is a bug in the date::isLeap member function. The impact though is
minimal:

A year is a leap year if it is dividable by 4, EXCEPT if it is dividable by
100. Additionally, if it is dividable by 400, it is a leap year again.

Thus 1900 and 2100 are not leap years.

Although this won't possibly have an impact on any calculation, they are
things people (users) love to check out.

Gilbert

Hi all

Gilbert wrote:
 > Please send me your suggestions so I can put a
 > draft together
my 0.2$ on programming styles

92. Replace Doc++ with Doxygen

>>87. I prefer to stack the arguments
>>
>>     runThisRoutine (int     numNodes,             // Number of nodes
>>                     int*    connectivityList) {   // Elements connectivites
>>         blah blah
>>     }
>>
>>so one can comment each of the arguments individually.
>We might be forced to follow the Doxygen requirements here, if we want 
>such comments to be extracted and put into the documentation. The Doxygen 
>comment block would look like:
>
>     /*! \brief short description of the method
>         \param numNodes         number of nodes
>         \param connectivityList elements connectivities
>         \return description of the returned value
>     */
I would follow Doxygen requirements. Then argument stacking is probably 
redundant, but it doesn't hurt

 > 90) We'll have to stick to /* ... */ when comments
 > are to be extracted by Doxygen.
Doxygen rules.


 > 17) ok for employee.setName(). However, employee.getName() seems a
 > bit redundant to me - employee.name() is just as clear.
 > Unfortunately this would conflict with 6) since name() is not a
 > verb (well, not in this case).
I prefer the set/get symmetry. This do not conflict with 6 ;-)

>>38. ...TABs should be avoided.
>Actually I though that inserting real tab characters instead of spaces 
>allowed people to set the indentation to the number they like without 
>conflicting with others... am I missing something obvious here?
The 80 column limit cannot allow for different TABs.
I would join Luigi and Gilbert in the "4 spaces" club


I agree on all the following statement:

 > 5) I'd prefer enumerations inside classes and static const class
 > variables in mixed case starting with lower case.

 > 24. I usually use <num>, but <no> is as good. One may as well permit both

>36. [...] we can move the body of the methods outside the class 
>definition. Of course they will stay in the header file for them to be 
>inlined. One forced exception are template methods of a non-template 
>class, which VC++ won't compile unless they are declared inside the class.

 > 49) I would make an exception for static const variables,
 > for which I see no reason for access through a get() method.

 > 70) I like better example 1 for classes and functions too.

 > 73. I prefer the SUN recommendation, but this has no big impact
 > anyway, I think

 > 83) f (x) looks very strange to me with the space in the middle.


ciao -- Nando

Hi all,

At 11:58 AM 12/20/00 +0100, Gilbert Peffer wrote:
>36. This is currently in contradiction to some of the code in Quantlib. I
>myself are not too consistent in this particular style case. What do you
>think?

I'm not that consistent myself - mostly out of laziness. But we can move 
the body of the methods outside the class definition. Of course they will 
stay in the header file for them to be inlined. One forced exception are 
template methods of a non-template class, which VC++ won't compile unless 
they are declared inside the class.

An additional thought: not cluttering the header with such inlined bodies 
is somehow less of an issue, as the Doxygen-generated documentation for the 
class has a clearer layout than the header file itself...

>38. ...TABs should be avoided. Does anybody have an idea of the real impact
>the use of TABs can have?

Actually I though that inserting real tab characters instead of spaces 
allowed people to set the indentation to the number they like without 
conflicting with others... am I missing something obvious here?

>87. I would like to add a suggestion for function/subroutine definitions.
>For long argument lists (and for short ones as well), I prefer to stack the
>arguments
>
>     runThisRoutine (int     numNodes,             // Number of nodes
>                     int     numElements,          // Number of elements
>                     double* coordinateSet,        // Nodal coordinates
>                     int*    connectivityList) {   // Elements connectivites
>         blah blah
>     }
>
>so one can comment each of the arguments individually. Unless somebody has a
>strong objection about this (I guess it is a style choice one has to get
>used to) I wouldn't mind seeing it implemented in Quantlib

We might be forced to follow the Doxygen requirements here, if we want such 
comments to be extracted and put into the documentation. The Doxygen 
comment block would look like:

     /*! \brief short description of the method
         \param numNodes         number of nodes
         \param numElements      number of elements
         \param coordinateSet    nodal coordinates
         \param connectivityList elements connectivities
         \return description of the returned value
     */
    double runThisRoutine (int numNodes, int numElements,
                            double* coordinateSet, int* connectivityList) {
         blah blah
     }

Bye,
         Luigi

Peter

I'm unable to reach you at pe...@sc...

please get in touch

ciao -- Nando

Salut Gilbert,

On Die, 19 Dez 2000, you wrote:
>Some headaches I had using templates:
>A few months ago, I wrote some C++ template code using STL templates (which
>in turn contained nested templates). I had problems looking at the value of
>the variables in my Visual C++ debugger because some of the templates were
>resolved into over 20 lines or so. Perhaps I didn't find the option that
>would allow me to collapse the expanded template name into something more
>managable. If there isn't, then templates can make your debugging life much
>more difficult.
>Regards
>Gilbert

I normally create pointer - debug-variables poiting to &(*iterator).
Then you can access the members. Annoying, but it works.

Or, although I'm developping a lot in MS VS 6.0, I often port
it my sources to GCC/Linux fjust or Debugging templated Code with DDD.

Best wishes
Peter 

Hello,

>At 07:18 PM 12/18/00 +0100, Ferdinando Ametrano wrote:
[...]
>Furthermore, if different array classes - possibly including sparse ones - 
>or different operator classes  - tridiagonal, band diagonal, sparse, you 
>name it - are to be derived from base classes, then it is very likely that 
>we will have to declare as virtual even very basic functionalities (i.e., 
>operator[]) which tend to get in the innermost loops of the code and get 
>called humongous number of times. Now, while it is true that virtual calls 
>are cheap nowadays, it is also true that precious few optimizers inline 
>them. A simple algorithm for multiplying a matrix and a vector would either:
>a) be written in a generic way, in which case it would jump in and out the 
>respective operator[] for most of the time, which will add up to quite a 
>loss in efficiency, or
>b) be specialized for the concrete operators and array - however, this 
>would need double dispatching, which is not easier to write and maintain 
>than templates.
Yes, I agree, that expression templates are a nice and efficient way for
Linear algebra. But, there the rules are simple: You need an () or [] operator.
And I do like the STL library.

But I have to agree to Bernd Wuebbens point c):
> c) considerable porting headaches.

In 1997 had heavily templated sources which went to SGI, NEC, Cray just because
their compiler couldn't compile my sources. SGI (and now Cray) works now.
MS C++ 6.0 and gcc 2.95.2 still can't.
If you ever want to run your library on a dinosauror (large vector machines),
heavily templated code will kill you, or wait 10 years for their compilers to
catch up. That's  just a hint.
The main problem is partial template specialization and the non-generic
template instantiation mechanism.

Best wishes
Peter

 ________________________________________
Dr. Peter Schmitteckert / IT-Consulting
s-mail:	Fridolinstr. 19, 68753 Waghäusel
Web:	http://www.schmitteckert.com
e-mail:	su...@sc...
Tel.:	07254/951896

Hi there,
I have read through the C++ Programming Style Guidelines, and thought that,
with a few exceptions (in addition to those posted by Luigi yesterday), all
the rules were acceptable. The ones where I have some comments are:

22. I often call variable or object containers <set>, although for a
mathematical purist, this can provoke considerable grief

24. I usually use <num>, but <no> is as good. One may as well permit both

36. This is currently in contradiction to some of the code in Quantlib. I
myself are not too consistent in this particular style case. What do you
think?

38. ...TABs should be avoided. Does anybody have an idea of the real impact
the use of TABs can have?

69. I prefer 4 spaces

73. I prefer the SUN recommendation, but this has no big impact anyway, I
think

87. I would like to add a suggestion for function/subroutine definitions.
For long argument lists (and for short ones as well), I prefer to stack the
arguments

    runThisRoutine (int     numNodes,             // Number of nodes
                    int     numElements,          // Number of elements
                    double* coordinateSet,        // Nodal coordinates
                    int*    connectivityList) {   // Elements connectivites
        blah blah
    }

so one can comment each of the arguments individually. Unless somebody has a
strong objection about this (I guess it is a style choice one has to get
used to) I wouldn't mind seeing it implemented in Quantlib

That's about it. Please send me your suggestions so I can put a draft
together

Best regards

Gilbert

Hi Bernd and all

>d) diminished transparence as only few understand templates well
>     enough.
>I am particularly concerned by d), as it is
>hard enough to find people who know how to write pricers, it is
>even harder to find those who also are well versed in C++ and
>templates. The use of templates  will raise the barriers of entry
>amoung students, academics and practitioners alike.
We've been through this discussion a couple of time in RiskMap.
We (finally?) agreed that QuantLib should be a 3 level project:
1) core base
2) pricing code
3) end user interface

I will give an (incomplete) example. Let's consider this first level statement:
FiniteDifferenceModel<CrankNicolson<TridiagonalOperator> > 
myModel(theOperator);

[where theOperator is the tridiagonal discretization of BS equation]

It's scaring, I agree. The presence of that line of code in 
bsmamericanoption.cpp is highly unsatisfactory. This is because the second 
level is not ready yet.
The second level design is sketched in the same bsmamericanoption.cpp.
We will have a Model class implementing a common interface (rollBack(), 
etc.) and somewhere in the first level there will be:
template <class Evolver>
class FiniteDifferenceModel : public Model {
}

typedef FiniteDifferenceModel<CrankNicolson<TridiagonalOperator> > BsmModel;

At this point, you can declare
Handle<Model> myModel(new BsmModel(gridSize));
[the safe equivalent of:
  Model* myModel = new BsmModel(gridSize);
]

Now - in the second level - the Model interface will remove all 
implementation details (binomial, trinomial, finite difference) away and 
will provide a common interface for any model. This will work for BDT, BK, 
HW, etc. too, giving you the ability to write pricing code with pluggable 
Model. Switching from one model to another will be very easy.
No template programming will be needed either.

The third level is the end user interface. Here I'm thinking about 
scripting languages, MATLAB, Octave, Excel, applications that can be 
written on QuantLib.
We will have to design an object interface for the environments supporting 
objects and function interface for the others.
In the third level should be still possible to write pricing code (I'm 
especially thinking of Python): of course this code will be inefficient, 
but good enough for prototyping or not-demanding application.

ciao -- Nando

Hi Bernd (and all the others),

At 03:26 PM 12/19/00 -0500, you wrote:

>Hi Luigi,
>         We have all read the text books and now about the
>conceptual advanges of templates.

Ok, I'll keep it shorter next time :)

>What I am concerned about is
>
>a) performance hit

This is a pro for templates.

>b) significant bloat

And this is a con. They cancel out in my opinion.

>c) considerable porting headaches.

This should be less of a problem as time goes by and compilers improve. 
We're talking standard C++ after all... and anyway, I'm afraid the 
headaches will be more on the Win side - I'm told g++ is well ahead of 
other competitors as far as compliance goes. However: I'm aware of the 
problem, and of the fact the compilers won't uniform for a while. But I 
don't think there is an infinite number of possibilities to mess things up 
- I mean, I think we'll have a relatively small number of generic 
techniques to fix porting problems, so that it shouldn't be hard to master 
them.

>d) diminished transparence as only few understand templates well
>     enough.
>
>         These issues must be weight against the beauty of
>programming using templates. In the end I tend to decide to
>do what is best for the user, and not what is most convenient
>for the programmer. I am particularly concerned by d), as it is
>hard enough to find people who know how to write pricers, it is
>even harder to find those who also are well versed in C++ and
>templates. The use of templates  will raise the barriers of entry
>amoung students, academics and practitioners alike.

I agree. But as I said: there's only half of the framework in place now. 
The outer layer will be a base class (let us say Model) from which 
FiniteDifferenceModel inherits. Pricers will be written in terms of the 
Model interface, which means that one can use either our finite difference 
framework and benefit from it if he can, or write his own model class 
inherited from Model without using templates. You're free to choose what 
techniques to use: the power and complexity of templates, or the ease of 
dynamic polymorphism. The _complete_ framework will accept either one.

I am aware that this is the second mail in which I call to my rescue this 
supposed complete framework which nobody ever saw. Well, I must admit I 
didn't see it either :) Unfortunately we have a few deadlines at the 
moment, so that I don't have much time to set it up. However, I hope I did 
make the basic idea clear, so that it can be taken into account.

Thanks again for your patience,

                         Luigi

Hi Luigi,
	We have all read the text books and now about the
conceptual advanges of templates. If I could I would use them
all day, but I don't and that is for issues of practical software
engineering not because I am not fully aware of the many 
advantages they afford from a theoretical point of view.
What I am concerned about is

a) performance hit
b) significant bloat
c) considerable porting headaches.
d) diminished transparence as only few understand templates well 
    enough. 

	These issues must be weight against the beauty of 
programming using templates. In the end I tend to decide to 
do what is best for the user, and not what is most convenient
for the programmer. I am particularly concerned by d), as it is
hard enough to find people who know how to write pricers, it is
even harder to find those who also are well versed in C++ and 
templates. The use of templates  will raise the barriers of entry
amoung students, academics and practitioners alike.

	However, this is just my opinion and nothing more,
you guys should do what you like best, this is a free software 
project after all, and we want to have fun. However, I just 
thought I  should make sure that we realize  what the trade 
off's are.

Best,
Bernd


On Tuesday 19 December 2000 10:50, you wrote:
> At 07:18 PM 12/18/00 +0100, Ferdinando Ametrano wrote:
> >>Initial impressions:
> >>
> >>         I am unhappy about the heavy use of templates and the stl. Its
> >> going to bite you on many platforms (guys there is a whole world out
> >> there apart from Macs and Windows machines...) and the bloat is going to
> >> be considerable.
> >
> >Luigi will reply to this one.
>
> Here I am. Of course you're right about compiler support (we already had
> quite a few headaches because of this) and about the bloat. I am also aware
> that, as Peter Schmitteckert wrote,
>
> >for a library, I prefer virtual classes/functions to achieve conveniency
> >and flexibility. You can extend classes with virtual function, withouot
> >recompiling or changing the interface. With templates you can't (normally)
> > not. ...and remember, virtual fuctions are just a pointer-derefencation,
> > and that's cheap on microprocessors.
>
> Well, I'll try and explain the reasoning behind the current template
> implementation, of which-I think-the finite difference package is the most
> blatant example. (P.S. Sorry - it turned out to be a long e-mail, but I
> wanted to put all my cards on the table so that we can continue discussing
> the issue with the complete picture in mind)
>
> First and foremost, the virtual classes approach is one that we definitely
> want to pursue - expecially as we are exporting the library towards Python
> (and hopefully other languages) where we cannot exploit the C++ template
> mechanism.
> In short, I surely want to be able to use dynamic polymorphism to switch
> between FiniteDifferenceModel<CrankNicolson<TridiagonalOperator> >,
> FiniteDifferenceModel<BackwardEuler<MultigridOperator> >,
> FiniteDifferenceModel<MyVerySpecificPadeApproximation>,
> FiniteDifferenceModel<WhateverYouLike>, and even
> TreeModel<WhateverItNeeds>. This can be (more or less) easily accomplished
> by inheriting template<class Evolver> FiniteDifferenceModel<Evolver> from
> some more generic interface class. However, this is a part of the global
> design that didn't make into the library yet. We just uploaded the inner
> part of it.
>
> At the same time, while very flexible with respect to usability by the
> final user, dynamic polymorphism is somehow less flexible with respect to
> developing new classes - because it forces such classes to belong to a
> particular hierarchy. I see two main disadvantages of this approach:
> 1) multiple inheritance rears its ugly head, which I would avoid if
> possible. This is very likely to be a only a prejudice of mine - so feel
> free to ignore it - but it is getting much too close to virtual base
> classes for my liking.
> 2) if you decide that, e.g., some sparse array class you found in another
> library would be just right for your particular problem, you'll have to
> either: a) modify that class so that it inherits from the base class for
> arrays in our brand new polymorhpic framework, which is not always
> possible, or b) write a wrapper class which contains the sparse array and
> inherit from the base one.
> In a template framework, you can just go ahead and write your differential
> operator using the sparse array class as it is, and its full compatibility
> with the framework is just a trait specialization away.
>
> Furthermore, if different array classes - possibly including sparse ones -
> or different operator classes  - tridiagonal, band diagonal, sparse, you
> name it - are to be derived from base classes, then it is very likely that
> we will have to declare as virtual even very basic functionalities (i.e.,
> operator[]) which tend to get in the innermost loops of the code and get
> called humongous number of times. Now, while it is true that virtual calls
> are cheap nowadays, it is also true that precious few optimizers inline
> them. A simple algorithm for multiplying a matrix and a vector would
> either: a) be written in a generic way, in which case it would jump in and
> out the respective operator[] for most of the time, which will add up to
> quite a loss in efficiency, or
> b) be specialized for the concrete operators and array - however, this
> would need double dispatching, which is not easier to write and maintain
> than templates.
>
> Finally, there's still one thing that static polymorphism can do and
> dynamic polymorphism can't, and that's generic algorithms on iterators. You
> simply can't derive all iterators from a single class as Java does, because
> you can't add a parent class to C pointers. But I don't think you need to
> hear this from me :)
>
> Well, I'm open to suggestions. In short, my point was: I'd like to be able
> to use templates in the inner parts of the models - arrays, operators... -
> for the kind of flexibility I explained above. I'd also like to use dynamic
> polymorphism in the outer parts - the complete models and their interface -
> for the kind of flexibility users, including myself, want.
> Once the design is refined, we could have the best of both worlds - and of
> course a bit of the worst of both, compiler support included :) But it is a
> trade-off that I would personally accept.
>
> Thanks for listening (man, was this long!)
>
>                  Luigi
>
>
> _______________________________________________
> Quantlib-users mailing list
> Qua...@li...
> http://lists.sourceforge.net/mailman/listinfo/quantlib-users

At 04:02 PM 12/19/00 +0100, you wrote:
>Hi everybody,
>Programming styles are probably one of the more contentious issues, and
>different people are used to different things. But I think Bernd is right to
>bring up the issue of programming style. There are probably a zillion ways
>of doing things, but what I would like to propose is that we should agree on
>a set of C++ programming style rules. This, I think, will avoid problems at
>a stage, when many more people are starting to add code.

Gilbert,
         I agree with bringing up the issue. I had a look at the 
recommendations you cited, and I agree with most of them. Actually, on 
second thought, even with some that are against ones that I currently use - 
and my colleagues know how grumpy I can get about these :) The only ones I 
still have doubts about are:

5) Ok for having #defines in uppercase. I'd prefer enumerations inside 
classes and static const class variables in mixed case starting with lower 
case.

17) ok for employee.setName(). However, employee.getName() seems a bit 
redundant to me - employee.name() is just as clear. Unfortunately this 
would conflict with 6) since name() is not a verb (well, not in this case).
What the hey, you decide and tell me.

49) I would make an exception for static const variables, for which I see 
no reason for access through a get() method.

69) I find an indentation of 4 more readable than 2. But hey, that's just 
me, I can get used to it.

70) I like better example 1 for classes and functions too. But again, 
that's just me.

83) f (x) looks very strange to me with the space in the middle. Then again...

90) We'll have to stick to /* ... */ when comments are to be extracted by 
Doxygen.


Bye for now,
                 Luigi

Some headaches I had using templates:
A few months ago, I wrote some C++ template code using STL templates (which
in turn contained nested templates). I had problems looking at the value of
the variables in my Visual C++ debugger because some of the templates were
resolved into over 20 lines or so. Perhaps I didn't find the option that
would allow me to collapse the expanded template name into something more
managable. If there isn't, then templates can make your debugging life much
more difficult.
Regards
Gilbert

> -----Mensaje original-----
> De: qua...@li...
> [mailto:qua...@li...]En nombre de Luigi
> Ballabio
> Enviado el: 19 December 2000 16:51
> Para: qua...@li...
> Asunto: [Quantlib-users] Templates
>
>
> At 07:18 PM 12/18/00 +0100, Ferdinando Ametrano wrote:
> >>Initial impressions:
> >>
> >>         I am unhappy about the heavy use of templates and the stl. Its
> >> going to bite you on many platforms (guys there is a whole world out
> >> there apart from Macs and Windows machines...) and the bloat
> is going to
> >> be considerable.
> >Luigi will reply to this one.
>
> Here I am. Of course you're right about compiler support (we already had
> quite a few headaches because of this) and about the bloat. I am
> also aware
> that, as Peter Schmitteckert wrote,
>
> >for a library, I prefer virtual classes/functions to achieve conveniency
> >and flexibility. You can extend classes with virtual function, withouot
> >recompiling or changing the interface. With templates you can't
> (normally) not.
> >...and remember, virtual fuctions are just a pointer-derefencation, and
> >that's cheap on microprocessors.
>
> Well, I'll try and explain the reasoning behind the current template
> implementation, of which-I think-the finite difference package is
> the most
> blatant example. (P.S. Sorry - it turned out to be a long e-mail, but I
> wanted to put all my cards on the table so that we can continue
> discussing
> the issue with the complete picture in mind)
>
> First and foremost, the virtual classes approach is one that we
> definitely
> want to pursue - expecially as we are exporting the library
> towards Python
> (and hopefully other languages) where we cannot exploit the C++ template
> mechanism.
> In short, I surely want to be able to use dynamic polymorphism to switch
> between FiniteDifferenceModel<CrankNicolson<TridiagonalOperator> >,
> FiniteDifferenceModel<BackwardEuler<MultigridOperator> >,
> FiniteDifferenceModel<MyVerySpecificPadeApproximation>,
> FiniteDifferenceModel<WhateverYouLike>, and even
> TreeModel<WhateverItNeeds>.
> This can be (more or less) easily accomplished by inheriting
> template<class
> Evolver> FiniteDifferenceModel<Evolver> from some more generic interface
> class. However, this is a part of the global design that didn't make into
> the library yet. We just uploaded the inner part of it.
>
> At the same time, while very flexible with respect to usability by the
> final user, dynamic polymorphism is somehow less flexible with respect to
> developing new classes - because it forces such classes to belong to a
> particular hierarchy. I see two main disadvantages of this approach:
> 1) multiple inheritance rears its ugly head, which I would avoid if
> possible. This is very likely to be a only a prejudice of mine - so feel
> free to ignore it - but it is getting much too close to virtual base
> classes for my liking.
> 2) if you decide that, e.g., some sparse array class you found in another
> library would be just right for your particular problem, you'll
> have to either:
>    a) modify that class so that it inherits from the base class
> for arrays
> in our brand new polymorhpic framework, which is not always possible, or
>    b) write a wrapper class which contains the sparse array and inherit
> from the base one.
> In a template framework, you can just go ahead and write your
> differential
> operator using the sparse array class as it is, and its full
> compatibility
> with the framework is just a trait specialization away.
>
> Furthermore, if different array classes - possibly including
> sparse ones -
> or different operator classes  - tridiagonal, band diagonal, sparse, you
> name it - are to be derived from base classes, then it is very
> likely that
> we will have to declare as virtual even very basic functionalities (i.e.,
> operator[]) which tend to get in the innermost loops of the code and get
> called humongous number of times. Now, while it is true that
> virtual calls
> are cheap nowadays, it is also true that precious few optimizers inline
> them. A simple algorithm for multiplying a matrix and a vector
> would either:
> a) be written in a generic way, in which case it would jump in
> and out the
> respective operator[] for most of the time, which will add up to quite a
> loss in efficiency, or
> b) be specialized for the concrete operators and array - however, this
> would need double dispatching, which is not easier to write and maintain
> than templates.
>
> Finally, there's still one thing that static polymorphism can do and
> dynamic polymorphism can't, and that's generic algorithms on
> iterators. You
> simply can't derive all iterators from a single class as Java
> does, because
> you can't add a parent class to C pointers. But I don't think you need to
> hear this from me :)
>
> Well, I'm open to suggestions. In short, my point was: I'd like
> to be able
> to use templates in the inner parts of the models - arrays,
> operators... -
> for the kind of flexibility I explained above. I'd also like to
> use dynamic
> polymorphism in the outer parts - the complete models and their
> interface -
> for the kind of flexibility users, including myself, want.
> Once the design is refined, we could have the best of both worlds
> - and of
> course a bit of the worst of both, compiler support included :)
> But it is a
> trade-off that I would personally accept.
>
> Thanks for listening (man, was this long!)
>
>                  Luigi
>
>
> _______________________________________________
> Quantlib-users mailing list
> Qua...@li...
> http://lists.sourceforge.net/mailman/listinfo/quantlib-users
>

Hi everybody,
Programming styles are probably one of the more contentious issues, and
different people are used to different things. But I think Bernd is right=
 to
bring up the issue of programming style. There are probably a zillion way=
s
of doing things, but what I would like to propose is that we should agree=
 on
a set of C++ programming style rules. This, I think, will avoid problems =
at
a stage, when many more people are starting to add code.

There is a very concise set of rules (actually 92 of them) at
http://www.geosoft.no/style.html#General%20Recomendations, which we could
take as a base for discussion. I would propose that we should go through =
the
list and  discard those rules we don't like or add other rules, and thus
keep those we think guarantee a minimum degree of consistency in the code.

What are your thoughts on this?

Gilbert


____________________________________________

Gilbert Peffer
Project Manager
Finance, IT & Engineering
International Centre for Numerical Methods in Engineering (CIMNE)
Building C1 -  North Campus UPC
Gran Capit=E0 s/n
08034 Barcelona, Spain

Movil: +34 626 386 652
Tel:   +34 93 401 6038
       +34 93 401 6035
Fax:   +34 93 401 6517
E-mail: gi...@ci...
Web:    www.cimne.upc.es

At 07:18 PM 12/18/00 +0100, Ferdinando Ametrano wrote:
>>Initial impressions:
>>
>>         I am unhappy about the heavy use of templates and the stl. Its 
>> going to bite you on many platforms (guys there is a whole world out 
>> there apart from Macs and Windows machines...) and the bloat is going to 
>> be considerable.
>Luigi will reply to this one.

Here I am. Of course you're right about compiler support (we already had 
quite a few headaches because of this) and about the bloat. I am also aware 
that, as Peter Schmitteckert wrote,

>for a library, I prefer virtual classes/functions to achieve conveniency 
>and flexibility. You can extend classes with virtual function, withouot 
>recompiling or changing the interface. With templates you can't (normally) not.
>...and remember, virtual fuctions are just a pointer-derefencation, and 
>that's cheap on microprocessors.

Well, I'll try and explain the reasoning behind the current template 
implementation, of which-I think-the finite difference package is the most 
blatant example. (P.S. Sorry - it turned out to be a long e-mail, but I 
wanted to put all my cards on the table so that we can continue discussing 
the issue with the complete picture in mind)

First and foremost, the virtual classes approach is one that we definitely 
want to pursue - expecially as we are exporting the library towards Python 
(and hopefully other languages) where we cannot exploit the C++ template 
mechanism.
In short, I surely want to be able to use dynamic polymorphism to switch 
between FiniteDifferenceModel<CrankNicolson<TridiagonalOperator> >, 
FiniteDifferenceModel<BackwardEuler<MultigridOperator> >,
FiniteDifferenceModel<MyVerySpecificPadeApproximation>, 
FiniteDifferenceModel<WhateverYouLike>, and even TreeModel<WhateverItNeeds>.
This can be (more or less) easily accomplished by inheriting template<class 
Evolver> FiniteDifferenceModel<Evolver> from some more generic interface 
class. However, this is a part of the global design that didn't make into 
the library yet. We just uploaded the inner part of it.

At the same time, while very flexible with respect to usability by the 
final user, dynamic polymorphism is somehow less flexible with respect to 
developing new classes - because it forces such classes to belong to a 
particular hierarchy. I see two main disadvantages of this approach:
1) multiple inheritance rears its ugly head, which I would avoid if 
possible. This is very likely to be a only a prejudice of mine - so feel 
free to ignore it - but it is getting much too close to virtual base 
classes for my liking.
2) if you decide that, e.g., some sparse array class you found in another 
library would be just right for your particular problem, you'll have to either:
   a) modify that class so that it inherits from the base class for arrays 
in our brand new polymorhpic framework, which is not always possible, or
   b) write a wrapper class which contains the sparse array and inherit 
from the base one.
In a template framework, you can just go ahead and write your differential 
operator using the sparse array class as it is, and its full compatibility 
with the framework is just a trait specialization away.

Furthermore, if different array classes - possibly including sparse ones - 
or different operator classes  - tridiagonal, band diagonal, sparse, you 
name it - are to be derived from base classes, then it is very likely that 
we will have to declare as virtual even very basic functionalities (i.e., 
operator[]) which tend to get in the innermost loops of the code and get 
called humongous number of times. Now, while it is true that virtual calls 
are cheap nowadays, it is also true that precious few optimizers inline 
them. A simple algorithm for multiplying a matrix and a vector would either:
a) be written in a generic way, in which case it would jump in and out the 
respective operator[] for most of the time, which will add up to quite a 
loss in efficiency, or
b) be specialized for the concrete operators and array - however, this 
would need double dispatching, which is not easier to write and maintain 
than templates.

Finally, there's still one thing that static polymorphism can do and 
dynamic polymorphism can't, and that's generic algorithms on iterators. You 
simply can't derive all iterators from a single class as Java does, because 
you can't add a parent class to C pointers. But I don't think you need to 
hear this from me :)

Well, I'm open to suggestions. In short, my point was: I'd like to be able 
to use templates in the inner parts of the models - arrays, operators... - 
for the kind of flexibility I explained above. I'd also like to use dynamic 
polymorphism in the outer parts - the complete models and their interface - 
for the kind of flexibility users, including myself, want.
Once the design is refined, we could have the best of both worlds - and of 
course a bit of the worst of both, compiler support included :) But it is a 
trade-off that I would personally accept.

Thanks for listening (man, was this long!)

                 Luigi

Hi all

Gilbert wrote:
>         - Include IMSL and NAG analytics interfaces. This will give the 
> user the
>possibility to access the most robust mathematical routines written under
>the sun.
We can't. IMSL, NAG, Numerix, Panalytix, XXX APIs are copyrighted. We 
cannot clone their interface if we want QuantLib to stand the test of time.
We can design our own interfaces, then anybody can provide wrappers for 
proprietary libraries to be used in place of any part of QuantLib.
Besides to adopt non-free libraries may be a serious problem for student 
and researchers. I don't want to force anybody to buy XXX analytics to use 
QuantLib.

In the search of a Grand Numerical Library we will have some problem.
Even gsl (Gnu Scientific Library) is forbidden because of its licence (GPL).
Another constraint to consider is that I want QuantLib to be cross platform.

>         - Estmiation and calibration methods such as maximum likelihood or
>filtering
This means multidimensional optimization, that I plan for release 1.0. I 
don't think 1.0 will deal with calibration, I think it will be plain 
vanillas only.
Of course as soon as 1.0 is out we can work on more advanced issues.

>         - A schedule class is very important, but I saw that you are already
>working on that
Yes I hope Luigi and I will have it in January. Maybe I will post the 
interface design before.

>         - I would suggest to add an ExchangeInstrument class, containing 
> all the
>exchange traded instruments for all instruments (futures, options, ...)
>traded on an exchange
I agree.

>         - A class <StructuredNote> would be great, but I have a feeling 
> that this
>is highly non-trivial
It's too early. We need term structure models

>         - Some other classes to think about and add are <Trade>, <Portfolio>,
Enrico is working on <Deal> (that will include a <FinancialIntrument>), 
<Portfolio> (a collection of <Deal>s valued on the same curve/model), 
<Book> (a collection of <Portfolio>s), <TradeGroup> (a generic collection 
of <Deal>s, with no further constraints)

><Index>
Luigi and I are working on that. This class should provide an index fixing 
estimate for all the models available

><Flow>
A cash flow schedule will be something like an array of <Flow>s, including 
also the date handler structure, and an <Index> reference

><Lattice>
I'm thinking about a <Model> class that wraps what is currently available: 
e.g. FiniteDifferenceModel<CrankNicolson<TridiagonalOperator> > (where 
TridiagonalOperator is the discretization of a differential operator, e.g. 
the one for Black Scholes equation)
On such a model you can rollBack an <Asset> without knowing about the 
inners of <Model>

>         - An interface to MatLab is certainly a good idea, but can you 
> distribute
>applications written in QuantLib and using MatLab for graphical output to
>users that don't have MatLab installed? If yes great, if no, we should look
>for graphic freeware.
I'm not good at that, but I would consider wxWindows (http://wxwindows.org/)
Anyway QuantLib is a library. I will support any attempt to build an 
application on QuantLib, but I don't think the time is right to start 
working on that.
QuantLib API will change a lot before 1.0
I personally use the Python interface and I think scripting languages are 
good for this task.
Excel and MATLAB are so widespread I think is a smart move to support them.

There are a few border issues between a library and an application. While 
the application in not a 1.0 goal some of them need careful planning from 
the start. I found a few application issue in your message. The following 
is a list:

>         - Add a <Quote> class that can be observed by objects such as 
> yield curves
>(for automatic live updates)
This may be a natural extension of our design of yield curves as observable.

>         - XMLing the structures is a great idea
Thank you. Unfortunately it is only an idea. I never worked with XML, 
everything to do.

>         - A function parser would be excellent to have. That way, you can 
> let users
>input for instance more complicated cash flow patterns (for instance in
>leveraged floaters, but in many other situations more)
I completely agree, even if I have no idea how to write a parser.
This is not urgent since the parser is mainly to allow an end user of a 
QuantLib application
to describe a complex cash flow pattern. As QuantLib developer you can 
write ad-hoc code (not elegant I agree, but this is just to set priorities)


A great part of the excitement of an open source project is that you don't 
plan everything ahead: you know the suggestion: "release often, release early".
Nothing is written in stone, so fell free to give me a strong feedback.
Even better provide working code, I'll do my best to make it fit with the 
general design.
If your contribution is good it will even change the design.

ciao -- Nando

>but could we at least have some white
>space inbetween logical blocks of code?
>
>Comments welcome.
your version is clearly more readable. I will follow your suggestion, and 
probably everybody will, at least in my company.

ciao -- Nando

Hi,
	I realize different people follow different code styles, and I am the very 
last person to be fuzz about this, but could we at least have some white 
space inbetween logical blocks of code?

Attached please find an example for what is currently been done:

bsmamericanoption.cpp

and what I would like to see:

bsmamericanoptionoSpace.cpp

Comments welcome.
Bernd

Hi,
	attached please find the latest Linux port. Everything works including
python support and the history.h file nando commited earlier today. (see my
edits in history.h -- I think this is going to be a nightmare until g++ will 
have proper c++ standart library support ...).

	Would love to commit myself but have to wait for nando to figure out
how to give me write access to the cvs. 

	I don't think I broke anything for the other platforms, if yes, please
report. The only change of note I made is to move the soruces that used
to reside in Sources into a subdirector called QLBase. I think this is better
style and should have a trivlal fix in the dev environments on Windows and
the Mac.

	In order to build on Linux just cd into /Linux and follwo the instructions
in the Readme.


--- Bernd

This is from Bernd.
He didn't know I just merged quantlib-dev into quantlib-users.
Two mailing list are too much for a new project

ciao -- Nando




>X-From_: qua...@li...  Mon Dec 18 12:32:09 2000
>Delivered-To: 383...@ma...
>From: Bernd Johannes Wuebben <wu...@be...>
>Reply-To: wu...@be...
>Organization: Deutsche Bank
>To: Ferdinando Ametrano <fer...@ri...>
>Subject: Re: [Quantlib-dev] Linux Port
>X-Mailer: KMail [version 1.2]
>Cc: qua...@li...
>Sender: qua...@li...
>X-BeenThere: qua...@li...
>X-Mailman-Version: 2.0
>List-Help: <mailto:qua...@li...?subject=help>
>List-Post: <mailto:qua...@li...>
>List-Subscribe: <http://lists.sourceforge.net/mailman/listinfo/quantlib-dev>,
>         <mailto:qua...@li...?subject=subscribe>
>List-Id: Discussion of QuantLib development 
><quantlib-dev.lists.sourceforge.net>
>List-Unsubscribe: 
><http://lists.sourceforge.net/mailman/listinfo/quantlib-dev>,
> 
><mailto:qua...@li...?subject=unsubscribe>
>List-Archive: <http://lists.sourceforge.net/archives//quantlib-dev/>
>Date: Mon, 18 Dec 2000 15:32:13 -0500
>
>On Monday 18 December 2000 14:52, you wrote:
> > I have a pragmatic approach, it's matter of evaluating what will help more:
> > GPL code or support from GPL-adverse financial software/consulting
>
>Whether your approach is pragmatic can not be decided at this point
>as we have not seen any support from GPL-adverse financial software/consulting
>firms. Furthermore, frankly I don't expect anything, probably ever. My KDE
>eperiences have been versy sobering.  Companies will ONLY take and _never_
>give as far a code is concerned.
>
>As to the GPL code question. I really don't care anymore. I am tired of
>anything that involved licensing questions. Very tired. The license
>we have currently is fine with me and if we can't use R or orctave stuff,
>then so be it.
>
>ps what's that history.h file? Did you even try to compile that using g++
>2.95-3? Don't know whether I can quickly fix that one ...
>
>Bernd
>
>
> > companies.
> >
> > ciao -- Nando
>
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>http://lists.sourceforge.net/mailman/listinfo/quantlib-dev

> > We cannot use GPLed libraries to preserve the QuantLib licence, since GPL
> > would contaminate QuantLib. We can use LGPL libraries.
>
>Well, lets see whether we can survive without  great code such as the stats
>libs of R etc.
I have a pragmatic approach, it's matter of evaluating what will help more: 
GPL code or support from GPL-adverse financial software/consulting companies.

ciao -- Nando

>         I sent nando an initial embryonicGNU/Linux port. Generates makefiles
>dynamically, almost everything compiles. More when I have another five
>minutes.
thank you Bernd

>Initial impressions:
>
>         I am unhappy about the heavy use of templates and the stl. Its 
> going to
>bite you on many platforms (guys there is a whole world out there apart from
>Macs and Windows machines...) and the bloat is going to be considerable.
Luigi will reply to this one. In the meantime can you elaborate on which 
platform you think we will have problems?
QuantLib compiles on Win32, Mac and (hopefully soon) on Linux.
Sun Solaris is the only other platform used in financial world I can think of.

>         Is the license compatible with the GPL?
Nice to hear such a question from a KDE developer ;-)
Yes it is. The XFree-86 style licence (also called BSD style licence) 
classifies QuantLib as both Free Software and Open Source, as you can see 
following the links in http://quantlib.sourceforge.net/license.html

>  Has someone verified with Richard?
I had email exchanges with Richard Stallman before announcing QuantLib. He 
advocated GPL or LGPL of course.
I chose XFree-86 style licence because I want software companies and/or 
researchers to be able to release proprietary model based on QuantLib under 
more restrictive copyright. I think this is a requirement if we want 
QuantLib to become a widespread adopted standard, since proprietary model 
are a competitive advantage in the trading rooms.
This is also a requirement from my company, even if I hope and think that 
we will GPL our products.
I will get back to Richard to let him known about the QuantLib project, and 
to get a confirmation that my wording of XFree-86 is good enough to be GPL 
compatible.

Of course my approach has some drawback.
We cannot use GPLed libraries to preserve the QuantLib licence, since GPL 
would contaminate QuantLib. We can use LGPL libraries.

>             We need to talk seriously about the architecture sometime soon.
I posted a to do list as a starter 
(http://lists.sourceforge.net/archives//quantlib-users/2000-December/000004.html)
This is not talking about architecture yet, but it is a starting point.
I also owe an answer to Gilbert Peffer message 
(http://lists.sourceforge.net/archives//quantlib-users/2000-December/000005.html)

Feel free to start a design thread on this mailing list if you have some 
proposal

ciao -- Nando

Peter

I can't reach you at pe...@sc...
Please get in touch

ciao -- Nando

>         I have dowloaded Swig1.3.3NT and Python 2.0 for windows.
If you're trying to use the release 0.1.1 you don't need to use Swig, since 
the wrapper files are already included and ready to be compiled.
This should also be true if you're trying to compile the latest CVS 
snapshot: anyway in this case it may happen that wrapper files are out of 
synch.

Of course if you want to actively develop QuantLib using Python (or 
scripting languages) it is useful to have Swig.
In this case please note that we're using 1.3a5. Since the NT port is not 
available yet you have to use CygWin.
Follow these steps:

a) Download Cygwin from http://cygwin.com/ and install it. Take note of 
your CygWin root (C:\cygwin from now on)
b) Download SWIG1.3a5 from 
http://download.sourceforge.net/swig/swig1.3a5.tar.gz
c) Copy the file swig1.3a5.tar.gz in a directory under the control of 
Cygwin (e.g. your home dir C:\cygwin\home\username)
d) Open a Cygwin shell
         > cd "the directory where swig1.3a5.tar.gz is"
         > gunzip swig1.3a5.tar.gz
         > tar xvf swig1.3a5.tar
         > cd SWIG1.3a5
         > ./configure
        edit "./Makefile" and replace "SWIG_LIB = $(prefix)/lib/swig1.3"
               with "SWIG_LIB = $(prefix)/lib/swig1.3a5"
        edit "./Source/Include/swigconfig.h" and replace
                 #define SWIG_LIB   "/usr/local/lib/swig1.3"
           with  #define SWIG_LIB   "/usr/local/lib/swig1.3a5"
         > make
         > make install
         > mv /usr/local/bin/swig.exe /usr/local/bin/swig1.3a5.exe
e) Include "C:\cygwin\usr\local\bin" and the path where you have the 
cygwin1.dll file ("C:\cygwin\bin") in your system variable $PATH

now you're ready to compile QuantLib.

Borland compiler: use the makefile provided (you will have to change a 
couple of defines accordingly to your Python installation).
MSVC compiler: use QuantLib\Win\PyWrap.bat to generate the wrappers. You 
will have to add the directory of Python.h to your MSVC settings

>  I tried an
>example given in "Examples Directory", I could compile example.i for swig to
>generate example_wrap.c
>compiled example.c
>but when compiling example_wrap.c along with example.c it generates lots of
>errors.
>Apparently these are because the Header file "Python.h" doesn't contains
>some items like
>"PyObject". I would like to know info on this.
This is a problem related with your Swig installation. See my suggestion 
for Borland and MSVC

We have changed a few things to have an easier Windows installation. They 
will be available this week with release 0.1.2
I will also add a FAQ entry for CygWin/Swig

ciao -- Nando

	I have dowloaded Swig1.3.3NT and Python 2.0 for windows. I tried an
example given in "Examples Directory", I could compile example.i for swig to
generate example_wrap.c
compiled example.c 
but when compiling example_wrap.c along with example.c it generates lots of
errors.
Apparently these are because the Header file "Python.h" doesn't contains
some items like
"PyObject". I would like to know info on this.

Yours Sincerely,
Sakti