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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |