You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(23) |
| 2002 |
Jan
(18) |
Feb
(20) |
Mar
(22) |
Apr
(41) |
May
(28) |
Jun
(25) |
Jul
(10) |
Aug
(7) |
Sep
(5) |
Oct
(20) |
Nov
(13) |
Dec
(11) |
| 2003 |
Jan
(28) |
Feb
(5) |
Mar
(6) |
Apr
(5) |
May
(17) |
Jun
(6) |
Jul
(45) |
Aug
(35) |
Sep
(24) |
Oct
(50) |
Nov
(53) |
Dec
(6) |
| 2004 |
Jan
(4) |
Feb
(10) |
Mar
(52) |
Apr
(46) |
May
(8) |
Jun
(25) |
Jul
(12) |
Aug
(6) |
Sep
(8) |
Oct
(8) |
Nov
(9) |
Dec
(7) |
| 2005 |
Jan
(18) |
Feb
(60) |
Mar
(19) |
Apr
(26) |
May
(14) |
Jun
(27) |
Jul
(8) |
Aug
(15) |
Sep
(19) |
Oct
(53) |
Nov
(20) |
Dec
(23) |
| 2006 |
Jan
(16) |
Feb
(27) |
Mar
(33) |
Apr
(51) |
May
(36) |
Jun
(25) |
Jul
(54) |
Aug
(30) |
Sep
(25) |
Oct
(67) |
Nov
(43) |
Dec
(13) |
| 2007 |
Jan
(23) |
Feb
(27) |
Mar
(55) |
Apr
(79) |
May
(60) |
Jun
(66) |
Jul
(46) |
Aug
(30) |
Sep
(90) |
Oct
(49) |
Nov
(85) |
Dec
(74) |
| 2008 |
Jan
(68) |
Feb
(59) |
Mar
(64) |
Apr
(28) |
May
(66) |
Jun
(35) |
Jul
(73) |
Aug
(76) |
Sep
(65) |
Oct
(46) |
Nov
(41) |
Dec
(19) |
| 2009 |
Jan
(46) |
Feb
(90) |
Mar
(51) |
Apr
(104) |
May
(13) |
Jun
(24) |
Jul
(20) |
Aug
(39) |
Sep
(109) |
Oct
(101) |
Nov
(117) |
Dec
(57) |
| 2010 |
Jan
(55) |
Feb
(42) |
Mar
(39) |
Apr
(22) |
May
(33) |
Jun
(41) |
Jul
(25) |
Aug
(52) |
Sep
(75) |
Oct
(60) |
Nov
(62) |
Dec
(52) |
| 2011 |
Jan
(70) |
Feb
(31) |
Mar
(26) |
Apr
(28) |
May
(17) |
Jun
(38) |
Jul
(51) |
Aug
(35) |
Sep
(27) |
Oct
(35) |
Nov
(10) |
Dec
(20) |
| 2012 |
Jan
(21) |
Feb
(29) |
Mar
(13) |
Apr
(37) |
May
(33) |
Jun
(12) |
Jul
(34) |
Aug
(27) |
Sep
(29) |
Oct
(35) |
Nov
(58) |
Dec
(27) |
| 2013 |
Jan
(27) |
Feb
(16) |
Mar
(40) |
Apr
(16) |
May
(34) |
Jun
(37) |
Jul
(6) |
Aug
(3) |
Sep
(4) |
Oct
(49) |
Nov
(13) |
Dec
(12) |
| 2014 |
Jan
(15) |
Feb
(21) |
Mar
(11) |
Apr
(13) |
May
(27) |
Jun
(60) |
Jul
(19) |
Aug
(29) |
Sep
(20) |
Oct
(28) |
Nov
(41) |
Dec
(15) |
| 2015 |
Jan
(33) |
Feb
(29) |
Mar
(26) |
Apr
(17) |
May
(2) |
Jun
(13) |
Jul
(21) |
Aug
(30) |
Sep
(22) |
Oct
(15) |
Nov
(46) |
Dec
(20) |
| 2016 |
Jan
(6) |
Feb
(5) |
Mar
(9) |
Apr
(15) |
May
(9) |
Jun
(4) |
Jul
(3) |
Aug
(4) |
Sep
(39) |
Oct
(8) |
Nov
(5) |
Dec
(8) |
| 2017 |
Jan
(4) |
Feb
(14) |
Mar
(4) |
Apr
(16) |
May
(5) |
Jun
(10) |
Jul
(25) |
Aug
(2) |
Sep
(5) |
Oct
(11) |
Nov
(8) |
Dec
(11) |
| 2018 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
(1) |
May
(4) |
Jun
(21) |
Jul
(8) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2019 |
Jan
(1) |
Feb
(5) |
Mar
(18) |
Apr
(9) |
May
(5) |
Jun
(21) |
Jul
(25) |
Aug
(25) |
Sep
(4) |
Oct
(2) |
Nov
(2) |
Dec
(5) |
| 2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(2) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(6) |
Dec
|
| 2021 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(4) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(9) |
Nov
(1) |
Dec
(5) |
| 2022 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
(2) |
May
(5) |
Jun
(3) |
Jul
(3) |
Aug
(3) |
Sep
(3) |
Oct
(14) |
Nov
|
Dec
(1) |
| 2023 |
Jan
(10) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2024 |
Jan
(8) |
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(4) |
Aug
(5) |
Sep
|
Oct
(4) |
Nov
(1) |
Dec
(1) |
| 2025 |
Jan
(3) |
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2026 |
Jan
(1) |
Feb
(12) |
Mar
|
Apr
(2) |
May
(8) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Slava M. <Sla...@ro...> - 2008-08-11 18:33:26
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>XLL Containers</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> <h1>XLL Containers</h1> <p><a href="#Introduction">Introduction</a><br> <a href="#common_requirements">Common Requirements</a><br> <A href="#BestPractices">Best Practices</A><br> <a href="#Examples">Examples</a><br> </p> <h2><a name="Introduction">Introduction</a></h2> <p>Implementation of Excel add-in functional interface often requires dealing with <strong>XLOPER</strong> structure created by Excel and a pointer to which passed to a user defined function. In addition, sometimes a user defined function should return a pointer to <strong>XLOPER</strong> back to Excel as a return value. <strong>XLOPER</strong> structure is actually a <em>variant</em> type, which can contain data of several different types, but the vast majority of all applicable treatments of <strong>XLOPER</strong> structure falls in the following three categories: <ul> <li>a single <em>cell</em>,</li> <li>a one-dimensional range, or a <em>vector</em> of elements</li> <li>a two-dimensional range, or a <em>matrix</em> of elements</li> </ul> The scope of the solution under consideration is limited to those three cases.</p> <p>To extract useful information from <strong>XLOPER</strong> structure application programmers usually implement various <em>converters</em> to transform <strong>XLOPER</strong> structure to and from base types: <pre>int, double</pre> or STL types: <pre>std::string, std::vector</pre>Such an approach although straightforward and easily comprehensible sometimes entails an undesirable overhead in terms of memory management and computational efficiency.<br/> In addition, <em>converters</em> usually support only limited set of input/output types making such a solution non-generic.<br/> Moreover, it is sometimes not quite easy to decide when memory allocated for <strong>XLOPER</strong> structure can be safely released, which often leads to memory leaks.</p> <p>The solution proposed here takes a different approach. It is based on classes-adaptors that wraps around <strong>XLOPER</strong> and allow to treat it as a single value of a specific base type, or as a container complying with requirements of STL.</p> <p>Thus, each class in the proposed solution can be viewed as a <em>dual</em> entity: for Excel such a class is seen as an <strong>XLOPER</strong> structure, but for application functions it can be treated as a C++ basis or container type. Such a <em>dualism</em> contributes a great deal to efficient memory management, code brevity and exception safety.</p> <p>Check out the <a href="#Examples">examples</a> of use of XLL containers below.</p> <p>The XLL containers template library provides six container class templates:</p> <div align="left"> <table border="1" cellpadding="4" cellspacing="0"> <tr> <td><a href="./XllCell.htm"><b>xll::Cell</b></a></td> <td><a href="../Include/XllArrays.hpp"><XllArrays.hpp></a></td> <td>A simple wrapper around <strong>XLOPER</strong>. Non-constructable and non-copyable.</td> </tr> <tr> <td><a href="./XllCellAlloc.htm"><b>xll::CellAlloc</b></a></td> <td><a href="../Include/XllArrays.hpp"><XllArrays.hpp></a></td> <td>A subclass of <b>xll::Cell</b> that allow for construction by a user. Copy-constructable.</td> </tr> <tr> <td><a href="./XllMatrix.htm"><b>xll::Matrix</b></a></td> <td><a href="../Include/XllArrays.hpp"><XllArrays.hpp></a></td> <td>A 2-d Excel range that can be treated as a matrix. Non-constructable and non-copyable.</td> </tr> <tr> <td><a href="./XllMatrixAlloc.htm"><b>xll::MatrixAlloc</b></a></td> <td><a href="../Include/XllArrays.hpp"><XllArrays.hpp></a></td> <td>A subclass of <b>xll::Matrix</b> that allow for construction by a user. Copy-constructable.</td> </tr> <tr> <td><a href="./XllVector.htm"><b>xll::Vector</b></a></td> <td><a href="../Include/XllArrays.hpp"><XllArrays.hpp></a></td> <td>A 1-d Excel range that can be treated as a standard vector. Non-constructable and non-copyable.</td> </tr> <tr> <td><a href="./XllVectorAlloc.html"><b>xll::VectorAlloc</b></a></td> <td><a href="../Include/XllArrays.hpp"><XllArrays.hpp></a></td> <td>A subclass of <b>xll::Vector</b> that allow for construction by a user. Copy-constructable.</td> </tr> </table> </div> <p>In addition, for each of <b>xll::Cell, xll::Matrix, xll::Vector</b> container classes the library provides implementation of five different pointer class concepts, which implement concepts of <a href="http://www.boost.org/libs/smart_ptr/scoped_ptr.htm">boost::scoped_pointer</a>, <a href="http://www.boost.org/libs/smart_ptr/shared_ptr.htm">boost::shared_pointer</a>, and <a href="http://www.boost.org/libs/smart_ptr/intrusive_ptr.html">boost::intrusive_pointer</a>:</p> <div align="left"> <table border="1" cellpadding="4" cellspacing="0"> <tr> <td><b>const-pointer</b></td> <td>Implements a const-pointer concept. Read-only, no memory management is assumed.</td> </tr> <tr> <td><b>weak-pointer</b></td> <td>A pointer, which is not responsible for releasing allocated memory within definition scope.<br/> Memory release happens later, either in a user provided <code>xlAutoFree</code> function or Excel itself takes care of the memory.</td> </tr> <tr> <td><b>scoped-pointer</b></td> <td>A pointer for an object, which is supposed to be created and used only within a current scope.<br/> Implements a <b>boost::scoped_pointer</b> concept.</td> </tr> <tr> <td><b>shared-pointer</b></td> <td>A pointer to a shared object to be used beyond the current scope, e.g. in <a href="http://www.objecthandler.org/">ObjectHandler</a> framework.<br/> Implements a <b>boost::shared_pointer</b> concept.</td> </tr> <tr> <td><b>temp-pointer</b></td> <td>A pointer to a temporal object allocated in a static memory of XLL framework.</td> </tr> </table> </div> <p>When implementing an Excel add-in functional interface the following five essentially different situation usually should be addressed:</p> <ol> <li>Excel passes a pointer to <strong>XLOPER</strong> to a user defined function that should be treated as an input, read-only data. A <b>const-pointer</b> type is suitable in this case.</li> <li>A user defined function must construct an <strong>XLOPER</strong> structure and pass it as a result to Excel. In this case a <b>weak-pointer</b> is a perfect choice.</li> <li>A local <strong>XLOPER</strong> object should be created to pass it to <code>Excel4v</code> function as a parameter-result (e.g. <code>xlfGetName</code>). A <b>scoped-pointer</b> is a convenient choice in this case.</li> <li>An Excel object should be constructed and stored in some external container (e.g. <a href="http://www.objecthandler.org/">ObjectHandler</a>) for future use. A <b>shared-pointer</b> is the only solution in this case.</li> <li>A temporal <strong>XLOPER</strong> should be created to pass it as an input parameter to <code>Excel4v</code> function. In this case a <b>temp-pointer</b> can be used. </ol> <p>The table below summarizes the references to all XLL Containers library classes and binds them to the use cases listed above (see also <a href="#Examples">examples</a> below):</p> <div align="left"> <table border="1" cellpadding="4" cellspacing="0"> <tr> <td><b>namespace xll::</b></td> <td><b>const-pointer</b><br/>use case 1</td> <td><b>weak-pointer</b><br/>use case 2</td> <td><b>scoped-pointer</b><br/>use case 3</td> <td><b>shared-pointer</b><br/>use case 4</td> <td><b>temp-pointer</b><br/>use case 5</td> </tr> <tr> <td><a href="./XllCell.htm"><b>Cell</b></a></td> <td><a href="./XllCellPtr.htm#const"><b>CellPtrConst</b></a></td> <td><a href="./CellPtrWeak.htm"><b>CellPtrWeak</b></a></td> <td><a href="./CellPtrScoped.htm"><b>CellPtrScoped</b></a></td> <td><a href="./CellPtrShared.htm"><b>CellPtrShared</b></a></td> <td><a href="./CellPtrTemp.htm"><b>CellPtrTemp</b></a></td> </tr> <tr> <td><a href="./XllMatrix.htm"><b>Matrix</b></a></td> <td><a href="./MatrixPtrConst.htm"><b>MatrixPtrConst</b></a></td> <td><a href="./MatrixPtrWeak.htm"><b>MatrixPtrWeak</b></a></td> <td><a href="./MatrixPtrScoped.htm"><b>MatrixPtrScoped</b></a></td> <td><a href="./MatrixPtrShared.htm"><b>MatrixPtrShared</b></a></td> <td><a href="./MatrixPtrTemp.htm"><b>MatrixPtrTemp</b></a></td> </tr> <tr> <td><a href="./XllVector.htm"><b>Vector</b></a></td> <td><a href="./VectorPtrConst.htm"><b>VectorPtrConst</b></a></td> <td><a href="./VectorPtrWeak.htm"><b>VectorPtrWeak</b></a></td> <td><a href="./VectorPtrScoped.htm"><b>VectorPtrScoped</b></a></td> <td><a href="./VectorPtrShared.htm"><b>VectorPtrShared</b></a></td> <td><a href="./VectorPtrTemp.htm"><b>VectorPtrTemp</b></a></td> </tr> </table> </div> <h2><a name="common_requirements">Common Requirements</a></h2> <p>All XLL Containers library class templates have a template parameter, <b>T</b>, which specifies the type of the object stored in a container. The following types can be specified: <ul> <li>integer types: <code>int, long, short, bool</code>; <li>floating point types: <code>float, double</code>; <li><code>std::string</code>; <li><a href="http://boost.org/doc/html/any.html"><b>boost::any</b></a> (which makes it an abstract container); <li>an error type cell: <code>xll::ErrorCode</code>; <li>a special case int type: <code>xll::Int</code> (to handle <code>xltypeInt</code> XLL type). </ul> </p> <h2><a name="BestPractices">Best Practices</a></h2> <p>Although it is possible to create an object of type <b>CellAlloc</b>, <b>MatrixAlloc</b>, or <b>VectorAlloc</b>, it is recommended to use pointer classes instead.<br/> The reason for this is that unlike object-containers, pointer classes explicitly specify the intention and reason for creating an object: <b>const-pointer</b> means read only data, <b>weak-pointer</b> indicates that the object created will be passed to Excel, <b>scoped-pointer</b> indicates local "in-scope" use of object, and <b>shared-pointer</b> means creation of a global, reusable object.<br/> Construction of object-containers is not safe in this respect since it is easy to make a mistake choosing an inappropriate allocation method.</p> <p>It is also not advisable using <b>static</b> objects since use of pointer classes discussed here makes it senseless.</p> <p>An access to the features of underlying class-containers can be done via usual pointer dereferencing technique as demonstrated in <a href="#Examples">examples</a> below.</p> <h2><a name="Examples">Examples</a></h2> <p>The following example demonstrates the use of a <b>const-pointer</b>.</p> <pre class="programlisting"> #include <XLLArrays.hpp> // In the function below it is assumed that parameter x represents a vector of doubles double Average (const XLOPER *x) { try { <a href="">xll::VectorPtrConst</a> <double> px (x); double res = 0; for (size_t i = 0; i < px->size(); ++i) res += px->at(i); // or res += (*px)[i]; return res / px->size(); } catch (const std::bad_cast &) { cerr << "Parameter x either not an array or its elements cannot be converted to double" << endl; } return 0; } </pre> <p><b><em>Notes.</em></b> <ol> <li><b>VectorPtrConst</b> class checks the type of input parameter x. If it cannot be converted to array of doubles the constructor throws a <b>bad_cast</b> exception.</li> <li>The code above works fine even if a user passes a single numeric cell to this function. <b>VectorPtrConst</b> will treat it as an array of size 1 automatically in this case. </ol></p> <p>The following example demonstrates the use of a <b>weak-pointer</b>.</p> <pre class="programlisting"> #include <XLLArrays.hpp> #include <algorithm> // This function generates an array of random numbers and returns it to Excel XLOPER * GenRandomVector (int how_many, int in_row) { xll::VectorPtrWeakExcel <int> px (how_many, in_row != 0); std::generate (px->begin(), px->end(), rand); return px; } </pre> <p><b><em>Note.</em></b> Memory allocated in the function above will be released by Excel. If instead of <b>VectorPtrWeakExcel</b> one used <b>VectorPtrWeak</b> class, the <code>xlAutoFree</code> function would have to be provided to release memory.</p> <p>The next example demonstrates the use of a <b>scoped-pointer</b> and a <b>temp-pointer</b>.<br/> <pre class="programlisting"> #include <XLLArrays.hpp> // A nifty implementation of xlAutoOpen interface function int xlAutoOpen() { using namespace xll; try { CellPtrScopedExcel <std::string> xDll; Excel(xlGetName, xDll, 0); Excel(xlfRegister, 0, 10, xDll, TempStr ("GenRandomVector"), //Function code name. TempStr ("PJJ"), //Parameter codes. TempStr ("GenRandomVector"), //Function display name. TempStr (""), TempStr ("1"), //Function type. TempStr ("My functions"), //Function category. TempStr (""), //shortcut text (command macros only). TempStr (""), //path to help file. TempStr ("Returns a vector of random numbers ") ); return 1; } catch (const std::exception &ex) { Excel(xlcAlert, 0, 1, TempStr(ex.what())); return 0; } catch (...) { Excel(xlcAlert, 0, 1, TempStr("Unknown exception")); return 0; } } </pre> <p>Note use of <b>CellPtrScopedExcel</b> class in the function above. We do not have to worry about the call of <code>xlFree</code> function to release memory allocated by Excel in <code>xlGetName</code> since implementation of <b>CellPtrScopedExcel</b> class takes care about it. If, however, we use <b>CellPtrScoped</b> class instead (and it is admittedly very easy to confuse) the code above most likely end up in a crash when <b>CellPtrScoped</b> destructor will try to release memory allocated by Excel in <code>xlGetName</code> call.</p> <p>The following example demonstrates the use of a <b>shared-pointer</b>.</p> <pre class="programlisting"> #include <XLLArrays.hpp> #include <boost/shared_ptr.hpp> #include <algorithm> // Calculates the sum of two arrays and returns the result to the outside world. boost::shared_ptr<XLOPER> SumArrays(const XLOPER *x, const XLOPER *y) { using namespace xll; VectorPtrConst <double> px(x); VectorPtrConst <double> py(y); VectorPtrShared <double> pz(px->size()); std::transform (px->begin(), px->end(), py->begin(), pz->begin(), std::plus); return boost::static_pointer_cast <XLOPER> (pz); } </pre> <p>Note that a shared pointer returned by the function above can be stored in <a href="http://www.objecthandler.org/">ObjectHandler</a>. Memory allocated by <b>VectorPtrShared</b> class is released in its destructor, which is called when reference counter for the instances of underlying object becomes zero.</p> <h2><a name="History">History</a> and Acknowledgements</h2> <p>April 2007. Original version.</p> <h2><a name="References">References</a></h2> <p>[<a name="XLOPER">XLOPER</a>] MSDN, <a href="http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/office97/html/SF7EF.asp"> The XLOPER Data Type</a></p> <p>Copyright 2007 ---</p> </body> </html> |
|
From: Luigi B. <lui...@gm...> - 2008-08-11 12:21:09
|
On Mon, 2008-08-11 at 09:35 +1000, Mark joshi wrote: > Looks like something's missing from the project file for testsuite Should work now. Luigi -- All generalizations are false, including this one. -- Mark Twain |
|
From: willshaw <wil...@gm...> - 2008-08-11 10:50:29
|
Hi, Eric, I just reinstalled my Excel 2003 this weekend. Now it works fine with 20 arguments. Thanks. BTW. My previous constructor function has 14 own-defined arguments, another is ObjectID. So plus Permanent, Trigger, Overwrite is 18. Just to clarify. Now it's all ok with 20 arguments. Eric Ehlers-2 wrote: > > Hello, > > On Wed, August 6, 2008 03:09, willshaw wrote: >> >> Hi, Eric, >> >> I just double check again. I defined own function with 15 >> arguments. But >> with extra 3 arguments, namely Permanent, Trigger, and >> Overwrite, there are >> actually 18 in Excel. > > That's a very good point. Certain parameters are generated > automatically: > - 4 for a Constructor - ObjectId, Permanent, Trigger, Overwrite > - 2 for a Member - ObjectId, Trigger > - 1 for a Utility - Trigger > These need to be taken into account when ensuring that the > total number of parameters does not exceed the limit of 20. > > I just did a quick test, adding dummy parameters to a > constructor function to get a total of 20 parameters (16 user > defined + 4 autogenerated). I tested the function in Excel and > it looks OK - it displays correctly in the Function Wizard and > seems to function as expected. Are you saying that a similar > test still fails for you? If so I again invite you to send me > your modifications so that I can recreate the problem on my > machine. > > I mentioned in an earlier email that it's possible to define > user functions with up to 30 parameters, with the limitation > that the Function Wizard displays descriptions for only the > first 20. I thought QuantLibXL did not support this trick but > I have just noticed that there is in fact an attempt to > implement this feature, but it is broken. I'll try to resolve > this when I can, for now I would advise sticking to the 20 > parameter limit. > >> But this does not matter really because I assume you will >> upgrade QuantLibXL >> to take advantage of Excel 2007. > > I certainly intend to but I don't need the upgrade myself right > now so it's not on my immediate todo list. > >> May I ask another question? What serializationIncludes and >> addinIncludes >> mean in XML files? > > serializationIncludes specifies the #include directives for > files autogenerated to QuantLibAddin\qlo\Serialization. > addinIncludes specifies the #include directives for files > autogenerated to QuantLibXL\qlxl\Functions. > The two values are usually the same. > > 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 > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > -- View this message in context: http://www.nabble.com/QuantLibXL-function-in-Excel%2C-limit-in-number-of-arguments--tp18464649p18923378.html Sent from the quantlib-dev mailing list archive at Nabble.com. |
|
From: Mark j. <mar...@gm...> - 2008-08-10 23:35:04
|
cliquetoption.obj : error LNK2019: unresolved external symbol "public: __thiscall QuantLib::PerformanceOptionPathPricer::PerformanceOptionPathPricer(enum QuantLib::Option::Type,double,class std::vector<double,class std::allocator<double> > const &)" (??0PerformanceOptionPathPricer@QuantLib@@QAE@W4Type@Option@1@NABV?$vector@NV?$allocator@N@std@@@std@@@Z) referenced in function "protected: virtual class boost::shared_ptr<class QuantLib::PathPricer<class QuantLib::Path,double> > __thiscall QuantLib::MCPerformanceEngine<struct QuantLib::GenericPseudoRandom<class QuantLib::MersenneTwisterUniformRng,class QuantLib::InverseCumulativeNormal>,class QuantLib::GenericRiskStatistics<class QuantLib::GenericGaussianStatistics<class QuantLib::GeneralStatistics> > >::pathPricer(void)const " (?pathPricer@?$MCPerformanceEngine@U?$GenericPseudoRandom@VMersenneTwisterUniformRng@QuantLib@@VInverseCumulativeNormal@2@@QuantLib@@V?$GenericRiskStatistics@V?$GenericGaussianStatistics@VGeneralStatistics@QuantLib@@@QuantLib@@@2@@QuantLib@@MBE?AV?$shared_ptr@V?$PathPricer@VPath@QuantLib@@N@QuantLib@@@boost@@XZ) quantlibtestsuite.obj : error LNK2019: unresolved external symbol "public: static class boost::unit_test::test_suite * __cdecl PagodaOptionTest::suite(void)" (?suite@PagodaOptionTest@@SAPAVtest_suite@unit_test@boost@@XZ) referenced in function "class boost::unit_test::test_suite * __cdecl init_unit_test_suite(int,char * * const)" (?init_unit_test_suite@@YAPAVtest_suite@unit_test@boost@@HQAPAD@Z) .\bin/QuantLib-test-suite-vc80-mt-0_9_7.exe : fatal error LNK1120: 2 unresolved external Looks like something's missing from the project file for testsuite |
|
From: Ferdinando A. <na...@am...> - 2008-08-07 14:07:27
|
On Thu, Aug 7, 2008 at 8:51 AM, <su...@us...> wrote: > Revision: 15348 > http://quantlib.svn.sourceforge.net/quantlib/?rev=15348&view=rev > [...] > --- branches/oh_functions/ObjectHandler/oh/utilities.cpp 2008-08-07 06:49:16 UTC (rev 15347) > +++ branches/oh_functions/ObjectHandler/oh/utilities.cpp 2008-08-07 06:51:19 UTC (rev 15348) >[...] > @@ -305,17 +318,20 @@ > } > } > OH_REQUIRE(b, "month outside valid range"); > - totalSecond -= days * SECS_PER_DAY; > + totalMSecond -= days * MILLISECS_PER_DAY; > > days -= pMonth[monthoffset - 1]; > > - hours = totalSecond / 3600; > - totalSecond -= hours * 3600; > - minutes = totalSecond / 60; > - seconds = totalSecond - minutes * 60; > + hours = totalMSecond / (3600 * 1000); > + totalMSecond -= (hours * 3600 * 1000) ; > + minutes = totalMSecond / (60 * 1000); > + totalMSecond -= minutes * 60 * 1000; > + seconds = totalMSecond / 60 * 1000; > + milliseconds = totalMSecond - seconds * 1000; if I get it right it should be: > + seconds = totalMSecond / 1000; > + milliseconds = totalMSecond - seconds * 1000; ciao -- Nando |
|
From: Eric E. <eri...@na...> - 2008-08-07 09:05:43
|
Hello, On Wed, August 6, 2008 03:09, willshaw wrote: > > Hi, Eric, > > I just double check again. I defined own function with 15 > arguments. But > with extra 3 arguments, namely Permanent, Trigger, and > Overwrite, there are > actually 18 in Excel. That's a very good point. Certain parameters are generated automatically: - 4 for a Constructor - ObjectId, Permanent, Trigger, Overwrite - 2 for a Member - ObjectId, Trigger - 1 for a Utility - Trigger These need to be taken into account when ensuring that the total number of parameters does not exceed the limit of 20. I just did a quick test, adding dummy parameters to a constructor function to get a total of 20 parameters (16 user defined + 4 autogenerated). I tested the function in Excel and it looks OK - it displays correctly in the Function Wizard and seems to function as expected. Are you saying that a similar test still fails for you? If so I again invite you to send me your modifications so that I can recreate the problem on my machine. I mentioned in an earlier email that it's possible to define user functions with up to 30 parameters, with the limitation that the Function Wizard displays descriptions for only the first 20. I thought QuantLibXL did not support this trick but I have just noticed that there is in fact an attempt to implement this feature, but it is broken. I'll try to resolve this when I can, for now I would advise sticking to the 20 parameter limit. > But this does not matter really because I assume you will > upgrade QuantLibXL > to take advantage of Excel 2007. I certainly intend to but I don't need the upgrade myself right now so it's not on my immediate todo list. > May I ask another question? What serializationIncludes and > addinIncludes > mean in XML files? serializationIncludes specifies the #include directives for files autogenerated to QuantLibAddin\qlo\Serialization. addinIncludes specifies the #include directives for files autogenerated to QuantLibXL\qlxl\Functions. The two values are usually the same. 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 |
|
From: willshaw <wil...@gm...> - 2008-08-06 02:09:42
|
Hi, Eric, I just double check again. I defined own function with 15 arguments. But with extra 3 arguments, namely Permanent, Trigger, and Overwrite, there are actually 18 in Excel. But this does not matter really because I assume you will upgrade QuantLibXL to take advantage of Excel 2007. May I ask another question? What serializationIncludes and addinIncludes mean in XML files? Thanks. Eric Ehlers-2 wrote: > > Hello, > > On Wed, July 23, 2008 02:14, willshaw wrote: >> >> Hi, to expose a function to Excel, I first define the > function >> interface in >> project "QuantLibObjects" under namespace QuantLibAddin, it >> should call the >> real function in QuantLib, then edit the xml in project >> "qlgensrc", then >> compile. No edit of autogenerated files. I use Excel 2003. > > Very strange. Please send me the smallest possible patch which > would allow me to recreate the problem - e.g. a handful of > files containing your edits which I could unzip onto a clean > install of 0.9.0. > > Thanks, > 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 > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > -- View this message in context: http://www.nabble.com/QuantLibXL-function-in-Excel%2C-limit-in-number-of-arguments--tp18464649p18843137.html Sent from the quantlib-dev mailing list archive at Nabble.com. |
|
From: Sylvain B. <syl...@gm...> - 2008-08-04 15:55:33
|
On 8/4/08, Luigi Ballabio <lui...@gm...> wrote: > On Wed, 2008-07-23 at 15:53 -0400, Sylvain Bertrand wrote: > > Anyway, I tried to change the QL_REAL from double to long double (it > > might actually partially solve my issue). > > > > But then I faced errors calling std::max with a long double on one > > side, and 0. on the other side. As everyone knows, 0. is a double, and > > max can only be called with two args of the same type. I would need > > 0.L here. > > Yes, or we might specify std::max<Real>(x, 0) so that the 0 gets > converted to the right type. In that case we would need to change all the calls to std::max on all the files (at least for consistency). Is there some kind of approval process, to ensure the owners of each file (or the whole QL group) are ok with that? > > I'm quite confident on the fact that less than 0.1% of users have ever > > thought of changing QL_REAL, but what if? Is QuantLib supposed to > > support other types of Real? > > We used the QL_REAL thing so that, in case one wanted to try and change > the default float type, we didn't have double hard-coded everywhere. But > we never tried very hard to make the library even compile with different > types. > > As for your spline calculations, if you need long doubles, just go ahead > and use long double. As the implementation relies heavily on matrix operations, I would need to use only long double matrices, which work if I set QL_REAL to long double for the whole library, since matrices are forced to the QL_REAL type. "QL_REAL = long double" would then have to be the default for QL releases, otherwise the user would run the risk of using the cubic splines with very poor results (in that case there should also be a warning to prevent the user from changing the setting back to double and use the splines). Is that something that would be acceptable? I personally don't think of it as the best option. Another option would be to transform the current Matrix class into a template to support different types, which would give each piece of code the freedom to use the default QL_REAL or use more precision when needed. Let me know what you think. Sylvain |
|
From: Luigi B. <lui...@gm...> - 2008-08-04 14:51:20
|
On Wed, 2008-07-16 at 09:44 +0200, =?ISO-8859-1?Q? Fr=E9d=E9ric_Degraeve _ wrote: > Also, I would like to understand where my mistake is. Now, I don't > find any solutions except making a c++ function that creates my > FittedBondDiscountCurve from simple parameters. I guess it is not a > clean solution. > > Firstly, I wrote a swig file to call FittedBondDiscountCurve from > Python. Secondly, I called it from a python script. Finally, this > prototype is not recognized. Try fully qualifying QuantLib::FittedBondDiscountCurve::FittingMethod in the constructor. If that fails, try exporting QuantLib::FittedBondDiscountCurve::FittingMethod trough SWIG. Luigi -- No, I'm not interested in developing a powerful brain. All I'm after is just a mediocre brain, something like the president of American Telephone and Telegraph Company. -- Alan Turing on the possibilities of a thinking machine, 1943. |
|
From: Luigi B. <lui...@gm...> - 2008-08-04 14:03:45
|
On Wed, 2008-07-23 at 15:53 -0400, Sylvain Bertrand wrote: > Anyway, I tried to change the QL_REAL from double to long double (it > might actually partially solve my issue). > > But then I faced errors calling std::max with a long double on one > side, and 0. on the other side. As everyone knows, 0. is a double, and > max can only be called with two args of the same type. I would need > 0.L here. Yes, or we might specify std::max<Real>(x, 0) so that the 0 gets converted to the right type. > I'm quite confident on the fact that less than 0.1% of users have ever > thought of changing QL_REAL, but what if? Is QuantLib supposed to > support other types of Real? We used the QL_REAL thing so that, in case one wanted to try and change the default float type, we didn't have double hard-coded everywhere. But we never tried very hard to make the library even compile with different types. As for your spline calculations, if you need long doubles, just go ahead and use long double. Luigi -- Weiler's Law: Nothing is impossible for the man who doesn't have to do it himself. |
|
From: Mark j. <mar...@gm...> - 2008-08-04 05:15:20
|
never mind, I probably just didn't update properly. mark |
|
From: Mark j. <mar...@gm...> - 2008-08-04 02:04:50
|
I did an update this morning. Test suite is looking for 0.9.6 when linking. Quantlib is producing the 0.9.5 version. So it fails to build. I 'm using VC8 I fixed it by changing the filename. What's the correct fix? thanks mark -- Quant Job Interview Questions and Answers is now out: www.markjoshi.com Assoc Prof Mark Joshi Centre for Actuarial Studies University of Melbourne My website is www.markjoshi.com |
|
From: Slava M. <Sla...@ro...> - 2008-07-31 20:01:15
|
Greetings, Is there any particular reason for restrictions in Period::frequency() method on the length in weeks and days? Firstly, it looks inconsistent with handling of months. Why in a similar manner couldn't it translate weeks and days via Frequency(52/length) and Frequency(366/length) respectively? Secondly, I have a real issue with such a restriction. I need to setup a fixed rate bond that pays coupon every 182 days unadjusted. So, in setting up a schedule I specified tenor as 182D or 26W, but the constructor of FixedRateBond object ends up in exception when such a schedule is passed as an input parameter. It would be okay for me if such a bond would have semiannual settings for frequency; moreover it looks like in majority cases "frequency" plays just a "decorative" role. Is there any workaround? Thanks, Slava Mazur |
|
From: Bojan N. <bo...@bn...> - 2008-07-31 11:53:05
|
Hi Luigi, Luigi Ballabio <lui...@gm...> writes: > gave up. I might give bazaar a try. Also, it would be interesting if > you had some comments on how to go the other way; i.e., how (if > possible) to merge one's changes back into the official Subversion > repository if one has write access to the latter. I have not tried this, but as far as I understand this is supported extremely well by the bzr-svn plugin: http://bazaar-vcs.org/BzrForeignBranches/Subversion#features In this case you would want to use bazaar to directly access the Sourceforge subversion repository rather than the mirror hosted on Launchpad. That is, with the plugin installed, you should be able to make a branch directly like this: bzr branch https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk/QuantLib And subsequently to publish your changes when you wish so with: bzr push https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk/QuantLib Best, Bojan -- Bojan Nikolic || http://www.bnikolic.co.uk |
|
From: Luigi B. <lui...@gm...> - 2008-07-30 19:39:07
|
On Jul 29, 2008, at 11:48 PM, Bojan Nikolic wrote: > I have written a little article on how I manage my experimental and > non-public changes to QuantLib using the bazaar distributed revision > control system. > > If you are interested, the article is available at: > > http://www.bnikolic.co.uk/blog/ql-ontop-bzr.html Bojan, thanks for the article---very interesting. I had tried something similar with svk, but I ran into technical problems and gave up. I might give bazaar a try. Also, it would be interesting if you had some comments on how to go the other way; i.e., how (if possible) to merge one's changes back into the official Subversion repository if one has write access to the latter. Luigi |
|
From: Luigi B. <lui...@gm...> - 2008-07-30 15:21:20
|
On Sun, 2008-07-20 at 11:23 +0000, mar...@us... wrote: > Revision: 15249 > http://quantlib.svn.sourceforge.net/quantlib/?rev=15249&view=rev > Author: markjoshi > Date: 2008-07-20 11:22:34 +0000 (Sun, 20 Jul 2008) > > Log Message: > ----------- > changed market model to use incremental statistics gathering. Hi Mark, did it work? Luigi -- The box said "Use Windows 95 or better," so I got a Macintosh. |
|
From: Bojan N. <bo...@bn...> - 2008-07-29 21:48:33
|
Dear All, I have written a little article on how I manage my experimental and non-public changes to QuantLib using the bazaar distributed revision control system. Examples where this can be useful are: * Tracking patches which are not yet ready for a public review and integration in the central source code tree * Extensions or changes to QuantLib that are intended to be permanently private but require revision control and tracking of the public source tree If you are interested, the article is available at: http://www.bnikolic.co.uk/blog/ql-ontop-bzr.html Comments welcome. Best, Bojan -- Bojan Nikolic || http://www.bnikolic.co.uk |
|
From: Eric E. <eri...@na...> - 2008-07-29 11:19:05
|
Hello, On Wed, July 23, 2008 02:14, willshaw wrote: > > Hi, to expose a function to Excel, I first define the function > interface in > project "QuantLibObjects" under namespace QuantLibAddin, it > should call the > real function in QuantLib, then edit the xml in project > "qlgensrc", then > compile. No edit of autogenerated files. I use Excel 2003. Very strange. Please send me the smallest possible patch which would allow me to recreate the problem - e.g. a handful of files containing your edits which I could unzip onto a clean install of 0.9.0. Thanks, Eric ------------------------- Eric Ehlers nazcatech sprl | Brussels | http://www.nazcatech.be Distributed computing for pricing analytics - Use Microsoft Excel as a client to the Grid |
|
From: Klaus S. <kl...@sp...> - 2008-07-27 11:01:33
|
Hi The y values (return value of the functions) have to be of type Real as the alogrithm rely on the SVD method... and looking back I think making the x values a template parameter is "overengineered" here. regards Klaus On Friday 25 July 2008 11:21:56 Silakhdar Krikeb wrote: > Hi > > The contructor of the class LinearLeastSquaresRegression takes three > argument of which two are std::vector<T>& while the the result of > the least square regression is save in a container of type Array, is there > any design reason for that and why can't the class Array just be extended > to a template class Array<T>? > > Thank you! > > Regards > > Silakhdar |
|
From: Silakhdar K. <sil...@gm...> - 2008-07-25 09:21:59
|
Hi The contructor of the class LinearLeastSquaresRegression takes three argument of which two are std::vector<T>& while the the result of the least square regression is save in a container of type Array, is there any design reason for that and why can't the class Array just be extended to a template class Array<T>? Thank you! Regards Silakhdar |
|
From: Sylvain B. <syl...@gm...> - 2008-07-23 19:53:32
|
Anyway, I tried to change the QL_REAL from double to long double (it might actually partially solve my issue). But then I faced errors calling std::max with a long double on one side, and 0. on the other side. As everyone knows, 0. is a double, and max can only be called with two args of the same type. I would need 0.L here. If QL_REAL was changed to float, it would produce the same error, and I would need 0.f here. I'm quite confident on the fact that less than 0.1% of users have ever thought of changing QL_REAL, but what if? Is QuantLib supposed to support other types of Real? Let me know how you guys feel... On 7/23/08, Sylvain Bertrand <syl...@gm...> wrote: > > I assume this has never been an issue for anyone... > > I've looked around in the limits.h and other headers in the stdlib and > boost, and I've come to the conclusion that increasing the precision of the > Real would probably have a lot of impacts. > > Is anyone here familiar with those matters? > > > On 7/22/08, Sylvain Bertrand <syl...@gm...> wrote: >> >> Hi, >> >> As I'm working on spline implementations, I've encountered issues with the >> precision of Real. >> >> The calculations I'm doing rely heavily on precision, and it is not an >> option for me to consider 1e-20 as 0 or 2.0/3 as 0.666667. >> >> 2 things here: >> - I want to raise to your attention the fact that the current spline >> implementation is also affected by this (though to a lesser extent) >> - I would like to know if any of you have used workarounds for this, and >> what you did >> >> Thanks >> >> Sylvain >> > > |
|
From: Sylvain B. <syl...@gm...> - 2008-07-23 14:50:09
|
I assume this has never been an issue for anyone... I've looked around in the limits.h and other headers in the stdlib and boost, and I've come to the conclusion that increasing the precision of the Real would probably have a lot of impacts. Is anyone here familiar with those matters? On 7/22/08, Sylvain Bertrand <syl...@gm...> wrote: > > Hi, > > As I'm working on spline implementations, I've encountered issues with the > precision of Real. > > The calculations I'm doing rely heavily on precision, and it is not an > option for me to consider 1e-20 as 0 or 2.0/3 as 0.666667. > > 2 things here: > - I want to raise to your attention the fact that the current spline > implementation is also affected by this (though to a lesser extent) > - I would like to know if any of you have used workarounds for this, and > what you did > > Thanks > > Sylvain > |
|
From: willshaw <wil...@gm...> - 2008-07-23 01:14:46
|
Hi, to expose a function to Excel, I first define the function interface in project "QuantLibObjects" under namespace QuantLibAddin, it should call the real function in QuantLib, then edit the xml in project "qlgensrc", then compile. No edit of autogenerated files. I use Excel 2003. Regards, Eric Ehlers-2 wrote: > > Hello, > > There is a limit of 20 arguments to QuantLibXL functions. I > have added a new item in the FAQ to document this issue: > > http://quantlib.org/quantlibaddin/faq.html#faq_item_numparams > > I cannot explain why you are hitting a limit of 15. How are > you going about adding the additional arguments? Are you > editing the XML function metadata for gensrc? Or are you > manually editing the C++ source files that were autogenerated > by gensrc? > > Regards, > Eric > > On Tue, July 15, 2008 13:59, willshaw wrote: >> >> Hi, >> >> It seems that the function exposed to Excel by QuantLibXL has > a >> limit in >> number of arguments, 15. If I have more than 15 arguments in >> function, >> although I can compile xll successfully, when I click the >> function in Excel, >> nothing happens. But if I reduced the arguments to less than > 15 >> without >> doing anything else, it works. >> >> Any idea? >> >> Thanks. >> -- >> View this message in context: >> http://www.nabble.com/QuantLibXL-function-in-Excel%2C-limit-in-number-of-arguments--tp18464649p18464649.html > Sent from the quantlib-dev mailing list archive at > Nabble.com. >> >> >> ------------------------------------------------------------------------- > 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 >> Qua...@li... >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >> > > > ------------------------- > 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 > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > -- View this message in context: http://www.nabble.com/QuantLibXL-function-in-Excel%2C-limit-in-number-of-arguments--tp18464649p18602057.html Sent from the quantlib-dev mailing list archive at Nabble.com. |
|
From: Kyle K. <kk...@st...> - 2008-07-22 17:34:53
|
Hi, I'm trying to understand how the finite-differences American Options pricing in QuantLib works. Specifically, I've been looking into the FDDivdendAmericanEngine class but am having a bit of trouble understanding the algorithm on a high level because of the multiple levels of inheritance. As I understand it, it implements a Crank -Nicolson fully centered finite difference method by iterating backwards in time over a grid of prices, but please correct me if I'm wrong. Note that I've just been running this class as it's used in the quanlib-benchmark program. My main questions involve how the dimensions of the grid are determined: - How are the number of price levels determined? (They seem to be fixed at 100 in the benchmark). - How are the time-steps of the grid determined? Mu understanding is that these methods typically use constant time steps, but the quantlib implementation seems to vary them. I determined this by looking in rollbackImpl() found in finitedifferencemodel.hpp. I don't fully understand why rollback() gets called multiple times with a subset of the steps as opposed to calling it once with all steps. I couldn't find any documentation that describes the algorithms used in QuantLib, but if it exists please point me to it. Any help you can provide me in terms of understanding the high-level or my specific implementation questions would be greatly appreciated. Thanks in advance, Kyle |
|
From: Sylvain B. <syl...@gm...> - 2008-07-22 14:56:56
|
Hi, As I'm working on spline implementations, I've encountered issues with the precision of Real. The calculations I'm doing rely heavily on precision, and it is not an option for me to consider 1e-20 as 0 or 2.0/3 as 0.666667. 2 things here: - I want to raise to your attention the fact that the current spline implementation is also affected by this (though to a lesser extent) - I would like to know if any of you have used workarounds for this, and what you did Thanks Sylvain |