STL compliant containers for XLOPER

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

STL compliant containers for XLOPER

Slava Mazur

Greetings,

 

For more than a year I’ve been using several stl-compliant wrappers around XLOPER structure, which I’ve developed as an extension to ObjectHandler libraries and which I found pretty helpful and efficient.

Although my solution is completely independent of ObjectHandler, I think it might make sense embedding my classes to it, so I’m considering contribution. Moreover, the latest developments in ObjectHandler and introduction of property_t class in particular makes me think that I ought to introduce my solution rather sooner than later.

 

Please find the attached an incomplete draft version of documentation of implemented classes in html format which gives an idea what is all about and let me know if this makes any sense so that I could discuss such a contribution with other parties involved. If not, then well, I’ll continue to use these classes as my own extension to ObjectHandler.

 

Thanks,

 

Slava Mazur

 

 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

XLLArrays.htm (21K) Download Attachment
XllVector.htm (4K) Download Attachment
XllCell.htm (6K) Download Attachment
XllCellPtr.htm (4K) Download Attachment
XllMatrix.htm (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: STL compliant containers for XLOPER

Eric Ehlers-2
Hi Slava,

Wow, that is one impressive design.  You have pushed the XLOPER/STL/Boost
combination to its limit.

Every XLL library tries to solve the problem of separating the guts of an
XLOPER from its interface, your "duality" idea is the most elegant approach I
have seen yet.  I have considered the idea of inheriting from XLOPER and could
not get it to work but I think you have found a way.

I like the fact that you use different classes depending on whether XLOPER
memory is to be managed by Excel or the XLL.  Many libraries including
ObjectHandler and XLW use a single class with a switch and I find your
approach safer and more intuitive.

Many thanks for considering the idea of contributing this to ObjectHandler.
The contribution would be welcome.  I understand that you would need to do
some negotiating on your side, please keep me posted.  Would you be able to
provide a statement authorizing the release of this code under the QuantLib
license?  Depending on you contract and the laws in your country it may be
that your thoughts are the property of your employer ;) in which case the
statement would have to come from them.

I'm in the process of packaging up the 0.9.6 release of ObjectHandler and
we're too late to add more to that, but we could get your classes onto the svn
trunk for inclusion in the next release.  I would put them in new folder
ObjectHandler/ohxl/xllcontainers in a sub-namespace.  As you note, your new
classes can be used independently of ObjectHandler and I would definitely want
to retain that orthogonality.

It would be good to get some example applications for XLL Containers, maybe
showing the usage of the classes with and without ObjectHandler?

As you observe, for ObjectHandler 0.9.6, boost::any is replaced everywhere by
property_t, which wraps boost::variant, because the latter is supported
natively by boost::serialization.  I'm not sure how this change impacts your
classes, which also use boost::any but in a different context.

Your design document could go into a new section of the ObjectHandler
documentation.  If you would like also to use doxygen compatible comments in
the code then those would be included in the reference manual.

Longer term I would consider the idea of using these classes for QuantLibXL,
but that would be more complicated.  The design of OH/QLA is platform
independent and all of the Excel bindings have C++ equivalents.  For example,
consider the conversion from a variant type to a QuantLib::Quote:

The abstract implementation of this conversion is
    convertQuote()
    in QuantLibAddin\qlo\conversions\conversion_tmpl.hpp
The C++ instantiation is
    convert2<boost::shared_ptr<QuantLib::Quote>, property_t>
    in QuantLibAddin\qlo\conversions\conversions.cpp
The Excel instantiation is
    convert2<boost::shared_ptr<QuantLib::Quote>, ConvertOper>
    in QuantLibXL\qlxl\conversions\opertovector.cpp

This approach allows us to have the conversion logic in one place where it is
reused by all platforms, for example if you serialize the Excel environment
into a stream that can be loaded by a QuantLib C++ application on Linux.  How
would that work if the ObjectHandler XLL and QuantLibXL were to use the XLL
Container classes in place of the existing Excel bindings?

Regards,
Eric

-------------------------
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
Distributed computing for pricing analytics - Use Microsoft Excel as a client
to the Grid

On Mon, August 11, 2008 19:33, Slava Mazur wrote:

> Greetings,
>
>
>
> For more than a year I've been using several stl-compliant wrappers
> around XLOPER structure, which I've developed as an extension to
> ObjectHandler libraries and which I found pretty helpful and efficient.
>
> Although my solution is completely independent of ObjectHandler, I think
> it might make sense embedding my classes to it, so I'm considering
> contribution. Moreover, the latest developments in ObjectHandler and
> introduction of property_t class in particular makes me think that I
> ought to introduce my solution rather sooner than later.
>
>
>
> Please find the attached an incomplete draft version of documentation of
> implemented classes in html format which gives an idea what is all about
> and let me know if this makes any sense so that I could discuss such a
> contribution with other parties involved. If not, then well, I'll
> continue to use these classes as my own extension to ObjectHandler.
>
>
>
> Thanks,
>
>
>
> Slava Mazur
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: STL compliant containers for XLOPER

Ferdinando M. Ametrano-3
Hi Slava

I join Eric in the appreciation for your proposal and second your contribution

On Wed, Aug 13, 2008 at 1:09 PM, Eric Ehlers <[hidden email]> wrote:
> [...] we could get your classes onto the svn
> trunk for inclusion in the next release.  I would put them in new folder
> ObjectHandler/ohxl/xllcontainers in a sub-namespace.  As you note, your new
> classes can be used independently of ObjectHandler and I would definitely want
> to retain that orthogonality.

what about having a dedicated XllContainers library? Then the XLL
specialization of ObjectHandler would just use it. It seems cleaner to
me

> It would be good to get some example applications for XLL Containers, maybe
> showing the usage of the classes with and without ObjectHandler?
> [... we ] have the conversion logic in one place where it is
> reused by all platforms, for example if you serialize the Excel environment
> into a stream that can be loaded by a QuantLib C++ application on Linux.  How
> would that work if the ObjectHandler XLL and QuantLibXL were to use the XLL
> Container classes in place of the existing Excel bindings?

I second this requests as they would help understanding how beneficial
would be merging your library into OH instead of keeping it separate
and how to effectively use it without losing the "platform neutrality"

ciao -- Nando

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: STL compliant containers for XLOPER

Eric Ehlers-2
Hi Nando,

On Mon, August 18, 2008 14:55, Ferdinando Ametrano wrote:
> what about having a dedicated XllContainers library? Then the XLL
specialization of ObjectHandler would just use it. It seems cleaner to me

Agreed.

Regards,
Eric

-------------------------
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
Distributed computing for pricing analytics - Use Microsoft Excel as a client
to the Grid





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: STL compliant containers for XLOPER

Slava Mazur
In reply to this post by Eric Ehlers-2
Hi Eric,

>The contribution would be welcome.  I understand that you would need to
do
>some negotiating on your side, please keep me posted.  Would you be
able to
>provide a statement authorizing the release of this code under the
QuantLib
>license?  Depending on you contract and the laws in your country it may
be
>that your thoughts are the property of your employer ;) in which case
the
>statement would have to come from them.

Negotiations are still in progress. Waiting for a decision from a higher
level management. Lower level is okay.

>It would be good to get some example applications for XLL Containers,
maybe
>showing the usage of the classes with and without ObjectHandler?

I think, a good one is how QuantLibXL::operToQlArray() could be
implemented with the help of XLL array. Consider the following, more
concise and more intuitive IMHO (BTW you might want to consider passing
the second parameter by const reference):

QuantLib::Array operToQlArray(const OPER &xVector,
   const std::string paramName) {
   try {
     xll::CellPtrConst<boost::any> pxVector(&xVector);

     OH_REQUIRE(!(pxVector->isError()),
                "input value '" << paramName << "' has type=error");
     if (pxVector->isMissingArg() || pxVector->isNil()) {
        return QuantLib::Array();
     } else if (pxVector->isArray()) {
        xll::VectorPtrConst<double> pv(&xVector);
        QuantLib::Array a(pv->size());
        std::copy (pv->begin(), pv->end(), a.begin());
        return a;
     } else if (pxVector->isString()) {
        using namespace boost::algorithm;
        xll::VectorPtrScoped<double> pv;
 
split(*pv,(std::string)*xll::CellPtrConst<std::string>(&xVector),
            is_any_of(",;"));
        QuantLib::Array a(pv->size());
        std::copy(pv->begin(), pv->end(), a.begin());
        return a;
     } else {
        xll::VectorPtrScopedExcel<double> pv(&xVector);
        QuantLib::Array a(pv->size());
        std::copy (pv->begin(), pv->end(), a.begin());
        return a;
     }
  } catch (const std::bad_cast &e) {
     OH_FAIL("operToVector: error converting parameter '" << paramName
<< "' : " << e.what());
  }
}

There are also several general examples in html files I sent to you
previously. Another one converts input sequence of numbers in a string
format to a double array and returns it as a range to Excel:

XLOPER * sequence2doubleArray (const char *input) {
   xll::VectorPtrWeakExcel<double> res;
   try {
      using namespace boost::algorithm;
      split(*res, input, is_any_of(",;"));
   } catch (const std::bad_cast &e) {
      res->setError();
   }
   return res;
}

>As you observe, for ObjectHandler 0.9.6, boost::any is replaced
everywhere >by
>property_t, which wraps boost::variant, because the latter is supported
>natively by boost::serialization.  I'm not sure how this change impacts
>your
>classes, which also use boost::any but in a different context.

I'm having a problem with such a design. Previously, when property value
type was boost::any and you handled OPER case as one of possible type a
property can have, I could use xll::CellPtrSharedExcel<boost::any> class
in my extension of ValueObject like the following and the function
ohPropertyValue worked correctly:

void MyValueObject::setProperty(const std::string& name,
   const boost::any& value)
{
   iterator it = properties_.find (name);
   if (it == properties_.end())
      throw PropertyNotFound;
   if (value.type() == typeid(OPER*))
      it->second = xll::CellPtrSharedExcel<boost::any>(value);
   else
      it->second = value;
}

boost::any MyValueObject::getProperty(const std::string& name) const
{
   iterator it = properties_.find (name);
   if (it == properties_.end())
      throw PropertyNotFound;
   boost::any w = it->second;
   if (w.type() == typeid(xll::CellPtrSharedExcel<boost::any>))
      return (OPER*)boost::any_cast <
xll::CellPtrSharedExcel<boost::any> >        (w);
   else return w;
}

My idea was to propose introduction of
xll::CellPtrSharedExcel<boost::any> as one of possible property type.
This way one could avoid unneccessary casts, transformations, and
duplication of data. However, with introduction of property_t you've
actually eliminated OPER and related types from the list of possible
types a property can have.

Now I have to convert my original data from OPER to one of acceptable
property_t type and thus to create a copy of data just to satisfy more
rigid property_t requrements. Note that by nature of my projects I'm
dealing with time series data, so creating unneccessary copies is highly
undesirable.
I'm wondering is it possible to generalize property_t concept making it
a template which depends on a variable list of types?

Thanks,

Slava Mazur



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev