quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] QL FpML Object Handler Modifications

[Fabrice C. <fab...@gm...>]

Hello there,


I have started reading FpML specs (which is not the best book I have
ever read, I must admit), and will need some more time to finish.

Concerning my participation, I am still interested in coding part of
the new QuantLib-FpML module, as described by Eric in his last post.

I was also thinking of contacting one of the FpML development groups
to ask them what will be the next steps in the development of this
language.


Bonne soir=E9e,

Fabrice


On Mon, 28 Feb 2005 12:35:03 +0000, eric ehlers <eri...@gm...> wro=
te:
> Hi David
>=20
> Welcome back, glad to hear that your negotiations are progressing, and
> looking forward to your project getting underway.
>=20
> >    After discussing with out Professor the idea of assisting with
> > GNUmeric implementation to QuantLibAddIn we found that our project was
> > not suitable.
>=20
> I know you mentioned a Gnumeric plugin, I hadn't understood that you
> were considering that for your project.
>=20
> > He said that wrappers were not a good substitute for a
> > complete learning experience involving object oriented programming.
>=20
> I agree.  Wrapping QuantLibAddin for any specific platform is a small
> technical exercise, mainly writing a Python script to autogenerate the
> source for the Addin.
>=20
> >    Eric:  We are not clear on whether you would be implementing FpML
> > if we built a modified object handler subclass that encoded /
> > unencoded FpML (or as Luigi called it:  Serialized / Deserialized
> > FpML.)  We are simply asking to make sure that no one is peforming
> > redundant work.
>=20
> I don't think there will be a subclass of ObjectHandler, nor any
> functionality in ObjectHandler for directly (De)Serializing FpML.
>=20
> Irrespective of who does what, let me first reiterate my current
> understanding of what needs to be done:
>=20
> In QuantLib:
> - implementation of TermSheet classes
> - extension of Instrument classes to support new constructors
> accepting TermSheet as input
>=20
> In new component QuantLib-FpML:
> - translation of FpML <-> TermSheet
>=20
> (note that QuantLib is now FpML-enabled - independent of
> ObjectHandler/QuantLibAddin)
>=20
> In ObjectHandler:
> - extend the abstract base class Object to include (De)Serialize
> member functions (which would be pure virtual)
> - extend class ObjectHandler to support (Un)Load functions (which in
> turn invoke Object->(De)Serialize).
>=20
> In QuantLibAddin:
> - for derived Object classes - override (De)Serialize to call the code
> in QuantLib-FpML appropriate for the underlying QuantLib object
>=20
> Back to the question of avoiding redundant work - I definitely agree
> that we need to clarify who does what - I haven't yet started to think
> about what I'd do personally and it depends a lot on what you would
> enjoy doing.
>=20
> >    Luigi:  Could you send us some links on the current structure of
> > the QL_Object_Handler that woudl require modification?  Any advice is
> > appreciated.
>=20
> Hopefully the comments above clarify the changes required in
> ObjectHandler?  There isn't much, with the main FpML-specific
> functionality implemented in QuantLib-FpML.
>=20
> Hope this clarifies things.  Very much looking forward to hearing your
> project proposal, please let me know what I can do to help.
>=20
> Best Regards,
> Eric
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Quantlib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Still problems compiling QuantLibAddIn under Linux

[Penschke, W. <Wal...@co...>]

Hi Eric, hi Luigi,

Sorry, to bother you again.
I am still struggling with the compilation of QuantLibAddIn under Linux.

Luigi, you mentioned that you added some "patches" to the current
development branch (Linux). So I today retrieved the modules QuantLib,
ObjectHandler and QuantLibAddin via anon-cvs and tried to compile and 
link the modules again (in the above order).

As before there were no problems with QuantLib and ObjectHandler. When 
trying to compile the QuantLibAddin module in the same way as described
previously (please see below), however, I encountered the following 
errors:

--- SCHNIPP ---
[wpe@metallica QuantLibAddin]$ make
Making all in Autogen
make[1]: Entering directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/Autogen'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/Autogen'
Making all in qla
make[1]: Entering directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla'
make  all-am
make[2]: Entering directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla'
make[2]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla'
make[1]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla'
Making all in Addins/C
make[1]: Entering directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/Addins/C'
if /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I../../qla  -I../.. -I/home/wpe/projects/quantlib_cvs_devel/ObjectHandler
-I/home/wpe/projects/quantlib_cvs_devel/QuantLib/include/  -g -O2 -Wall -MT
options.lo -MD -MP -MF ".deps/options.Tpo" -c -o options.lo options.cpp; \
then mv -f ".deps/options.Tpo" ".deps/options.Plo"; else rm -f
".deps/options.Tpo"; exit 1; fi
 g++ -DHAVE_CONFIG_H -I. -I. -I../../qla -I../..
-I/home/wpe/projects/quantlib_cvs_devel/ObjectHandler
-I/home/wpe/projects/quantlib_cvs_devel/QuantLib/include/ -g -O2 -Wall -MT
options.lo -MD -MP -MF .deps/options.Tpo -c options.cpp  -fPIC -DPIC -o
.libs/options.o
options.cpp: In function `int QL_OPTION_ASIAN_D(char*, char*, char*, double,
   long int, long int, long int*, char*, char*, double, char*, long int,
long
   int, char*, long int, VariesList*)':
options.cpp:87: error: no matching function for call to `Conversion<long
int>::
   convertVector(long int*&, long int&)'
../../Addins/C/varies.hpp:28: error: candidates are: static
   std::vector<array_type, std::allocator<_CharT> >
   Conversion<T>::convertVector(const T*&, const long int&) [with T = long
int]
../../Addins/C/varies.hpp:35: error:                 static
   std::vector<std::string, std::allocator<std::string> >
   Conversion<T>::convertVector(char**&, const long int&) [with T = long
int]
options.cpp: In function `int QL_OPTION_CLIQUET(char*, char*, long int, long
   int*, char*, double, long int, char*, long int, VariesList*)':
options.cpp:212: error: no matching function for call to `Conversion<long
int>
   ::convertVector(long int*&, long int&)'
../../Addins/C/varies.hpp:28: error: candidates are: static
   std::vector<array_type, std::allocator<_CharT> >
   Conversion<T>::convertVector(const T*&, const long int&) [with T = long
int]
../../Addins/C/varies.hpp:35: error:                 static
   std::vector<std::string, std::allocator<std::string> >
   Conversion<T>::convertVector(char**&, const long int&) [with T = long
int]
options.cpp: In function `int QL_OPTION_DIVIDENDVANILLA(char*, char*, long
int,
   long int*, long int, double*, char*, char*, double, char*, long int, long
   int, char*, long int, VariesList*)':
options.cpp:251: error: no matching function for call to `Conversion<long
int>
   ::convertVector(long int*&, long int&)'
../../Addins/C/varies.hpp:28: error: candidates are: static
   std::vector<array_type, std::allocator<_CharT> >
   Conversion<T>::convertVector(const T*&, const long int&) [with T = long
int]
../../Addins/C/varies.hpp:35: error:                 static
   std::vector<std::string, std::allocator<std::string> >
   Conversion<T>::convertVector(char**&, const long int&) [with T = long
int]
options.cpp:253: error: no matching function for call to
`Conversion<double>::
   convertVector(double*&, long int&)'
../../Addins/C/varies.hpp:28: error: candidates are: static
   std::vector<array_type, std::allocator<_CharT> >
   Conversion<T>::convertVector(const T*&, const long int&) [with T =
double]
../../Addins/C/varies.hpp:35: error:                 static
   std::vector<std::string, std::allocator<std::string> >
   Conversion<T>::convertVector(char**&, const long int&) [with T = double]
make[1]: *** [options.lo] Error 1
make[1]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/Addins/C'
make: *** [all-recursive] Error 1
[wpe@metallica QuantLibAddin]$
--- SCHNAPP ---

Your help is (as always) highly appreciated,


wpe




-----Original Message-----
From: qua...@li...
[mailto:qua...@li...]On Behalf Of
qua...@li...
Sent: Saturday, February 19, 2005 5:33 AM
To: qua...@li...
Subject: Quantlib-dev digest, Vol 1 #285 - 5 msgs


Send Quantlib-dev mailing list submissions to
	qua...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/quantlib-dev
or, via email, send a message with subject or body 'help' to
	qua...@li...

You can reach the person managing the list at
	qua...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Quantlib-dev digest..."


Today's Topics:

   1. [ quantlib-Bugs-1143732 ] VC6 Compliation Error (SourceForge.net)
   2. ObjectHandler and QuantLibAddin (Penschke, Walter)
   3. Re: ObjectHandler and QuantLibAddin (eric ehlers)
   4. ObjectHandler and QuantLibAddin II (Penschke, Walter)
   5. Re: ObjectHandler and QuantLibAddin (Luigi Ballabio)


Message: 2
From: "Penschke, Walter" <Wal...@co...>
To: "'qua...@li...'"
<qua...@li...>
Date: Fri, 18 Feb 2005 14:55:31 +0100
Subject: [Quantlib-dev] ObjectHandler and QuantLibAddin

Hi Eric,

sorry that I could not respong to you earlier.

Before I get come to your response to my initial email I'd like to address
that I have problems getting 
QuantLibAddIn compiled from the actual development backup tar-ball. With QL
and ObjectHandler 
everything went fine. Here is what I did (Linux as OS):

- Downloaded the development tar ball and extracted it locally.

- Set CVSROOT to the just extracted local CVS repository and checked out the

modules QuantLib, ObjectHandler and QuantLibAddin.

- Compiled QuantLib and ObjectHandler successfully like that:
$ ./autogen.sh 
$ ./configure --prefix=`pwd`
$ make 
$ make install

- Tried to compile QuantLibAddin like that:
$ ./autogen.sh
$ ./configure --prefix=`pwd` CPPFLAGS="-I<PATH_TO_OBJECTHANDLER>
-I<PATH_TO_QUANTLIB>/include" LDFLAGS="-L<PATH_TO_OBJECTHANDLER>/lib
-L<PATH_TO_QUANTLIB>/lib"
$ make

This make command seems to compile and link the directory
QuantLibAddin/qla/objects successfully 
but runs into problems with the directory QuantLibAddin/qla/functions. Here
is the end of the generated output:

--- SCHNIPP ---
g++ -DHAVE_CONFIG_H -I. -I. -I../../qla -I../..
-I/home/wpe/projects/quantlib_cvs_devel/ObjectHandler/
-I/home/wpe/projects/quantlib_cvs_devel/QuantLib/include -g -O2 -Wall -MT
vanillaoption.lo -MD -MP -MF .deps/vanillaoption.Tpo -c vanillaoption.cpp -o
vanillaoption.o >/dev/null 2>&1
/bin/sh ../../libtool --mode=link g++  -g -O2 -Wall
-L/home/wpe/projects/quantlib_cvs_devel/ObjectHandler/lib
-L/home/wpe/projects/quantlib_cvs_devel/QuantLib/lib -o libObjects.la
asianoption.lo barrieroption.lo basketoption.lo cliquetoption.lo
dividendvanillaoption.lo forwardvanillaoption.lo optionutils.lo
stochasticprocess.lo vanillaoption.lo
ar cru .libs/libObjects.a .libs/asianoption.o .libs/barrieroption.o
.libs/basketoption.o .libs/cliquetoption.o .libs/dividendvanillaoption.o
.libs/forwardvanillaoption.o .libs/optionutils.o .libs/stochasticprocess.o
.libs/vanillaoption.o
ranlib .libs/libObjects.a
creating libObjects.la
(cd .libs && rm -f libObjects.la && ln -s ../libObjects.la libObjects.la)
make[3]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla/objects'
Making all in functions
make[3]: Entering directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla/functions'
make[3]: *** No rule to make target `options.cpp', needed by `options.lo'.
Stop.
make[3]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla/functions'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla'
make: *** [all-recursive] Error 1
[wpe@metallica QuantLibAddin]$
--- SCHNAPP ---

Having a look in the corresponding QuantLibAddin/qla/functions/Makefile it
seems that it expects a source file options.cpp. However in the 
corresponding directory there is no such file.

Any help would be highly appreciated. Thanks in advance.


wpe


--__--__--

Message: 3
Date: Fri, 18 Feb 2005 14:32:25 +0000
From: eric ehlers <eri...@gm...>
Reply-To: eric ehlers <eri...@gm...>
To: qua...@li...
Subject: Re: [Quantlib-dev] ObjectHandler and QuantLibAddin

Hi Walter

> Having a look in the corresponding QuantLibAddin/qla/functions/Makefile it
> seems that it expects a source file options.cpp. However in the
> corresponding directory there is no such file.

Much of the QuantLibAddin source code is autogenerated, you need to cd
to the Autogen directory and run autogen.py.  Sorry for not mentioning
that anywhere!, I'll add it to the readme file.

Some other notes on recompiling ...
- compiling the Calc Linux addin requires some extra steps which I
haven't gotten around to documenting.  If you need that please let me
know.  The Calc addin on Windows should compile as documented.
- On Windows I use MSDEV6 and those project workspace files are always
up to date.  I try to propogate changes to the other IDEs with
grep/sed but they may be broken.

Very much looking forward to your feedback.

Regards
Eric




--__--__--

Message: 5
Date: Fri, 18 Feb 2005 16:09:07 +0000
From: Luigi Ballabio <lui...@gm...>
Subject: Re: [Quantlib-dev] ObjectHandler and QuantLibAddin
To: eric ehlers <eri...@gm...>
Cc: qua...@li...


On 02/18/05 15:32:25, eric ehlers wrote:
> Much of the QuantLibAddin source code is autogenerated, you need to cd
> to the Autogen directory and run autogen.py.  Sorry for not mentioning
> that anywhere!, I'll add it to the readme file.

I just committed a couple of small patches---under Linux, 'make' will now
=20
invoke autogen.py before building the addins.

> Some other notes on recompiling ...
> - compiling the Calc Linux addin requires some extra steps which I
> haven't gotten around to documenting.  If you need that please let me
> know.

Or if you don't have Calc installed, use
./configure --disable-calc
to inhibit Calc-specific compilations.

Later,
	Luigi

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

Every solution breeds new problems.
-- unknown





--__--__--

_______________________________________________
Quantlib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev


End of Quantlib-dev Digest

Re: [Quantlib-dev] QL FpML Object Handler Modifications

[eric e. <eri...@gm...>]

Hi David

Welcome back, glad to hear that your negotiations are progressing, and
looking forward to your project getting underway.

>    After discussing with out Professor the idea of assisting with
> GNUmeric implementation to QuantLibAddIn we found that our project was
> not suitable.  

I know you mentioned a Gnumeric plugin, I hadn't understood that you
were considering that for your project.

> He said that wrappers were not a good substitute for a
> complete learning experience involving object oriented programming.

I agree.  Wrapping QuantLibAddin for any specific platform is a small
technical exercise, mainly writing a Python script to autogenerate the
source for the Addin.

>    Eric:  We are not clear on whether you would be implementing FpML
> if we built a modified object handler subclass that encoded /
> unencoded FpML (or as Luigi called it:  Serialized / Deserialized
> FpML.)  We are simply asking to make sure that no one is peforming
> redundant work.

I don't think there will be a subclass of ObjectHandler, nor any
functionality in ObjectHandler for directly (De)Serializing FpML.

Irrespective of who does what, let me first reiterate my current
understanding of what needs to be done:

In QuantLib:
- implementation of TermSheet classes
- extension of Instrument classes to support new constructors
accepting TermSheet as input

In new component QuantLib-FpML:
- translation of FpML <-> TermSheet

(note that QuantLib is now FpML-enabled - independent of
ObjectHandler/QuantLibAddin)

In ObjectHandler:
- extend the abstract base class Object to include (De)Serialize
member functions (which would be pure virtual)
- extend class ObjectHandler to support (Un)Load functions (which in
turn invoke Object->(De)Serialize).

In QuantLibAddin:
- for derived Object classes - override (De)Serialize to call the code
in QuantLib-FpML appropriate for the underlying QuantLib object

Back to the question of avoiding redundant work - I definitely agree
that we need to clarify who does what - I haven't yet started to think
about what I'd do personally and it depends a lot on what you would
enjoy doing.

>    Luigi:  Could you send us some links on the current structure of
> the QL_Object_Handler that woudl require modification?  Any advice is
> appreciated.

Hopefully the comments above clarify the changes required in
ObjectHandler?  There isn't much, with the main FpML-specific
functionality implemented in QuantLib-FpML.

Hope this clarifies things.  Very much looking forward to hearing your
project proposal, please let me know what I can do to help.

Best Regards,
Eric

[Quantlib-dev] QL FpML Object Handler Modifications

[David B. <doc...@gm...>]

Hello-

   After discussing with out Professor the idea of assisting with
GNUmeric implementation to QuantLibAddIn we found that our project was
not suitable.  He said that wrappers were not a good substitute for a
complete learning experience involving object oriented programming. 
Therefore,  Peter and I have been working on redesigning the 'school'
project;  there seem to be too many inconsistencies that are not yet
fleshed out.

   Luigi and Eric and Walter have expounded numerous points regarding
the future structure of FpML usage and from Walter's discussions,
there appear to be some future deficienies.  (SOAP, etc.)  This email
is to stimulate a little more brainstorming, prior to finalizing out
'class project proposal'.  Here is what we have been thinking:

   Eric:  We are not clear on whether you would be implementing FpML
if we built a modified object handler subclass that encoded /
unencoded FpML (or as Luigi called it:  Serialized / Deserialized
FpML.)  We are simply asking to make sure that no one is peforming
redundant work.

   Luigi:  Could you send us some links on the current structure of
the QL_Object_Handler that woudl require modification?  Any advice is
appreciated.


   Walter:  Regarding SOAP, could you please explain the problems and
intricacies you see that we need to consider when working on this FpML
Serial./Deserial. class?



Best Wishes,
David Brown

[Quantlib-dev] 0.3.9

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

Hi all,
	if Luca confirms that the Bermudan-swaption patch I sent to ql-=20
users fixes the problem, I'd go for a 0.3.9 release in a short time =20
(possibly a week or so.) Nando, can you manage the short lag now that you =20
automated your stuff? Are there any open issues we should fix before =20
release? (Given that putting out a bug fix has priority over "I'd like this=
 =20
to be in" features?)

Later,
	Luigi

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

Within C++, there is a much smaller and cleaner language struggling to get =
=20
out.
-- Bjarne Stroustrup

[Quantlib-dev] Voluntary Software Developer

[Alex Lu <lu....@gm...>]

Hi,

I am new here and am willing to contribute some of my time to the
test, development of QuantLib project. I have been using C/C++ for
more than 7 years.
Now I am a software engineer in a data mining company and develop
software using COM/ATL on both Unix and Windows platforms.

This week I have compiled Boost and QuantLib on my Windows 2000 using
Visual Studio .NET 2003. Everything goes very smooth. I'd like to see
what I can contribute now.

Thanks,
Alex

Re: [Quantlib-dev] ObjectHandler and QuantLibAddin II

[eric e. <eri...@gm...>]

Hi Walter

> > Having had a look at the current code of interface, I was thinking if one
> > could for example add the name of the class and then use a factory to create
> > an instance of the class in the (now general) MAKE method of interface.

> Yes, this is the right approach.  I've made the change in
> ObjectHandler - the interface layer is now collapsed into a single
> factory function.  It needs some refinement but it's definitely the
> way forward.  I'm in the process of making the corresponding change in
> QuantLibAddin (I already completed a quick test to confirm it will
> work throughout the app).  Many thanks for this excellent suggestion,
> I owe you a beer.

OK, QuantLibAddin is now factory-enabled (and half its former size). 
I need to do a lot of refinements before the release but the basic
change is in place, the design is a lot cleaner with the end user
interface working exactly as before.

Looking forward to your further feedback.

Tschuess,
Eric

[Quantlib-dev] How can I create an XlfOper with a multi dimensional array ?

[Adjriou B. <bad...@ya...>]

Hi,
 
 I try to display in Excel this arrays :
 
  std::vector<double> df = market.discountFactors();
  std::vector<double> zc = market.zeroCoupons();
  std::vector<Date> dt = market.maturities();
 
  char * *dfs  =new char*[df.size()];
  char * *zcs =new char*[zc.size()];
  char * *dts =new char*[dt.size()];

  for(int i=0; i< df.size();i++)
   printf(dfs[i],"%c",df[i]);
  
  for(int j=0; j< zc.size();j++)
   printf(zcs[j],"%c",zc[j]);  
 
  for(int k=0; k< dt.size();k++)
   itoa(dt[k].serialNumber(),dts[k],10);  
 
  char ** results[3];
  results[0] = dts;
  results[1] = dfs;
  results[2] = zcs;
    
  return XlfOper(df.size(),3,results);
 
And I've got this message :
warning C4800: 'char ** ' : forcing value to bool 'true' or 'false' (performance warning)
        c:\adjriou\xlw\xlw\xlfoper.h(79) : see reference to function template instantiation 'class XlfOper &__thiscall XlfOper::Set(unsigned short,unsigned char,char ***  )' being compiled

And when I run excel, I have TRUE, TRUE .... ?
 
How can I create an XlfOper with a multi dimensional array ?
 
Thanks a lot for your help.
 
Regards.

    

		
---------------------------------
 Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails !
Créez votre Yahoo! Mail

Re: [Quantlib-dev] ObjectHandler and QuantLibAddin II

[eric e. <eri...@gm...>]

> Having had a look at the current code of interface, I was thinking if one
> could for example add the name of the class and then use a factory to create
> an instance of the class in the (now general) MAKE method of interface. 

Yes, this is the right approach.  I've made the change in
ObjectHandler - the interface layer is now collapsed into a single
factory function.  It needs some refinement but it's definitely the
way forward.  I'm in the process of making the corresponding change in
QuantLibAddin (I already completed a quick test to confirm it will
work throughout the app).  Many thanks for this excellent suggestion,
I owe you a beer.

> Wrt to the UPDATE method I am not sure
> if we need to know about the concrete derived class at all. Could it work to use straight forward
> polymorphism here? May be I missed something, but if that would work we would be fine with
> one single interface class. Haven't yet found time to actually try it.

This isn't a generic update, i.e. it's not a simple overwrite of
values in Object.  The idea is to allow the client to invoke any
member function in the underlying object.  In the ObjectHandler
example, the relevant function happens to be called Foo->update()
(I'll change this to a less confusing name).  In QuantLibAddin there's
an example which uses this feature to call
QuantLib::VanillaOption->setPricingEngine().

I gather you weren't thinking of the Update method in those terms when
you suggested polymorphism(?), but just to follow through on that
idea:  to achieve this polymorphically, the interface in the base
Object class would need to receive some kind of code or other means of
telling the derived Object class which method in the underlying
QuantLib class to call.  It might be technically doable but it
wouldn't be implementing polymorphism so much as circumventing it and
I don't think it's the right approach.

I'm not certain there's actually a requirement for this feature to
call a member function in the underlying QuantLib object.  I
implemented it because it fit easily into the design, to let people
see the idea and to see if there's any interest.  But usually in a
spreadsheet if you want to change the state of an object you just
delete it and recreate it with new inputs.  There may be cases where
the member function thing could be used to improve performance but I
don't know how often that situation will arise and we might consider
scrapping this feature altogether (with the possibility of
resurrecting it later if required).

Incidentally I have similar thoughts about the so-called "low level
interrogation" feature which enables the client to get directly at the
underlying object - I included it in ObjectHandler to demonstrate the
possibility but I'm not sure the feature is useful or desirable - it
hasn't been needed so far for QuantLibAddin.

> Up to now I did get working a small sample pricing server and a small Excel
> based market data retrieval server.
> I wrote an own little ExcelEngine for accessing Spreadsheets, which hides
> all the nasty COM stuff away.

So the server calls in to Excel with updates in pseudo real-time?  Sounds neat.

> At this stage I was thinking how to sensibly extend the service prototypes.
> One idea I have
> in mind is to provide one big "master-method", which is fed with a variable
> list of arguments. I this case I would need
> a corresponding Dispatcher on the client side. 

The ObjectHandler factory function could be the Dispatcher?  The
client could specify whether a request should be executed locally or
remotely, for remote requests the factory function serializes the
request and sends it to the server.

> Also, the load on the server would be pretty high as it not only performs
> pricing but also needs to create the objects from scratch for each request.

We could think about persistence.  The client has a handle for each
object in ObjectHandler - perhaps there would be the possibility for a
handle to refer to an object which is cached on the server.  This also
allows a single object to be shared by multiple clients.

> The remaining problem of wrapping up the complete QL functionality is
> however remaining.
> For the SOAP-calls your idea with (XML-)serialisation seems to be the right
> way. In contrast to Java this is, however,
> not a neglectable task within C++ because in C++ no proper reflection
> mechanism is available (Class.forName(...)).
> Perhaps one could supply a big serialiser/deserialiser class. But this idea
> also seems to be a bit clunky.

I've been assuming there will be (de)serialize member functions in the
base Object class, which derived classes override appropriately - all
of this using QuantLib-FpML/QuantLib-XML to do the real work.  I agree
that the implementation isn't trivial.

> Alternatively there might be other SOAP implementations available, which
> support automatic stub/skeleton-generation from a "normal" C++ class. 
> Perhaps one could create the required communication code automatically???

Yes, in the worst case scenario where we need specific code to
(de)serialize each class, it would at least be nice to be able to
generate the code automatically.

> Sorry that I have more questions than answers. 

Apology not accepted!  Your feedback is fantastic and has already led
to a fundamental improvement in the ObjectHandler design.  I'm very
glad to be having this discussion because we need to ensure that
ObjectHandler can be extended to support distributed computing and
it's best to get this right on day one.

> Please, let me know what you think about it.

My first thought is that we need more information.  You've anticipated
the design problems that we're likely to encounter, we need to
investigate available tools in more detail, maybe someone has already
solved some of these problems.  I'll see what info I can dig up and I
will keep you posted.

Longer term I think we should do some prototyping - identify the most
promising design, and then code up a small test for a few sample
classes - perhaps with ObjectHandler plugged in to your server - as a
proof of concept.

Regards,
Eric

Re: [Quantlib-dev] ObjectHandler and QuantLibAddin

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

On 02/18/05 15:32:25, eric ehlers wrote:
> Much of the QuantLibAddin source code is autogenerated, you need to cd
> to the Autogen directory and run autogen.py.  Sorry for not mentioning
> that anywhere!, I'll add it to the readme file.

I just committed a couple of small patches---under Linux, 'make' will now =20
invoke autogen.py before building the addins.

> Some other notes on recompiling ...
> - compiling the Calc Linux addin requires some extra steps which I
> haven't gotten around to documenting.  If you need that please let me
> know.

Or if you don't have Calc installed, use
./configure --disable-calc
to inhibit Calc-specific compilations.

Later,
	Luigi

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

Every solution breeds new problems.
-- unknown

[Quantlib-dev] ObjectHandler and QuantLibAddin II

[Penschke, W. <Wal...@co...>]

Hi Eric,

here my thougts on your last posting:

- I am still not clear about interface.hpp/interface.cpp:
I can see that it is a procedural wrapper for ObjectHandler and understand
that it is required
for environments like Excel. What is a bit striking to me is that it is
tightly bound to ObjectWidget 
which is one specific sub-class of Object. Am I right that for any other
subclass of Object - and if
I understood your idea correctly, there will be lots - again such a
procedural wrapper is required? 

If so, could it be an alternative to incorporate the actual class we are
dealing with "somehow" in 
the signature of interface? Having had a look at the current code of
interface, I was thinking if one
could for example add the name of the class and then use a factory to create
an instance of the
class in the (now general) MAKE method of interface. Wrt to the UPDATE
method I am not sure 
if we need to know about the concrete derived class at all. Could it work to
use straight forward 
polymorphism here? May be I missed something, but if that would work we
would be fine with
one single interface class. Haven't yet found time to actually try it.

- Here is what I have done so far with SOAP and what design issues I
encountered:
I am using gSoap (http://gsoap2.sourceforge.net) and it seems to be ok. It
seems to be pretty fast
and works on both platforms which are relevant to me (Windows and Linux).
STL types are not 
fully supported. It does work with lists but not with maps for example (at
least the version I am using,
which is only 2-3 month old.) The available documentation is pretty good and
big.

Up to now I did get working a small sample pricing server and a small Excel
based market data retrieval server. 
I wrote an own little ExcelEngine for accessing Spreadsheets, which hides
all the nasty COM stuff away.

I am not too much into gSoap and therefore was using a procedural interface
approach (similar to your idea). 
I.e. the communication between client and server is based on a set of
functions. Haven't yet checked if an 
object based approach is supported and works. 

My approach so far was to leave the client as dumb as possible. Within Excel
for example I don't need to 
have QuantLib available. For my little sample stuff this is ok as I only did
have to provide a small VB-routine 
which accesses the server via a thin client library.

At this stage I was thinking how to sensibly extend the service prototypes.
It seems to me that the principal
problem is the same as you are addressing with ObjectHandler/QuantLibAddin:
There is the need to wrap up 
QuantLib functionality as a whole, via a set of functions. 

Problem is that the number of thes functions can become pretty big. As I am
reluctant to wrap up all QL functionality
I was first thinking about reducing the granularity on the client side. The
question is: To what extend? One idea I have 
in mind is to provide one big "master-method", which is fed with a variable
list of arguments. I this case I would need 
a corresponding Dispatcher on the client side. Also, the load on the server
would be pretty high as it not only performs
pricing but also needs to create the objects from scratch for each request.

At this stage I came across your ObjectHandler/QuantLibAddin packages. The
idea of a local object store is nice as 
it would reduce the load on the server. I also don't see a big problem with
having QL available on the client side as well.
Clearly you are going the other way of keeping the granularity on the client
side in sync with QL, which is natural when
QL also resides on the client.

The remaining problem of wrapping up the complete QL functionality is
however remaining.
For the SOAP-calls your idea with (XML-)serialisation seems to be the right
way. In contrast to Java this is, however,
not a neglectable task within C++ because in C++ no proper reflection
mechanism is available (Class.forName(...)). 
Perhaps one could supply a big serialiser/deserialiser class. But this idea
also seems to be a bit clunky.

Alternatively there might be other SOAP implementations available, which
support automatic stub/skeleton-generation
from a "normal" C++ class. Perhaps one could create the required
communication code automatically???

Sorry that I have more questions than answers. I am also pretty much at the
beginning.
Please, let me know what you think about it.


wpe

Re: [Quantlib-dev] ObjectHandler and QuantLibAddin

[eric e. <eri...@gm...>]

Hi Walter

> Having a look in the corresponding QuantLibAddin/qla/functions/Makefile it
> seems that it expects a source file options.cpp. However in the
> corresponding directory there is no such file.

Much of the QuantLibAddin source code is autogenerated, you need to cd
to the Autogen directory and run autogen.py.  Sorry for not mentioning
that anywhere!, I'll add it to the readme file.

Some other notes on recompiling ...
- compiling the Calc Linux addin requires some extra steps which I
haven't gotten around to documenting.  If you need that please let me
know.  The Calc addin on Windows should compile as documented.
- On Windows I use MSDEV6 and those project workspace files are always
up to date.  I try to propogate changes to the other IDEs with
grep/sed but they may be broken.

Very much looking forward to your feedback.

Regards
Eric

[Quantlib-dev] ObjectHandler and QuantLibAddin

[Penschke, W. <Wal...@co...>]

Hi Eric,

sorry that I could not respong to you earlier.

Before I get come to your response to my initial email I'd like to address
that I have problems getting 
QuantLibAddIn compiled from the actual development backup tar-ball. With QL
and ObjectHandler 
everything went fine. Here is what I did (Linux as OS):

- Downloaded the development tar ball and extracted it locally.

- Set CVSROOT to the just extracted local CVS repository and checked out the

modules QuantLib, ObjectHandler and QuantLibAddin.

- Compiled QuantLib and ObjectHandler successfully like that:
$ ./autogen.sh 
$ ./configure --prefix=`pwd`
$ make 
$ make install

- Tried to compile QuantLibAddin like that:
$ ./autogen.sh
$ ./configure --prefix=`pwd` CPPFLAGS="-I<PATH_TO_OBJECTHANDLER>
-I<PATH_TO_QUANTLIB>/include" LDFLAGS="-L<PATH_TO_OBJECTHANDLER>/lib
-L<PATH_TO_QUANTLIB>/lib"
$ make

This make command seems to compile and link the directory
QuantLibAddin/qla/objects successfully 
but runs into problems with the directory QuantLibAddin/qla/functions. Here
is the end of the generated output:

--- SCHNIPP ---
g++ -DHAVE_CONFIG_H -I. -I. -I../../qla -I../..
-I/home/wpe/projects/quantlib_cvs_devel/ObjectHandler/
-I/home/wpe/projects/quantlib_cvs_devel/QuantLib/include -g -O2 -Wall -MT
vanillaoption.lo -MD -MP -MF .deps/vanillaoption.Tpo -c vanillaoption.cpp -o
vanillaoption.o >/dev/null 2>&1
/bin/sh ../../libtool --mode=link g++  -g -O2 -Wall
-L/home/wpe/projects/quantlib_cvs_devel/ObjectHandler/lib
-L/home/wpe/projects/quantlib_cvs_devel/QuantLib/lib -o libObjects.la
asianoption.lo barrieroption.lo basketoption.lo cliquetoption.lo
dividendvanillaoption.lo forwardvanillaoption.lo optionutils.lo
stochasticprocess.lo vanillaoption.lo
ar cru .libs/libObjects.a .libs/asianoption.o .libs/barrieroption.o
.libs/basketoption.o .libs/cliquetoption.o .libs/dividendvanillaoption.o
.libs/forwardvanillaoption.o .libs/optionutils.o .libs/stochasticprocess.o
.libs/vanillaoption.o
ranlib .libs/libObjects.a
creating libObjects.la
(cd .libs && rm -f libObjects.la && ln -s ../libObjects.la libObjects.la)
make[3]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla/objects'
Making all in functions
make[3]: Entering directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla/functions'
make[3]: *** No rule to make target `options.cpp', needed by `options.lo'.
Stop.
make[3]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla/functions'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/opt/projects/quantlib_cvs_devel/QuantLibAddin/qla'
make: *** [all-recursive] Error 1
[wpe@metallica QuantLibAddin]$
--- SCHNAPP ---

Having a look in the corresponding QuantLibAddin/qla/functions/Makefile it
seems that it expects a source file options.cpp. However in the 
corresponding directory there is no such file.

Any help would be highly appreciated. Thanks in advance.


wpe

[Quantlib-dev] [ quantlib-Bugs-1143732 ] VC6 Compliation Error

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

Bugs item #1143732, was opened at 2005-02-18 13:01
Message generated for change (Comment added) made by nando
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1143732&group_id=12740

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Chi-Wai C Lee (chiwai_lee)
Assigned to: Nobody/Anonymous (nobody)
Summary: VC6 Compliation Error

Initial Comment:
Hi there,

I am new to QuantLib 0.3.7 which now requires boost.  I 
tried to complie the testsuite files under MS VC++ 6.0 
and got the following errors.  Can anybody tell me what 
have I done wrong?

--------------------Configuration: testsuite - Win32 
Release--------------------
Linking...
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::~basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >
(void)" (??1?$basic_string@
DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAE@XZ) already defined in 
americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: bool 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Grow(unsigned int,bool)" (?_Grow@?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@AAE
_NI_N@Z) already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >(char const *,class basic_st
ring<char,struct std::char_traits<char>,class 
std::allocator<char> >::allocator<char> const &)" (??0?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAE@PBDABV?
$allocator@D@1@@Z) already defined in 
americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > & 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::assign(char co
nst *,unsigned int)" (?assign@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@QAEAAV12@PBDI@Z) already 
defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: void 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Tidy(bool)" (?_Tidy@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEX_N@Z) alread
y defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > & 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::assign(class s
td::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > 
const &,unsigned int,unsigned int)" (?assign@?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAEAAV12@ABV12@II@Z) 
already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::ios_base::Init::Init(void)" (??
0Init@ios_base@std@@QAE@XZ) already defined in 
libcpmt.lib(iostream.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::ios_base::Init::~Init(void)" (??
1Init@ios_base@std@@QAE@XZ) already defined in 
libcpmt.lib(iostream.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::_Winit::_Winit(void)" (??
0_Winit@std@@QAE@XZ) already defined in libcpmt.lib
(wiostrea.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::_Winit::~_Winit(void)" (??
1_Winit@std@@QAE@XZ) already defined in libcpmt.lib
(wiostrea.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: void 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Eos(unsigned int)" (?_Eos@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEXI@Z) a
lready defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: void 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Copy(unsigned int)" (?_Copy@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEXI@Z)
 already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "void __cdecl 
std::_Xlen(void)" (?_Xlen@std@@YAXXZ) already 
defined in libcpmt.lib(string.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
unsigned int __thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::max_size(void)const " (?max_size@?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@st
d@@QBEIXZ) already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > & 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::append(class s
td::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > 
const &,unsigned int,unsigned int)" (?append@?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAEAAV12@ABV12@II@Z) 
already defined in matrices.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >(class basic_string<char,str
uct std::char_traits<char>,class std::allocator<char> 
>::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > const &)" (??0?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@QAE@ABV01@@Z) already 
defined in libboos
t_unit_test_framework-vc6-mt-s-1_32.lib
(unit_test_log.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >  
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::substr(unsigned
 int,unsigned int)const " (?substr@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@QBE?AV12@II@Z) already 
defined in libboost_unit_test_framework-vc6-mt-s-
1_32.lib(test_tools.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: void 
__thiscall std::basic_ostringstream<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::`vbase destructor'(void)" (??_D?
$basic_ostringstream@DU?$char_traits@D@std@@V?
$allocator@D@2
@@std@@QAEXXZ) already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: virtual 
__thiscall std::basic_ostream<char,struct 
std::char_traits<char> >::~basic_ostream<char,struct 
std::char_traits<char> >(void)" (??1?
$basic_ostream@DU?
$char_traits@D@std@@@std@@UAE@XZ) alread
y defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: virtual 
__thiscall std::basic_ios<char,struct 
std::char_traits<char> >::~basic_ios<char,struct 
std::char_traits<char> >(void)" (??1?$basic_ios@DU?
$char_traits@D@std@@@std@@UAE@XZ) already 
defined in
 americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: virtual 
__thiscall std::ios_base::~ios_base(void)" (??
1ios_base@std@@UAE@XZ) already defined in libcpmt.lib
(ios.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: virtual 
__thiscall std::basic_streambuf<char,struct 
std::char_traits<char> >::~basic_streambuf<char,struct 
std::char_traits<char> >(void)" (??1?
$basic_streambuf@DU?
$char_traits@D@std@@@std@@UAE@XZ) 
already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "protected: 
void __thiscall std::basic_stringbuf<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Tidy(void)" (?_Tidy@?$basic_stringbuf@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@IAEXXZ) 
already defined in europeanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >  
__thiscall std::basic_ostringstream<char,struct 
std::char_traits<char>,class std::allocator<char> >::str
(void
)const " (?str@?$basic_ostringstream@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@QBE?AV?$basic_string@DU?
$char_traits@D@std@@V?$allocator@D@2@@2@XZ) 
already defined in libboost_unit_test_framework-vc6-mt-
s-1_32.lib(test_tools.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "class 
std::basic_ostream<char,struct std::char_traits<char> 
> & __cdecl std::operator<<(class 
std::basic_ostream<char,struct std::char_traits<char> 
> &,char const *)" (??6std@@YAAAV?
$basic_ostream@DU?$char_
traits@D@std@@@0@AAV10@PBD@Z) already defined 
in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "protected: 
void __thiscall std::basic_stringbuf<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Init(char const *,unsigned int,int)" (?_Init@?
$basic_stringbuf@DU?$char_traits@D@std@@V?$all
ocator@D@2@@std@@IAEXPBDIH@Z) already defined in 
americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: int 
__thiscall std::basic_stringbuf<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Mode(int)" (?_Mode@?$basic_stringbuf@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEHH@Z) alr
eady defined in asianoptions.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "protected: 
__thiscall std::basic_streambuf<char,struct 
std::char_traits<char> >::basic_streambuf<char,struct 
std::char_traits<char> >(void)" (??0?
$basic_streambuf@DU?
$char_traits@D@std@@@std@@IAE@XZ) alread
y defined in asianoptions.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::basic_ostream<char,struct 
std::char_traits<char> >::basic_ostream<char,struct 
std::char_traits<char> >(class 
basic_ostream<char,struct std::char_traits<char> 
>::basic_streambuf<char,
struct std::char_traits<char> > *,bool,bool)" (??0?
$basic_ostream@DU?
$char_traits@D@std@@@std@@QAE@PAV?
$basic_streambuf@DU?
$char_traits@D@std@@@1@_N1@Z) already defined in 
cliquetoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::_Lockit::~_Lockit(void)" (??
1_Lockit@std@@QAE@XZ) already defined in libcpmt.lib
(xlock.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::_Lockit::_Lockit(void)" (??
0_Lockit@std@@QAE@XZ) already defined in libcpmt.lib
(xlock.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: void 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Split(void)" (?_Split@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEXXZ) alread
y defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "void __cdecl 
std::_Xran(void)" (?_Xran@std@@YAXXZ) already 
defined in libcpmt.lib(string.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: virtual 
__thiscall exception::~exception(void)" (??
1exception@@UAE@XZ) already defined in LIBCMT.lib
(stdexcpt.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: 
__thiscall exception::exception(class exception const 
&)" (??0exception@@QAE@ABV0@@Z) already defined in 
LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: int 
__thiscall type_info::operator==(class type_info const &)
const " (??8type_info@@QBEHABV0@@Z) already 
defined in LIBCMT.lib(typinfo.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: _sprintf 
already defined in LIBCMT.lib(sprintf.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: _tolower 
already defined in LIBCMT.lib(tolower.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: _toupper 
already defined in LIBCMT.lib(toupper.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: 
__thiscall exception::exception(char const * const &)" 
(??0exception@@QAE@ABQBD@Z) already defined in 
LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: 
__thiscall exception::exception(void)" (??
0exception@@QAE@XZ) already defined in LIBCMT.lib
(stdexcpt.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: _memmove 
already defined in LIBCMT.lib(memmove.obj)
libcpmt.lib(locale.obj) : error LNK2005: "public: class 
std::locale & __thiscall std::locale::_Addfac(class 
std::locale::facet *,unsigned int,unsigned int)" (?
_Addfac@locale@std@@QAEAAV12@PAVfacet@12@II@Z
) already defined in msvcprt.lib(MSVCP60.dll)
libcpmt.lib(locale.obj) : error LNK2005: "public: __thiscall 
std::_Locinfo::_Locinfo(char const *)" (??
0_Locinfo@std@@QAE@PBD@Z) already defined in 
msvcprt.lib(MSVCP60.dll)
libcpmt.lib(locale.obj) : error LNK2005: "public: __thiscall 
std::_Locinfo::~_Locinfo(void)" (??
1_Locinfo@std@@QAE@XZ) already defined in 
msvcprt.lib(MSVCP60.dll)
libcpmt.lib(xwctomb.obj) : error LNK2005: __Getcvt 
already defined in msvcprt.lib(MSVCP60.dll)
LINK : warning LNK4098: defaultlib "MSVCRT" conflicts 
with use of other libs; use /NODEFAULTLIB:library
build\Release/testsuite.exe : fatal error LNK1169: one or 
more multiply defined symbols found
Error executing link.exe.

testsuite.exe - 47 error(s), 1 warning(s)


Many thanks.

Regards,

Chi-Wai


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

>Comment By: Ferdinando Ametrano (nando)
Date: 2005-02-18 14:09

Message:
Logged In: YES 
user_id=34616

you're probably mixing up runtime libraries with static
libraries, something which shouldn't happen if you build
QuantLib and Boost as they are out of the box.

BTW why using 0.3.7 if you're new to QuantLib? just use the
last version available, which is 0.3.8

Try again:
1) get the latest service pack for VC6 (version 5 or 6)
2) upgrade to QuantLib 0.3.8
3) download and build Boost 1.32
4) build QuantLib

please write on the user mailing list about any further problem.

thank you

ciao -- Nando

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

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

[Quantlib-dev] [ quantlib-Bugs-1143732 ] VC6 Compliation Error

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

Bugs item #1143732, was opened at 2005-02-18 12:01
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=1143732&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chi-Wai C Lee (chiwai_lee)
Assigned to: Nobody/Anonymous (nobody)
Summary: VC6 Compliation Error

Initial Comment:
Hi there,

I am new to QuantLib 0.3.7 which now requires boost.  I 
tried to complie the testsuite files under MS VC++ 6.0 
and got the following errors.  Can anybody tell me what 
have I done wrong?

--------------------Configuration: testsuite - Win32 
Release--------------------
Linking...
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::~basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >
(void)" (??1?$basic_string@
DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAE@XZ) already defined in 
americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: bool 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Grow(unsigned int,bool)" (?_Grow@?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@AAE
_NI_N@Z) already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >(char const *,class basic_st
ring<char,struct std::char_traits<char>,class 
std::allocator<char> >::allocator<char> const &)" (??0?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAE@PBDABV?
$allocator@D@1@@Z) already defined in 
americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > & 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::assign(char co
nst *,unsigned int)" (?assign@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@QAEAAV12@PBDI@Z) already 
defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: void 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Tidy(bool)" (?_Tidy@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEX_N@Z) alread
y defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > & 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::assign(class s
td::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > 
const &,unsigned int,unsigned int)" (?assign@?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAEAAV12@ABV12@II@Z) 
already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::ios_base::Init::Init(void)" (??
0Init@ios_base@std@@QAE@XZ) already defined in 
libcpmt.lib(iostream.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::ios_base::Init::~Init(void)" (??
1Init@ios_base@std@@QAE@XZ) already defined in 
libcpmt.lib(iostream.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::_Winit::_Winit(void)" (??
0_Winit@std@@QAE@XZ) already defined in libcpmt.lib
(wiostrea.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::_Winit::~_Winit(void)" (??
1_Winit@std@@QAE@XZ) already defined in libcpmt.lib
(wiostrea.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: void 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Eos(unsigned int)" (?_Eos@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEXI@Z) a
lready defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: void 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Copy(unsigned int)" (?_Copy@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEXI@Z)
 already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "void __cdecl 
std::_Xlen(void)" (?_Xlen@std@@YAXXZ) already 
defined in libcpmt.lib(string.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
unsigned int __thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::max_size(void)const " (?max_size@?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@st
d@@QBEIXZ) already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > & 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::append(class s
td::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > 
const &,unsigned int,unsigned int)" (?append@?
$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@QAEAAV12@ABV12@II@Z) 
already defined in matrices.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >(class basic_string<char,str
uct std::char_traits<char>,class std::allocator<char> 
>::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > const &)" (??0?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@QAE@ABV01@@Z) already 
defined in libboos
t_unit_test_framework-vc6-mt-s-1_32.lib
(unit_test_log.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >  
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::substr(unsigned
 int,unsigned int)const " (?substr@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@QBE?AV12@II@Z) already 
defined in libboost_unit_test_framework-vc6-mt-s-
1_32.lib(test_tools.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: void 
__thiscall std::basic_ostringstream<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::`vbase destructor'(void)" (??_D?
$basic_ostringstream@DU?$char_traits@D@std@@V?
$allocator@D@2
@@std@@QAEXXZ) already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: virtual 
__thiscall std::basic_ostream<char,struct 
std::char_traits<char> >::~basic_ostream<char,struct 
std::char_traits<char> >(void)" (??1?
$basic_ostream@DU?
$char_traits@D@std@@@std@@UAE@XZ) alread
y defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: virtual 
__thiscall std::basic_ios<char,struct 
std::char_traits<char> >::~basic_ios<char,struct 
std::char_traits<char> >(void)" (??1?$basic_ios@DU?
$char_traits@D@std@@@std@@UAE@XZ) already 
defined in
 americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: virtual 
__thiscall std::ios_base::~ios_base(void)" (??
1ios_base@std@@UAE@XZ) already defined in libcpmt.lib
(ios.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: virtual 
__thiscall std::basic_streambuf<char,struct 
std::char_traits<char> >::~basic_streambuf<char,struct 
std::char_traits<char> >(void)" (??1?
$basic_streambuf@DU?
$char_traits@D@std@@@std@@UAE@XZ) 
already defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "protected: 
void __thiscall std::basic_stringbuf<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Tidy(void)" (?_Tidy@?$basic_stringbuf@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@IAEXXZ) 
already defined in europeanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: class 
std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >  
__thiscall std::basic_ostringstream<char,struct 
std::char_traits<char>,class std::allocator<char> >::str
(void
)const " (?str@?$basic_ostringstream@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@QBE?AV?$basic_string@DU?
$char_traits@D@std@@V?$allocator@D@2@@2@XZ) 
already defined in libboost_unit_test_framework-vc6-mt-
s-1_32.lib(test_tools.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "class 
std::basic_ostream<char,struct std::char_traits<char> 
> & __cdecl std::operator<<(class 
std::basic_ostream<char,struct std::char_traits<char> 
> &,char const *)" (??6std@@YAAAV?
$basic_ostream@DU?$char_
traits@D@std@@@0@AAV10@PBD@Z) already defined 
in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "protected: 
void __thiscall std::basic_stringbuf<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Init(char const *,unsigned int,int)" (?_Init@?
$basic_stringbuf@DU?$char_traits@D@std@@V?$all
ocator@D@2@@std@@IAEXPBDIH@Z) already defined in 
americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: int 
__thiscall std::basic_stringbuf<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Mode(int)" (?_Mode@?$basic_stringbuf@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEHH@Z) alr
eady defined in asianoptions.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "protected: 
__thiscall std::basic_streambuf<char,struct 
std::char_traits<char> >::basic_streambuf<char,struct 
std::char_traits<char> >(void)" (??0?
$basic_streambuf@DU?
$char_traits@D@std@@@std@@IAE@XZ) alread
y defined in asianoptions.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::basic_ostream<char,struct 
std::char_traits<char> >::basic_ostream<char,struct 
std::char_traits<char> >(class 
basic_ostream<char,struct std::char_traits<char> 
>::basic_streambuf<char,
struct std::char_traits<char> > *,bool,bool)" (??0?
$basic_ostream@DU?
$char_traits@D@std@@@std@@QAE@PAV?
$basic_streambuf@DU?
$char_traits@D@std@@@1@_N1@Z) already defined in 
cliquetoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::_Lockit::~_Lockit(void)" (??
1_Lockit@std@@QAE@XZ) already defined in libcpmt.lib
(xlock.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "public: 
__thiscall std::_Lockit::_Lockit(void)" (??
0_Lockit@std@@QAE@XZ) already defined in libcpmt.lib
(xlock.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: "private: void 
__thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> 
>::_Split(void)" (?_Split@?$basic_string@DU?
$char_traits@D@std@@V?
$allocator@D@2@@std@@AAEXXZ) alread
y defined in americanoption.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: "void __cdecl 
std::_Xran(void)" (?_Xran@std@@YAXXZ) already 
defined in libcpmt.lib(string.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: virtual 
__thiscall exception::~exception(void)" (??
1exception@@UAE@XZ) already defined in LIBCMT.lib
(stdexcpt.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: 
__thiscall exception::exception(class exception const 
&)" (??0exception@@QAE@ABV0@@Z) already defined in 
LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: int 
__thiscall type_info::operator==(class type_info const &)
const " (??8type_info@@QBEHABV0@@Z) already 
defined in LIBCMT.lib(typinfo.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: _sprintf 
already defined in LIBCMT.lib(sprintf.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: _tolower 
already defined in LIBCMT.lib(tolower.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: _toupper 
already defined in LIBCMT.lib(toupper.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: 
__thiscall exception::exception(char const * const &)" 
(??0exception@@QAE@ABQBD@Z) already defined in 
LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: "public: 
__thiscall exception::exception(void)" (??
0exception@@QAE@XZ) already defined in LIBCMT.lib
(stdexcpt.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: _memmove 
already defined in LIBCMT.lib(memmove.obj)
libcpmt.lib(locale.obj) : error LNK2005: "public: class 
std::locale & __thiscall std::locale::_Addfac(class 
std::locale::facet *,unsigned int,unsigned int)" (?
_Addfac@locale@std@@QAEAAV12@PAVfacet@12@II@Z
) already defined in msvcprt.lib(MSVCP60.dll)
libcpmt.lib(locale.obj) : error LNK2005: "public: __thiscall 
std::_Locinfo::_Locinfo(char const *)" (??
0_Locinfo@std@@QAE@PBD@Z) already defined in 
msvcprt.lib(MSVCP60.dll)
libcpmt.lib(locale.obj) : error LNK2005: "public: __thiscall 
std::_Locinfo::~_Locinfo(void)" (??
1_Locinfo@std@@QAE@XZ) already defined in 
msvcprt.lib(MSVCP60.dll)
libcpmt.lib(xwctomb.obj) : error LNK2005: __Getcvt 
already defined in msvcprt.lib(MSVCP60.dll)
LINK : warning LNK4098: defaultlib "MSVCRT" conflicts 
with use of other libs; use /NODEFAULTLIB:library
build\Release/testsuite.exe : fatal error LNK1169: one or 
more multiply defined symbols found
Error executing link.exe.

testsuite.exe - 47 error(s), 1 warning(s)


Many thanks.

Regards,

Chi-Wai


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

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

Re: [Quantlib-dev] Questions on ObjectHandler and QuantLibAddin

[eric e. <eri...@gm...>]

Hi Walter

Many thanks for your message..

> - I am not sure what Widget/ObjectWidget is supposed to do. Is it an example
> for the usage of ObjectHandler?

Yes, it's intended as a standalone (independent of QuantLibAddin)
example for the usage of ObjectHandler.

> Is it related anyhow to graphical representation (widget = window + object)?

Not at all, and Widget was a poor choice of name for the example
class, I'll change this to Foo.

> - I don't quite understand the files interface.hpp/interface.cpp. Are they
> supposed to define a general interface?

Yes.  In fact a client could use ObjectHandler in a completely
object-oriented way, in which case there would be no need for an
interface layer.  But the Widget example mirrors QuantLibAddin's use
of ObjectHandler, i.e. linking an object-oriented environment
(QuantLib) to a procedural one (Excel), so the interface layer is
required in order to wrap class constructors/methods into functions.

> If so, why do they depend on ObjectWidget?

Well, in interface.cpp, objects of class ObjectWidget are constructed,
so there must be a dependency on ObjectWidget?

However looking at the code now I notice that the statement

    #include <objectwidget.hpp>

could be transferred from interface.hpp to interface.cpp and I will
make this change.

I'm not sure I've understood your question, please get back to me if not.

> - Other than the current development build in CVS, I could not yet find a
> released version of QuantLibAddin. Am I right?

Yes, that's right.  The first release will be in the next couple of weeks.

> - I am currently thinking about a (clever) way of remotely accessing QL
> functionality (via SOAP). In the documentation/mailing lists
> of ObjectHandler I read that this is also something you want to address in
> the future and that you want to establish an XML-based
> serialisation in order to achieve this (FpML). The problem I see is that for
> remote access, a client-side proxy-logic is required for each QL class.
> I assume that you want to achieve this client logic by various sub-classes
> of Objects. Is that correct? If so, this would result in completely
> "shadowing" QL classes with derivations of class Object. Am I right? If so,
> isn't that a pretty cumbersome way? I actually don't know
> any better way myself :(

It's very much my intention to anticipate distributed computing in the
design of ObjectHandler/QuantLibAddin.

I've been assuming that it will be necessary to install QL both on the
client and on each node of the grid.  Consider the case where you want
to price a QL object which is very resource intensive, or to price a
long list of simple objects.  The idea is that you construct the
object(s) on the client, transmit them to the grid to be priced, and
receive the results back to the client for display.  So QL is
installed on both client and grid but the hard work is done remotely.

Yes, the design dictates that for every QL object to be stored in
ObjectHandler, the relevant QL class must be wrapped in a class
descended from Object.

I considered a lot of different possibilities before settling on this
approach, and once you get into the details the chosen approach seems
the most elegant.  However it's entirely possible that I missed
something and if a superior design is possible then we'll use it. 
You'd be most welcome to look at it in more detail and come back with
more specific comments, that would be much appreciated.  I'd also be
very interested to hear in more detail about your ideas for
incorporating SOAP.

Regards
Eric

[Quantlib-dev] Questions on ObjectHandler and QuantLibAddin

[Penschke, W. <Wal...@co...>]

Hi,

with high interest I followed the announcement of ObjectHandler and
QuantLibAddin.

Got a couple of questions:

- I am not sure what Widget/ObjectWidget is supposed to do. Is it an example
for the usage of ObjectHandler?
Is it related anyhow to graphical representation (widget = window + object)?

- I don't quite understand the files interface.hpp/interface.cpp. Are they
supposed to define a general interface?
If so, why do they depend on ObjectWidget?

- Other than the current development build in CVS, I could not yet find a
released version of QuantLibAddin. Am I right?

- I am currently thinking about a (clever) way of remotely accessing QL
functionality (via SOAP). In the documentation/mailing lists
of ObjectHandler I read that this is also something you want to address in
the future and that you want to establish an XML-based
serialisation in order to achieve this (FpML). The problem I see is that for
remote access, a client-side proxy-logic is required for each QL class.
I assume that you want to achieve this client logic by various sub-classes
of Objects. Is that correct? If so, this would result in completely 
"shadowing" QL classes with derivations of class Object. Am I right? If so,
isn't that a pretty cumbersome way? I actually don't know 
any better way myself :(



wpe

[Quantlib-dev] [ quantlib-Bugs-1121342 ] Implementation of Monotone Spline

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

Bugs item #1121342, was opened at 2005-02-12 15:37
Message generated for change (Comment added) made by nando
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1121342&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implementation of Monotone Spline 

Initial Comment:
My email address is ala...@gm...

The implementation of the Hyman filter for the 
monotonising of the cubic spline is wrong.  The Hyman 
constraints are corrrectly specified but are applied to the
second derivative of the function (y'') rather than to y'.  
In order to implement correctly you need to

i) solve for the y'' values at the node in the usual way
ii) compute the first derivative values y' at each node
iii) generate the appropriate lagrange cubic polynomials 
through the node points with the correct y' value at the 
ends.

The incorrect approach does not guarantee to produce 
monotone splines.  

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

>Comment By: Ferdinando Ametrano (nando)
Date: 2005-02-14 11:20

Message:
Logged In: YES 
user_id=34616

why do you say that the contraints are "applied to the
second derivative of the function (y'') rather than to y'." ?

I wrote the code some time ago and I might be rusty, but it
looks to me that the Hyman filter is correctly applied to
the first derivative.

Beside the test suite is able to correctly reproduce Hyman
numerical examples.

Do you have a numerical examples to show a possible
monotonicity failure of the current implementation?

thank you


ciao -- Nando

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

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

[Quantlib-dev] [ quantlib-Bugs-1121342 ] Implementation of Monotone Spline

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

Bugs item #1121342, was opened at 2005-02-12 06:37
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=1121342&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implementation of Monotone Spline 

Initial Comment:
My email address is ala...@gm...

The implementation of the Hyman filter for the 
monotonising of the cubic spline is wrong.  The Hyman 
constraints are corrrectly specified but are applied to the
second derivative of the function (y'') rather than to y'.  
In order to implement correctly you need to

i) solve for the y'' values at the node in the usual way
ii) compute the first derivative values y' at each node
iii) generate the appropriate lagrange cubic polynomials 
through the node points with the correct y' value at the 
ends.

The incorrect approach does not guarantee to produce 
monotone splines.  

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

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

Re: [Quantlib-dev] List of QuantLibXL Functions

[eric e. <eri...@gm...>]

For info I revise (retract!) comments I made below to reflect feedback
from Nando:

> >    Just to get this straight:  QuantLibAddIn is going to do away with
> > QuantLibXL by taking all of it's functionality.

> Yes, QuantLibAddin will be extended to support all functions currently
> present in QuantLibXL and the goal will be complete backward
> compatibility, so that a spreadsheet based on QuantLibXL can load
> QuantLibAddin and see the same results.

No.  QuantLibXL won't be ported to QuantLibAddin.  If QuantLibXL
support is discontinued the last version will always be available and
people who need backward compatibility can just use that.  Where
sensible QuantLibXL functionality may be replicated in QuantLibAddin,
possibly with a revised interface.

Regards,
Eric

Re: [Quantlib-dev] FpML

[Fabrice C. <fab...@gm...>]

Bonjour,

My sourceforge account is fcarrega.

Here is a proposal :=20

Concerning development, I will take firstly a little time to read some
litterature about FpML  and draw a first UML model.

If you approve it, then I'll start coding.


Bonne journ=E9e,

Fabrice

Re: [Quantlib-dev] what do I need to make run an xll ?

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

On 02/10/05 10:20:51, JOSHI, Mark, Group Risk Mgmt wrote:
> We've come across this problem with xlls built under visual C++ .net .
> There are a couple of dlls that the xll requires and returns
> a library not recognized error if you don't have them.

Mark,
	did you download the xll binaries, or did you build it yourself?
In the latter case, you might want to try changing some compilation =20
settings. I don't have .NET, but there should be a project setting (on VC6 =
=20
it used to be under 'C++/Code generation') letting you choose the run-time =
=20
library to use. You should have the alternative between depending on DLLs =20
or linking the run-time library statically.

Hope this helps,
	Luigi


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

Weiler's Law:
        Nothing is impossible for the man who doesn't have to
do it himself.

Re: [Quantlib-dev] FpML

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

Hello,

On 02/10/05 23:24:07, Fabrice Carrega wrote:
>=20
> The question is : what will be the adapted organization for
> QuantLib-FpML development ?

To begin with, we can create an empty QuantLib-FpML module on the CVS =20
server to which you and David will be given write access (we'll need your =20
Sourceforge user names for this.) This way you'll have a common repository =
=20
for working on the project, and interested parties will be able to look at =
=20
your latest and greatest.

Also, you might want to choose one or two simple instruments to tackle as =20
test cases (European stock option? Zero-coupon bond?) This way I can go =20
ahead and start implementing their term-sheet thing in the library while =20
you set up the project.

As for organizing the development proper: we'll be there for answering any =
=20
questions and to help out when possible, but you and David are in charge---=
=20
it's up to you to choose what suits you best...

Later,
	Luigi


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

Things should be made as simple as possible, but no simpler.
-- Albert Einstein

Re: Fwd: [Quantlib-dev] FpML

[Fabrice C. <fab...@gm...>]

Hello,

Allright, that's clear to me now; maybe it's one of the clearest
things in my messy brain ; )

The question is : what will be the adapted organization for
QuantLib-FpML development ?


Bonne nuit,

Fabrice

On Thu, 10 Feb 2005 21:37:57 +0000, eric ehlers <eri...@gm...> wro=
te:
> Hi Fabrice,
>=20
> On Thu, 10 Feb 2005 19:35:28 +0100, Fabrice Carrega
> <fab...@gm...> wrote:
> > Hi all,
> >
> > So I would sum up what I have understood concerning FpML / XML developm=
ent.
> >
> > - QuantLib-FpML would be a library implemented in QuantLibAddin
> > permitting one to import indirectly data described in FpML in QuantLib
> > (and to export a QuantLib object to FpML)
>=20
> QuantLib-FpML and QuantLibAddin are separate, and QuantLib-FpML will
> be used both by QuantLibAddin and by other QuantLib clients unrelated
> to QuantLibAddin.
>=20
> QuantLibAddin(/ObjectHandler) are just utilities peripheral to
> QuantLib which provide a high-level API that allows QuantLib to be
> accessed from spreadsheets etc.
>=20
> Any industrial-strength app will directly use QuantLib's native C++
> API, and that app can use QuantLib-FpML, TermSheets etc. without
> reference to ObjectHandler/QuantLibAddin.
>=20
> QuantLibAddin would also use QuantLib-FpML as you describe above (and
> as described in more detail earlier in this thread).
>=20
> > - FpML would be translated to and from QuantLib::TermSheet
>=20
> Yes.  The purpose of QuantLib-FpML is to convert FpML >>
> QuantLib::TermSheet and vice versa.
>=20
> > - QuantLib-FpML abstract level would be implemented in ObjectHandler
>=20
> Yes, it's true that part of adapting QuantLibAddin/ObjectHandler to
> support FpML will include extending ObjectHandler to provide an
> abstract framework for FpML:
> - The abstract base class Object would be extended to include
> Serialize/Deserialize functions, which would be overridded
> appropriately by the QuantLibAddin classes descended from Object
> - The global ObjectHandler class may be extended to include
> Load/Unload functions, which would call Object->Deserialize and
> Object->Serialize.
>=20
> But as mentioned above, applications which access QuantLib directly
> can use QuantLib-FpML, TermSheets etc. without reference to
> ObjectHandler/QuantLibAddin.
>=20
> > - Modifications of some QuantLib classes would be needed to implement
> > a constructor taking a TermSheet as an argument
>=20
> Yes.  Those QuantLib::Instruments which are to have an FpML
> representation will be extended to have new constructors accepting a
> TermSheet as input.
>=20
> > - There would be no direct link between FpML and QuantLib objects
>=20
> Correct.
>=20
> > - QuantLib-XML is QuantLib-FpML evil twin for classes not described in
> > the FpML standard, which development would follow the same path, BUT
> > the import / export language (based on XML)
> >
> > a) needs to be chosen (if existing)
> > b) or needs to be created (if not)
>=20
> I'd say that QuantLib classes which need to be (de)serialized, but
> which are outside the scope of FpML, will be (de)serialized to/from
> XML, using a format defined by us - this is the purpose of the
> QuantLib-XML module Nando mentioned.
>=20
> > Bonne soir=E9e,
> >
> > Fabrice
>=20
> Bonne soir=E9e,
>=20
> Eric
>

Re: Fwd: [Quantlib-dev] FpML

[eric e. <eri...@gm...>]

Hi Fabrice,

On Thu, 10 Feb 2005 19:35:28 +0100, Fabrice Carrega
<fab...@gm...> wrote:
> Hi all,
>=20
> So I would sum up what I have understood concerning FpML / XML developmen=
t.
>=20
> - QuantLib-FpML would be a library implemented in QuantLibAddin
> permitting one to import indirectly data described in FpML in QuantLib
> (and to export a QuantLib object to FpML)

QuantLib-FpML and QuantLibAddin are separate, and QuantLib-FpML will
be used both by QuantLibAddin and by other QuantLib clients unrelated
to QuantLibAddin.

QuantLibAddin(/ObjectHandler) are just utilities peripheral to
QuantLib which provide a high-level API that allows QuantLib to be
accessed from spreadsheets etc.

Any industrial-strength app will directly use QuantLib's native C++
API, and that app can use QuantLib-FpML, TermSheets etc. without
reference to ObjectHandler/QuantLibAddin.

QuantLibAddin would also use QuantLib-FpML as you describe above (and
as described in more detail earlier in this thread).

> - FpML would be translated to and from QuantLib::TermSheet

Yes.  The purpose of QuantLib-FpML is to convert FpML >>
QuantLib::TermSheet and vice versa.

> - QuantLib-FpML abstract level would be implemented in ObjectHandler

Yes, it's true that part of adapting QuantLibAddin/ObjectHandler to
support FpML will include extending ObjectHandler to provide an
abstract framework for FpML:
- The abstract base class Object would be extended to include
Serialize/Deserialize functions, which would be overridded
appropriately by the QuantLibAddin classes descended from Object
- The global ObjectHandler class may be extended to include
Load/Unload functions, which would call Object->Deserialize and
Object->Serialize.

But as mentioned above, applications which access QuantLib directly
can use QuantLib-FpML, TermSheets etc. without reference to
ObjectHandler/QuantLibAddin.

> - Modifications of some QuantLib classes would be needed to implement
> a constructor taking a TermSheet as an argument

Yes.  Those QuantLib::Instruments which are to have an FpML
representation will be extended to have new constructors accepting a
TermSheet as input.

> - There would be no direct link between FpML and QuantLib objects

Correct.

> - QuantLib-XML is QuantLib-FpML evil twin for classes not described in
> the FpML standard, which development would follow the same path, BUT
> the import / export language (based on XML)
>=20
> a) needs to be chosen (if existing)
> b) or needs to be created (if not)

I'd say that QuantLib classes which need to be (de)serialized, but
which are outside the scope of FpML, will be (de)serialized to/from
XML, using a format defined by us - this is the purpose of the
QuantLib-XML module Nando mentioned.

> Bonne soir=E9e,
>=20
> Fabrice

Bonne soir=E9e,

Eric