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: Luigi B. <lui...@gm...> - 2015-09-08 08:11:57
|
QuantLib is a cross-platform, free/open-source quantitative finance C++ library for modeling, pricing, trading, and risk management in real-life. Version 1.6.2 has been released and is available for download at http://quantlib.org/download.shtml. QuantLib 1.6.2 is a compatibility release. It solves an ambiguous name resolution in the test-suite code when Visual Studio and the newly released Boost 1.59.0 are used together. The library code did not change. The QuantLib Group -- <http://leanpub.com/implementingquantlib/> <http://implementingquantlib.com> <http://twitter.com/lballabio> |
|
From: Luigi B. <lui...@gm...> - 2015-09-07 21:24:28
|
Hi Peter,
thanks, it's very interesting. (And not as bad as I thought.)
We'll have to think how to act on the info...
Luigi
On Mon, Sep 7, 2015 at 9:38 PM Peter Caspers <pca...@gm...> wrote:
> Hi Luigi, all,
>
> I ran a code coverage analysis highlighting parts of the library's
> code which are not executed by the test-suite (on the current master).
> You can download the result with (e.g.)
>
> wget -O quantlib_code_coverage.zip
>
> https://github.com/pcaspers/doc/blob/master/quantlib_code_coverage.zip?raw=true
>
> or by entering the url directly into a browser. Then unpack the
> archive and open index.html. There are help pages contained explaining
> the meaning of the numbers and colors used to highlight non-covered
> source code lines. While I do not fully understand all of the dark
> yellow marks yet, the yellow and red ones look plausible and useful.
> As well as the list of totally uncovered files of course.
>
> I thought this could be interesting to share. I created the output
> using the code coverage tool of the Intel C++ compiler 16.0 (which is
> free to use in the context of open source projects).
>
> Thank you
> Peter
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
--
<http://leanpub.com/implementingquantlib/>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>
|
|
From: Peter C. <pca...@gm...> - 2015-09-07 19:36:52
|
Hi Luigi, all, I ran a code coverage analysis highlighting parts of the library's code which are not executed by the test-suite (on the current master). You can download the result with (e.g.) wget -O quantlib_code_coverage.zip https://github.com/pcaspers/doc/blob/master/quantlib_code_coverage.zip?raw=true or by entering the url directly into a browser. Then unpack the archive and open index.html. There are help pages contained explaining the meaning of the numbers and colors used to highlight non-covered source code lines. While I do not fully understand all of the dark yellow marks yet, the yellow and red ones look plausible and useful. As well as the list of totally uncovered files of course. I thought this could be interesting to share. I created the output using the code coverage tool of the Intel C++ compiler 16.0 (which is free to use in the context of open source projects). Thank you Peter |
|
From: Eric E. <eri...@re...> - 2015-09-05 13:55:08
|
Oops... > Here are instructions for cloning the repos and building QuantLibXL. > There is also an example of how to export an additional function from > QuantLib to QuantLibXL: > > http://quantlib.org/reposit/ That link should be: http://quantlib.org/reposit/docs/latest/build_git_swig_windows.html Kind Regards, Eric |
|
From: Eric E. <eri...@re...> - 2015-09-04 23:01:11
|
Hi All, I implemented a project called reposit. In a nutshell, addin source code is autogenerated by a new SWIG module which supersedes gensrc. Here is a link to a presentation that I gave on this project at the QuantLib User Meeting last year: http://quantlib.org/slides/qlws14/ehlers.pdf. Advantages of the new design are: 1) The source code for the object wrappers is autogenerated. 2) Maintaining SWIG interface files is much easier than maintaining gensrc XML function metadata. Often, implementing a new function is as simple as copying a line of code from a QuantLib header file into a reposit SWIG interface file. An example of this is provided in the links below. A lot of progress was made in the last month. Under the new build the QuantLibXL addin can now run the Excel VBA Framework (http://quantlib.org/quantlibxl/framework.html) and price a swap. So we are well beyond a proof of concept, and the project is definitely viable. The plan now is to migrate to reposit for the 1.7 release. I have merged the reposit code to the master branch of my quantlib repo on git. So if you are interested in this project then please pull from my repo and have a look. All feedback is welcome. I have organized my repo so that the old and new builds coexist. Here are the directories for the old build: gensrc ObjectHandler QuantLibAddin QuantLibXL I am hoping not to have to maintain the above directories. Here are the directories for the new build: reposit - (this is a copy of ObjectHandler, renamed, and decoupled from gensrc) QuantLibAddin2 QuantLibXL2 I also cloned the SWIG repo and in my copy I implemented a new module called reposit. Here is the web site for the project: http://quantlib.org/reposit/ Here are instructions for cloning the repos and building QuantLibXL. There is also an example of how to export an additional function from QuantLib to QuantLibXL: http://quantlib.org/reposit/ The code is in a state of flux so if you attempt the build please be patient with any glitches. I will try to keep the above build stable. In the new build the functions do not always have the same name as the functions in the old build. The convention is to name the functions qlXxxYyy where Xxx is the class name and Yyy is the member function name. In the new build, the names are generated automatically, so the convention is strictly followed. In the old build, the names were configured by hand and the convention was not always followed, so some function names have changed. Since we are breaking some things we decided to break a few others. In the old build, function signatures looked like this: Free Functions: ..., Trigger Member Functions: ObjectId, ..., Trigger Constructors: ObjectId, ..., Permanent, Trigger, Overwrite Putting those autogenerated parameters at the end means that any time a new parameter is added in the QuantLib interface, the function breaks. So we decided to put those parameters at the beginning. This means that new optional parameters can be added at the end without breaking anything: Free Functions: Trigger, ... Member Functions: Trigger, ObjectId, ... Constructors: Trigger, ObjectId, Overwrite, Permanent, ... I am probably going to write a utility to automatically convert workbooks from the old format to the new. With regard to the recent work that was done on the LibreOffice addin, changes made to gensrc will be lost. However I happen to need the LibreOffice addin for my own purposes and I intend to get it working on the new platform very soon. I am very glad to have a recent build to work from. Kind Regards, Eric |
|
From: Peter C. <pca...@gm...> - 2015-08-29 18:10:14
|
thought as much, thank you Peter On 29 August 2015 at 19:50, Luigi Ballabio <lui...@gm...> wrote: > I think it's date-dependent. I don't think anything relevant changed since > the last time I ran it. > > Luigi > > > On 19:14, Sat, Aug 29, 2015 Peter Caspers <pca...@gm...> wrote: >> >> Hi Luigi, >> >> I get the following erros in the current master. Any idea where it may >> come from ? Is it maybe this kind of system date dependent thing one >> sees from time to time ? >> >> Thanks >> Peter >> >> >> Testing alpha caplet calibration in a lognormal coterminal swap market >> model... >> >> unknown location(0): fatal error in >> >> "QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletAlphaCalibrationTest::testFunction)": >> std::exception: >> ctsmmcapletcalibration.cpp:128: last caplet vol (0.1340376439125532) >> must be equal to last swaption vol (0.1340517152226495); discrepancy >> is 1.407131009625862e-05 >> utilities.hpp(74): last checkpoint >> >> Testing GHLS caplet calibration in a lognormal coterminal swap market >> model... >> >> unknown location(0): fatal error in >> >> "QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletCalibrationTest::testFunction)": >> std::exception: >> ctsmmcapletcalibration.cpp:128: last caplet vol (0.1340376439125532) >> must be equal to last swaption vol (0.1340517152226495); discrepancy >> is 1.407131009625862e-05 >> utilities.hpp(74): last checkpoint >> >> Testing max homogeneity caplet calibration in a lognormal coterminal >> swap market model... >> >> unknown location(0): fatal error in >> >> "QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletHomoCalibrationTest::testFunction)": >> std::exception: >> ctsmmcapletcalibration.cpp:128: last caplet vol (0.1340376439125532) >> must be equal to last swaption vol (0.1340517152226495); discrepancy >> is 1.407131009625862e-05 >> utilities.hpp(74): last checkpoint >> >> Testing max homogeneity periodic caplet calibration in a lognormal >> coterminal swap market model... >> Testing sphere-cylinder optimization... >> >> *** 3 failures detected in test suite "Master Test Suite" >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> QuantLib-dev mailing list >> Qua...@li... >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > -- > > <http://leanpub.com/implementingquantlib/> > <http://implementingquantlib.com> > <http://twitter.com/lballabio> |
|
From: Luigi B. <lui...@gm...> - 2015-08-29 17:51:16
|
I think it's date-dependent. I don't think anything relevant changed since the last time I ran it. Luigi On 19:14, Sat, Aug 29, 2015 Peter Caspers <pca...@gm...> wrote: > Hi Luigi, > > I get the following erros in the current master. Any idea where it may > come from ? Is it maybe this kind of system date dependent thing one > sees from time to time ? > > Thanks > Peter > > > Testing alpha caplet calibration in a lognormal coterminal swap market > model... > > unknown location(0): fatal error in > > "QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletAlphaCalibrationTest::testFunction)": > std::exception: > ctsmmcapletcalibration.cpp:128: last caplet vol (0.1340376439125532) > must be equal to last swaption vol (0.1340517152226495); discrepancy > is 1.407131009625862e-05 > utilities.hpp(74): last checkpoint > > Testing GHLS caplet calibration in a lognormal coterminal swap market > model... > > unknown location(0): fatal error in > > "QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletCalibrationTest::testFunction)": > std::exception: > ctsmmcapletcalibration.cpp:128: last caplet vol (0.1340376439125532) > must be equal to last swaption vol (0.1340517152226495); discrepancy > is 1.407131009625862e-05 > utilities.hpp(74): last checkpoint > > Testing max homogeneity caplet calibration in a lognormal coterminal > swap market model... > > unknown location(0): fatal error in > > "QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletHomoCalibrationTest::testFunction)": > std::exception: > ctsmmcapletcalibration.cpp:128: last caplet vol (0.1340376439125532) > must be equal to last swaption vol (0.1340517152226495); discrepancy > is 1.407131009625862e-05 > utilities.hpp(74): last checkpoint > > Testing max homogeneity periodic caplet calibration in a lognormal > coterminal swap market model... > Testing sphere-cylinder optimization... > > *** 3 failures detected in test suite "Master Test Suite" > > > ------------------------------------------------------------------------------ > _______________________________________________ > QuantLib-dev mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev > -- <http://leanpub.com/implementingquantlib/> <http://implementingquantlib.com> <http://twitter.com/lballabio> |
|
From: Peter C. <pca...@gm...> - 2015-08-29 17:13:16
|
Hi Luigi, I get the following erros in the current master. Any idea where it may come from ? Is it maybe this kind of system date dependent thing one sees from time to time ? Thanks Peter Testing alpha caplet calibration in a lognormal coterminal swap market model... unknown location(0): fatal error in "QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletAlphaCalibrationTest::testFunction)": std::exception: ctsmmcapletcalibration.cpp:128: last caplet vol (0.1340376439125532) must be equal to last swaption vol (0.1340517152226495); discrepancy is 1.407131009625862e-05 utilities.hpp(74): last checkpoint Testing GHLS caplet calibration in a lognormal coterminal swap market model... unknown location(0): fatal error in "QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletCalibrationTest::testFunction)": std::exception: ctsmmcapletcalibration.cpp:128: last caplet vol (0.1340376439125532) must be equal to last swaption vol (0.1340517152226495); discrepancy is 1.407131009625862e-05 utilities.hpp(74): last checkpoint Testing max homogeneity caplet calibration in a lognormal coterminal swap market model... unknown location(0): fatal error in "QuantLib::detail::quantlib_test_case(&MarketModelSmmCapletHomoCalibrationTest::testFunction)": std::exception: ctsmmcapletcalibration.cpp:128: last caplet vol (0.1340376439125532) must be equal to last swaption vol (0.1340517152226495); discrepancy is 1.407131009625862e-05 utilities.hpp(74): last checkpoint Testing max homogeneity periodic caplet calibration in a lognormal coterminal swap market model... Testing sphere-cylinder optimization... *** 3 failures detected in test suite "Master Test Suite" |
|
From: Peter C. <pca...@gm...> - 2015-08-29 14:29:25
|
You can implement your own accumulators (I am not aware of one working like GeneralStatistics), but I am not sure how returning the data would fit into the general concept. Maybe it is better to just leave the two tasks of storing the data / sorting it / return values ... etc. and the statistical computations separated in the respective responsibility of STL containers and accumulators in the end ? Also we have to keep in mind that the boost standard accumulators are returning different flavors of estimations compared to QuantLib (variance, skewness, kurtosis, error estimate). The right way would probably be be to provide own (boost based) accumulators for those, either as an extension provided within QuantLib or as a direct contribution to boost. I just placed appropriate factors in the wrapper for now. Peter On 29 August 2015 at 14:52, Ferdinando M. Ametrano <fer...@am...> wrote: > Statistics, random numbers, and distributions! I might even suggest that > stats and distributions should be boostified at the same time. > > Wouldn't this be a good student assignement? Too bad Google summer of code > is just over... > > On Aug 29, 2015 2:34 PM, "Luigi Ballabio" <lui...@gm...> wrote: >> >> I suppose there's a Boost accumulator that can replace GeneralStatistics, >> too? (That is, one that stores and can return the whole set of samples?) >> >> As for switching: I'm all for it, but the switch itself is going to need >> some thinking if we're to let the two interfaces coexist for a release or >> two. MonteCarloModel<MC, RNG, Statistics> and MonteCarloModel<MC, RNG, >> Boost.Whatever> should both work. I guess we could use traits of enable_if >> underneath... >> >> (The second leg of this would be to give our random-number generators the >> same interface as the ones in Boost and the C++11 standard so that we can >> eventually replace those, too. Performance would be more of a sensitive >> issue in this case, though...) >> >> Luigi >> >> >> On Fri, Aug 28, 2015 at 9:30 PM Peter Caspers <pca...@gm...> >> wrote: >>> >>> Yes sure, I kept the interface as is and just replaced the >>> implementation for now. Since the member variables are protected this >>> is not 100% backward compatible because classes might derive from >>> IncrementalStatistics using these variables. But this is not done in >>> QuantLib itself, so I would say we just ignore this. >>> >>> On 28 August 2015 at 20:42, Ferdinando M. Ametrano >>> <fer...@am...> wrote: >>> > I'm all in favor of replacing the implementation of QL statistics >>> > classes >>> > with boost. Then deprecate QL interfaces and switch to boost >>> > altogether.We >>> > might just have some finance related risk measures to keep. It has >>> > always >>> > been a dream pet project of mine... if i only had time... >>> > >>> > On Thu, Aug 27, 2015 at 10:48 AM, Luigi Ballabio >>> > <lui...@gm...> >>> > wrote: >>> >> >>> >> Ok, thanks. (The reason I asked is that the small memory footprint is >>> >> the >>> >> very reason IncrementalStatistics is there in the first place. >>> >> Otherwise, >>> >> one would just use GeneralStatistics instead.) >>> >> >>> >> >>> >> On Thu, Aug 27, 2015 at 10:45 AM Peter Caspers >>> >> <pca...@gm...> >>> >> wrote: >>> >>> >>> >>> This will in general depend on the specific accumulator, but I would >>> >>> assume so for the ones we need here. The documentation isn't overly >>> >>> explicit about that, the only hint seems to be >>> >>> >>> >>> "This works, but some accumulators are not cheap to copy. For >>> >>> example, >>> >>> the tail andtail_variate<> accumulators must store a std::vector<>, >>> >>> so >>> >>> copying these accumulators involves a dynamic allocation." >>> >>> >>> >>> I will test the memory usage though, to be sure. >>> >>> >>> >>> Peter >>> >>> >>> >>> >>> >>> On 27 August 2015 at 09:58, Luigi Ballabio <lui...@gm...> >>> >>> wrote: >>> >>> > Do they have the same behavior? (That is, keep the statistics but >>> >>> > discard >>> >>> > the data?) If so, yes, it would probably make the code simpler. >>> >>> > >>> >>> > Luigi >>> >>> > >>> >>> > On Thu, Aug 27, 2015 at 9:17 AM Peter Caspers >>> >>> > <pca...@gm...> >>> >>> > wrote: >>> >>> >> >>> >>> >> ... another idea would be to remove the core from >>> >>> >> IncrementalStatistics and replace it with boost accumulators (they >>> >>> >> are >>> >>> >> present since 1.36, so it should be ok), just leaving the >>> >>> >> interface in >>> >>> >> place. Shall I do that ? >>> >>> >> Peter >>> >>> >> >>> >>> >> On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> >>> >>> >> wrote: >>> >>> >> > Hi, >>> >>> >> > >>> >>> >> > here >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 >>> >>> >> > >>> >>> >> > is a check for a negative variance estimation. Indeed I observe >>> >>> >> > this >>> >>> >> > happens due to numerical issues sometimes. However, if this is >>> >>> >> > the >>> >>> >> > only source for the exception to be thrown, couldn't we just >>> >>> >> > omit >>> >>> >> > the >>> >>> >> > check and return the value or if you want max ( v, 0.0 ) ? >>> >>> >> > >>> >>> >> > In applications it is somewhat unexpected to get an exception >>> >>> >> > when >>> >>> >> > just asking for a variance estimation on valid data. >>> >>> >> > >>> >>> >> > Thank you >>> >>> >> > Peter >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> ------------------------------------------------------------------------------ >>> >>> >> _______________________________________________ >>> >>> >> QuantLib-dev mailing list >>> >>> >> Qua...@li... >>> >>> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>> >>> > >>> >>> > -- >>> >>> > >>> >>> > <http://leanpub.com/implementingquantlib/> >>> >>> > <http://implementingquantlib.com> >>> >>> > <http://twitter.com/lballabio> >>> >> >>> >> -- >>> >> >>> >> <http://leanpub.com/implementingquantlib/> >>> >> <http://implementingquantlib.com> >>> >> <http://twitter.com/lballabio> >>> >> >>> >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >>> >> >>> >> _______________________________________________ >>> >> QuantLib-dev mailing list >>> >> Qua...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>> >> >>> > >> >> -- >> >> <http://leanpub.com/implementingquantlib/> >> <http://implementingquantlib.com> >> <http://twitter.com/lballabio> |
|
From: Ferdinando M. A. <fer...@am...> - 2015-08-29 12:52:47
|
Statistics, random numbers, and distributions! I might even suggest that stats and distributions should be boostified at the same time. Wouldn't this be a good student assignement? Too bad Google summer of code is just over... On Aug 29, 2015 2:34 PM, "Luigi Ballabio" <lui...@gm...> wrote: > I suppose there's a Boost accumulator that can replace GeneralStatistics, > too? (That is, one that stores and can return the whole set of samples?) > > As for switching: I'm all for it, but the switch itself is going to need > some thinking if we're to let the two interfaces coexist for a release or > two. MonteCarloModel<MC, RNG, Statistics> and MonteCarloModel<MC, RNG, > Boost.Whatever> should both work. I guess we could use traits of enable_if > underneath... > > (The second leg of this would be to give our random-number generators the > same interface as the ones in Boost and the C++11 standard so that we can > eventually replace those, too. Performance would be more of a sensitive > issue in this case, though...) > > Luigi > > > On Fri, Aug 28, 2015 at 9:30 PM Peter Caspers <pca...@gm...> > wrote: > >> Yes sure, I kept the interface as is and just replaced the >> implementation for now. Since the member variables are protected this >> is not 100% backward compatible because classes might derive from >> IncrementalStatistics using these variables. But this is not done in >> QuantLib itself, so I would say we just ignore this. >> >> On 28 August 2015 at 20:42, Ferdinando M. Ametrano >> <fer...@am...> wrote: >> > I'm all in favor of replacing the implementation of QL statistics >> classes >> > with boost. Then deprecate QL interfaces and switch to boost >> altogether.We >> > might just have some finance related risk measures to keep. It has >> always >> > been a dream pet project of mine... if i only had time... >> > >> > On Thu, Aug 27, 2015 at 10:48 AM, Luigi Ballabio < >> lui...@gm...> >> > wrote: >> >> >> >> Ok, thanks. (The reason I asked is that the small memory footprint is >> the >> >> very reason IncrementalStatistics is there in the first place. >> Otherwise, >> >> one would just use GeneralStatistics instead.) >> >> >> >> >> >> On Thu, Aug 27, 2015 at 10:45 AM Peter Caspers <pca...@gm... >> > >> >> wrote: >> >>> >> >>> This will in general depend on the specific accumulator, but I would >> >>> assume so for the ones we need here. The documentation isn't overly >> >>> explicit about that, the only hint seems to be >> >>> >> >>> "This works, but some accumulators are not cheap to copy. For example, >> >>> the tail andtail_variate<> accumulators must store a std::vector<>, so >> >>> copying these accumulators involves a dynamic allocation." >> >>> >> >>> I will test the memory usage though, to be sure. >> >>> >> >>> Peter >> >>> >> >>> >> >>> On 27 August 2015 at 09:58, Luigi Ballabio <lui...@gm...> >> >>> wrote: >> >>> > Do they have the same behavior? (That is, keep the statistics but >> >>> > discard >> >>> > the data?) If so, yes, it would probably make the code simpler. >> >>> > >> >>> > Luigi >> >>> > >> >>> > On Thu, Aug 27, 2015 at 9:17 AM Peter Caspers < >> pca...@gm...> >> >>> > wrote: >> >>> >> >> >>> >> ... another idea would be to remove the core from >> >>> >> IncrementalStatistics and replace it with boost accumulators (they >> are >> >>> >> present since 1.36, so it should be ok), just leaving the >> interface in >> >>> >> place. Shall I do that ? >> >>> >> Peter >> >>> >> >> >>> >> On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> >> >>> >> wrote: >> >>> >> > Hi, >> >>> >> > >> >>> >> > here >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 >> >>> >> > >> >>> >> > is a check for a negative variance estimation. Indeed I observe >> this >> >>> >> > happens due to numerical issues sometimes. However, if this is >> the >> >>> >> > only source for the exception to be thrown, couldn't we just omit >> >>> >> > the >> >>> >> > check and return the value or if you want max ( v, 0.0 ) ? >> >>> >> > >> >>> >> > In applications it is somewhat unexpected to get an exception >> when >> >>> >> > just asking for a variance estimation on valid data. >> >>> >> > >> >>> >> > Thank you >> >>> >> > Peter >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> ------------------------------------------------------------------------------ >> >>> >> _______________________________________________ >> >>> >> QuantLib-dev mailing list >> >>> >> Qua...@li... >> >>> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >> >>> > >> >>> > -- >> >>> > >> >>> > <http://leanpub.com/implementingquantlib/> >> >>> > <http://implementingquantlib.com> >> >>> > <http://twitter.com/lballabio> >> >> >> >> -- >> >> >> >> <http://leanpub.com/implementingquantlib/> >> >> <http://implementingquantlib.com> >> >> <http://twitter.com/lballabio> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> QuantLib-dev mailing list >> >> Qua...@li... >> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >> >> >> > >> > -- > > <http://leanpub.com/implementingquantlib/> > <http://implementingquantlib.com> > <http://twitter.com/lballabio> > |
|
From: Luigi B. <lui...@gm...> - 2015-08-29 12:34:55
|
I suppose there's a Boost accumulator that can replace GeneralStatistics, too? (That is, one that stores and can return the whole set of samples?) As for switching: I'm all for it, but the switch itself is going to need some thinking if we're to let the two interfaces coexist for a release or two. MonteCarloModel<MC, RNG, Statistics> and MonteCarloModel<MC, RNG, Boost.Whatever> should both work. I guess we could use traits of enable_if underneath... (The second leg of this would be to give our random-number generators the same interface as the ones in Boost and the C++11 standard so that we can eventually replace those, too. Performance would be more of a sensitive issue in this case, though...) Luigi On Fri, Aug 28, 2015 at 9:30 PM Peter Caspers <pca...@gm...> wrote: > Yes sure, I kept the interface as is and just replaced the > implementation for now. Since the member variables are protected this > is not 100% backward compatible because classes might derive from > IncrementalStatistics using these variables. But this is not done in > QuantLib itself, so I would say we just ignore this. > > On 28 August 2015 at 20:42, Ferdinando M. Ametrano > <fer...@am...> wrote: > > I'm all in favor of replacing the implementation of QL statistics classes > > with boost. Then deprecate QL interfaces and switch to boost > altogether.We > > might just have some finance related risk measures to keep. It has always > > been a dream pet project of mine... if i only had time... > > > > On Thu, Aug 27, 2015 at 10:48 AM, Luigi Ballabio < > lui...@gm...> > > wrote: > >> > >> Ok, thanks. (The reason I asked is that the small memory footprint is > the > >> very reason IncrementalStatistics is there in the first place. > Otherwise, > >> one would just use GeneralStatistics instead.) > >> > >> > >> On Thu, Aug 27, 2015 at 10:45 AM Peter Caspers <pca...@gm...> > >> wrote: > >>> > >>> This will in general depend on the specific accumulator, but I would > >>> assume so for the ones we need here. The documentation isn't overly > >>> explicit about that, the only hint seems to be > >>> > >>> "This works, but some accumulators are not cheap to copy. For example, > >>> the tail andtail_variate<> accumulators must store a std::vector<>, so > >>> copying these accumulators involves a dynamic allocation." > >>> > >>> I will test the memory usage though, to be sure. > >>> > >>> Peter > >>> > >>> > >>> On 27 August 2015 at 09:58, Luigi Ballabio <lui...@gm...> > >>> wrote: > >>> > Do they have the same behavior? (That is, keep the statistics but > >>> > discard > >>> > the data?) If so, yes, it would probably make the code simpler. > >>> > > >>> > Luigi > >>> > > >>> > On Thu, Aug 27, 2015 at 9:17 AM Peter Caspers < > pca...@gm...> > >>> > wrote: > >>> >> > >>> >> ... another idea would be to remove the core from > >>> >> IncrementalStatistics and replace it with boost accumulators (they > are > >>> >> present since 1.36, so it should be ok), just leaving the interface > in > >>> >> place. Shall I do that ? > >>> >> Peter > >>> >> > >>> >> On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> > >>> >> wrote: > >>> >> > Hi, > >>> >> > > >>> >> > here > >>> >> > > >>> >> > > >>> >> > > >>> >> > > https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 > >>> >> > > >>> >> > is a check for a negative variance estimation. Indeed I observe > this > >>> >> > happens due to numerical issues sometimes. However, if this is the > >>> >> > only source for the exception to be thrown, couldn't we just omit > >>> >> > the > >>> >> > check and return the value or if you want max ( v, 0.0 ) ? > >>> >> > > >>> >> > In applications it is somewhat unexpected to get an exception when > >>> >> > just asking for a variance estimation on valid data. > >>> >> > > >>> >> > Thank you > >>> >> > Peter > >>> >> > >>> >> > >>> >> > >>> >> > ------------------------------------------------------------------------------ > >>> >> _______________________________________________ > >>> >> QuantLib-dev mailing list > >>> >> Qua...@li... > >>> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev > >>> > > >>> > -- > >>> > > >>> > <http://leanpub.com/implementingquantlib/> > >>> > <http://implementingquantlib.com> > >>> > <http://twitter.com/lballabio> > >> > >> -- > >> > >> <http://leanpub.com/implementingquantlib/> > >> <http://implementingquantlib.com> > >> <http://twitter.com/lballabio> > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> QuantLib-dev mailing list > >> Qua...@li... > >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev > >> > > > -- <http://leanpub.com/implementingquantlib/> <http://implementingquantlib.com> <http://twitter.com/lballabio> |
|
From: Peter C. <pca...@gm...> - 2015-08-28 19:30:28
|
Yes sure, I kept the interface as is and just replaced the implementation for now. Since the member variables are protected this is not 100% backward compatible because classes might derive from IncrementalStatistics using these variables. But this is not done in QuantLib itself, so I would say we just ignore this. On 28 August 2015 at 20:42, Ferdinando M. Ametrano <fer...@am...> wrote: > I'm all in favor of replacing the implementation of QL statistics classes > with boost. Then deprecate QL interfaces and switch to boost altogether.We > might just have some finance related risk measures to keep. It has always > been a dream pet project of mine... if i only had time... > > On Thu, Aug 27, 2015 at 10:48 AM, Luigi Ballabio <lui...@gm...> > wrote: >> >> Ok, thanks. (The reason I asked is that the small memory footprint is the >> very reason IncrementalStatistics is there in the first place. Otherwise, >> one would just use GeneralStatistics instead.) >> >> >> On Thu, Aug 27, 2015 at 10:45 AM Peter Caspers <pca...@gm...> >> wrote: >>> >>> This will in general depend on the specific accumulator, but I would >>> assume so for the ones we need here. The documentation isn't overly >>> explicit about that, the only hint seems to be >>> >>> "This works, but some accumulators are not cheap to copy. For example, >>> the tail andtail_variate<> accumulators must store a std::vector<>, so >>> copying these accumulators involves a dynamic allocation." >>> >>> I will test the memory usage though, to be sure. >>> >>> Peter >>> >>> >>> On 27 August 2015 at 09:58, Luigi Ballabio <lui...@gm...> >>> wrote: >>> > Do they have the same behavior? (That is, keep the statistics but >>> > discard >>> > the data?) If so, yes, it would probably make the code simpler. >>> > >>> > Luigi >>> > >>> > On Thu, Aug 27, 2015 at 9:17 AM Peter Caspers <pca...@gm...> >>> > wrote: >>> >> >>> >> ... another idea would be to remove the core from >>> >> IncrementalStatistics and replace it with boost accumulators (they are >>> >> present since 1.36, so it should be ok), just leaving the interface in >>> >> place. Shall I do that ? >>> >> Peter >>> >> >>> >> On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> >>> >> wrote: >>> >> > Hi, >>> >> > >>> >> > here >>> >> > >>> >> > >>> >> > >>> >> > https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 >>> >> > >>> >> > is a check for a negative variance estimation. Indeed I observe this >>> >> > happens due to numerical issues sometimes. However, if this is the >>> >> > only source for the exception to be thrown, couldn't we just omit >>> >> > the >>> >> > check and return the value or if you want max ( v, 0.0 ) ? >>> >> > >>> >> > In applications it is somewhat unexpected to get an exception when >>> >> > just asking for a variance estimation on valid data. >>> >> > >>> >> > Thank you >>> >> > Peter >>> >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >>> >> _______________________________________________ >>> >> QuantLib-dev mailing list >>> >> Qua...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>> > >>> > -- >>> > >>> > <http://leanpub.com/implementingquantlib/> >>> > <http://implementingquantlib.com> >>> > <http://twitter.com/lballabio> >> >> -- >> >> <http://leanpub.com/implementingquantlib/> >> <http://implementingquantlib.com> >> <http://twitter.com/lballabio> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> QuantLib-dev mailing list >> Qua...@li... >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >> > |
|
From: Peter C. <pca...@gm...> - 2015-08-28 19:25:07
|
Alight, I plugged the boost accumulators into the ql - class: Memory footprint: I added the first 10,000 integers to the original class (and extracted mean, variance, skewness, kurtosis to be sure later on boost is actually doing something) and recorded the heap usage with Massif. The peak memory usage is at 6 KB. In comparison for GeneralStatistics I get 390 KB. With the boostified version it is again 6 KB. This looks ok / the same for both implementations. Performance: Doing the same with the first 1,000,000 integers the original class runs 25ms, while the new one takes 35ms, so a bit slower. I guess this is acceptable though. Numerical stability: Seems to be better in boost, in particular for the variance estimation. Generating 500,000 random numbers drawn from a normal distribution with mean 1E8 and variance 1E-4 I get estimations for the variance of 9.9918E-5 in boost and 0 in ql. With mean 1E7 and variance 1E-6 it is 9.9918E-7 in boost and 0.6719 in ql. Or with mean 1E8 and variance 1E-2 boost says 0.00999 and ql 348.0. For me it looks as if boost wins on balance, mostly because of the better numerical stability. I will send a PR after adding a few test cases which test the new implementation against the old one and some cases which recognize the better stability. Peter On 27 August 2015 at 10:48, Luigi Ballabio <lui...@gm...> wrote: > Ok, thanks. (The reason I asked is that the small memory footprint is the > very reason IncrementalStatistics is there in the first place. Otherwise, > one would just use GeneralStatistics instead.) > > > On Thu, Aug 27, 2015 at 10:45 AM Peter Caspers <pca...@gm...> > wrote: >> >> This will in general depend on the specific accumulator, but I would >> assume so for the ones we need here. The documentation isn't overly >> explicit about that, the only hint seems to be >> >> "This works, but some accumulators are not cheap to copy. For example, >> the tail andtail_variate<> accumulators must store a std::vector<>, so >> copying these accumulators involves a dynamic allocation." >> >> I will test the memory usage though, to be sure. >> >> Peter >> >> >> On 27 August 2015 at 09:58, Luigi Ballabio <lui...@gm...> >> wrote: >> > Do they have the same behavior? (That is, keep the statistics but >> > discard >> > the data?) If so, yes, it would probably make the code simpler. >> > >> > Luigi >> > >> > On Thu, Aug 27, 2015 at 9:17 AM Peter Caspers <pca...@gm...> >> > wrote: >> >> >> >> ... another idea would be to remove the core from >> >> IncrementalStatistics and replace it with boost accumulators (they are >> >> present since 1.36, so it should be ok), just leaving the interface in >> >> place. Shall I do that ? >> >> Peter >> >> >> >> On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> >> >> wrote: >> >> > Hi, >> >> > >> >> > here >> >> > >> >> > >> >> > >> >> > https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 >> >> > >> >> > is a check for a negative variance estimation. Indeed I observe this >> >> > happens due to numerical issues sometimes. However, if this is the >> >> > only source for the exception to be thrown, couldn't we just omit the >> >> > check and return the value or if you want max ( v, 0.0 ) ? >> >> > >> >> > In applications it is somewhat unexpected to get an exception when >> >> > just asking for a variance estimation on valid data. >> >> > >> >> > Thank you >> >> > Peter >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> >> QuantLib-dev mailing list >> >> Qua...@li... >> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >> > >> > -- >> > >> > <http://leanpub.com/implementingquantlib/> >> > <http://implementingquantlib.com> >> > <http://twitter.com/lballabio> > > -- > > <http://leanpub.com/implementingquantlib/> > <http://implementingquantlib.com> > <http://twitter.com/lballabio> |
|
From: Ferdinando M. A. <fer...@am...> - 2015-08-28 19:06:21
|
I'm all in favor of replacing the implementation of QL statistics classes with boost. Then deprecate QL interfaces and switch to boost altogether.We might just have some finance related risk measures to keep. It has always been a dream pet project of mine... if i only had time... On Thu, Aug 27, 2015 at 10:48 AM, Luigi Ballabio <lui...@gm...> wrote: > Ok, thanks. (The reason I asked is that the small memory footprint is the > very reason IncrementalStatistics is there in the first place. Otherwise, > one would just use GeneralStatistics instead.) > > > On Thu, Aug 27, 2015 at 10:45 AM Peter Caspers <pca...@gm...> > wrote: > >> This will in general depend on the specific accumulator, but I would >> assume so for the ones we need here. The documentation isn't overly >> explicit about that, the only hint seems to be >> >> "This works, but some accumulators are not cheap to copy. For example, >> the tail andtail_variate<> accumulators must store a std::vector<>, so >> copying these accumulators involves a dynamic allocation." >> >> I will test the memory usage though, to be sure. >> >> Peter >> >> >> On 27 August 2015 at 09:58, Luigi Ballabio <lui...@gm...> >> wrote: >> > Do they have the same behavior? (That is, keep the statistics but >> discard >> > the data?) If so, yes, it would probably make the code simpler. >> > >> > Luigi >> > >> > On Thu, Aug 27, 2015 at 9:17 AM Peter Caspers <pca...@gm...> >> > wrote: >> >> >> >> ... another idea would be to remove the core from >> >> IncrementalStatistics and replace it with boost accumulators (they are >> >> present since 1.36, so it should be ok), just leaving the interface in >> >> place. Shall I do that ? >> >> Peter >> >> >> >> On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> >> wrote: >> >> > Hi, >> >> > >> >> > here >> >> > >> >> > >> >> > >> https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 >> >> > >> >> > is a check for a negative variance estimation. Indeed I observe this >> >> > happens due to numerical issues sometimes. However, if this is the >> >> > only source for the exception to be thrown, couldn't we just omit the >> >> > check and return the value or if you want max ( v, 0.0 ) ? >> >> > >> >> > In applications it is somewhat unexpected to get an exception when >> >> > just asking for a variance estimation on valid data. >> >> > >> >> > Thank you >> >> > Peter >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> >> QuantLib-dev mailing list >> >> Qua...@li... >> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >> > >> > -- >> > >> > <http://leanpub.com/implementingquantlib/> >> > <http://implementingquantlib.com> >> > <http://twitter.com/lballabio> >> > -- > > <http://leanpub.com/implementingquantlib/> > <http://implementingquantlib.com> > <http://twitter.com/lballabio> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > QuantLib-dev mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > |
|
From: Luigi B. <lui...@gm...> - 2015-08-27 15:18:17
|
Hi Ben,
yes, bugs would be a good place to start. Even before fixing them, it
would be great if you could triage them first, since, as you said, most are
quite old (for instance, those reporting build errors from years ago can
probably be closed, and others might have been fixed).
Just post here when you run into difficulties. Having someone looking at
the list and pushing forward will be a great help already, even if you
won't actually contribute code at the start.
Later,
Luigi
On Mon, Aug 24, 2015 at 6:27 PM Ben Champion <be...@be...> wrote:
> Hi all,
>
> I'm looking to return to quant finance after taking a stint (almost 2
> years) in academia. I did a FX desk quant internship at JPM in 2013.
>
> It seems to me that contributing to QuantLib might be a good way to
> re-familiarize myself with quant finance and "clean off the rust".
>
> I have read the developer introduction
> <http://quantlib.org/newdeveloper.shtml>. In addition to the suggestions
> in that document (and obligatory "RTFM" via the docs
> <http://quantlib.org/docs.shtml> page), maybe I could start by trying to
> fix some bugs <http://sourceforge.net/p/quantlib/bugs/>? It's not totally
> clear to me where I might start with the bugs, since they are all priority
> 5 (and some of the entries there are getting a bit old)! Apart from the
> bugs on Sourceforge, It looks like there are also some bugs listed on
> GitHub <https://github.com/lballabio/quantlib/issues> and in the reference
> manual <http://quantlib.org/reference/bug.html>.
>
> I would also be grateful for further suggestions about where to start.
> I've had a quick look through the archives, but undoubtedly have missed
> things.
>
> I look forward to the opportunity of working with you all!
>
> Thanks,
> Ben
>
> ------------------------------------------------------------------------------
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
--
<http://leanpub.com/implementingquantlib/>
<http://implementingquantlib.com>
<http://twitter.com/lballabio>
|
|
From: Luigi B. <lui...@gm...> - 2015-08-27 08:48:28
|
Ok, thanks. (The reason I asked is that the small memory footprint is the very reason IncrementalStatistics is there in the first place. Otherwise, one would just use GeneralStatistics instead.) On Thu, Aug 27, 2015 at 10:45 AM Peter Caspers <pca...@gm...> wrote: > This will in general depend on the specific accumulator, but I would > assume so for the ones we need here. The documentation isn't overly > explicit about that, the only hint seems to be > > "This works, but some accumulators are not cheap to copy. For example, > the tail andtail_variate<> accumulators must store a std::vector<>, so > copying these accumulators involves a dynamic allocation." > > I will test the memory usage though, to be sure. > > Peter > > > On 27 August 2015 at 09:58, Luigi Ballabio <lui...@gm...> > wrote: > > Do they have the same behavior? (That is, keep the statistics but discard > > the data?) If so, yes, it would probably make the code simpler. > > > > Luigi > > > > On Thu, Aug 27, 2015 at 9:17 AM Peter Caspers <pca...@gm...> > > wrote: > >> > >> ... another idea would be to remove the core from > >> IncrementalStatistics and replace it with boost accumulators (they are > >> present since 1.36, so it should be ok), just leaving the interface in > >> place. Shall I do that ? > >> Peter > >> > >> On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> > wrote: > >> > Hi, > >> > > >> > here > >> > > >> > > >> > > https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 > >> > > >> > is a check for a negative variance estimation. Indeed I observe this > >> > happens due to numerical issues sometimes. However, if this is the > >> > only source for the exception to be thrown, couldn't we just omit the > >> > check and return the value or if you want max ( v, 0.0 ) ? > >> > > >> > In applications it is somewhat unexpected to get an exception when > >> > just asking for a variance estimation on valid data. > >> > > >> > Thank you > >> > Peter > >> > >> > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> QuantLib-dev mailing list > >> Qua...@li... > >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > > > -- > > > > <http://leanpub.com/implementingquantlib/> > > <http://implementingquantlib.com> > > <http://twitter.com/lballabio> > -- <http://leanpub.com/implementingquantlib/> <http://implementingquantlib.com> <http://twitter.com/lballabio> |
|
From: Peter C. <pca...@gm...> - 2015-08-27 08:45:52
|
This will in general depend on the specific accumulator, but I would assume so for the ones we need here. The documentation isn't overly explicit about that, the only hint seems to be "This works, but some accumulators are not cheap to copy. For example, the tail andtail_variate<> accumulators must store a std::vector<>, so copying these accumulators involves a dynamic allocation." I will test the memory usage though, to be sure. Peter On 27 August 2015 at 09:58, Luigi Ballabio <lui...@gm...> wrote: > Do they have the same behavior? (That is, keep the statistics but discard > the data?) If so, yes, it would probably make the code simpler. > > Luigi > > On Thu, Aug 27, 2015 at 9:17 AM Peter Caspers <pca...@gm...> > wrote: >> >> ... another idea would be to remove the core from >> IncrementalStatistics and replace it with boost accumulators (they are >> present since 1.36, so it should be ok), just leaving the interface in >> place. Shall I do that ? >> Peter >> >> On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> wrote: >> > Hi, >> > >> > here >> > >> > >> > https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 >> > >> > is a check for a negative variance estimation. Indeed I observe this >> > happens due to numerical issues sometimes. However, if this is the >> > only source for the exception to be thrown, couldn't we just omit the >> > check and return the value or if you want max ( v, 0.0 ) ? >> > >> > In applications it is somewhat unexpected to get an exception when >> > just asking for a variance estimation on valid data. >> > >> > Thank you >> > Peter >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> QuantLib-dev mailing list >> Qua...@li... >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > -- > > <http://leanpub.com/implementingquantlib/> > <http://implementingquantlib.com> > <http://twitter.com/lballabio> |
|
From: Luigi B. <lui...@gm...> - 2015-08-27 07:59:03
|
Do they have the same behavior? (That is, keep the statistics but discard the data?) If so, yes, it would probably make the code simpler. Luigi On Thu, Aug 27, 2015 at 9:17 AM Peter Caspers <pca...@gm...> wrote: > ... another idea would be to remove the core from > IncrementalStatistics and replace it with boost accumulators (they are > present since 1.36, so it should be ok), just leaving the interface in > place. Shall I do that ? > Peter > > On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> wrote: > > Hi, > > > > here > > > > > https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 > > > > is a check for a negative variance estimation. Indeed I observe this > > happens due to numerical issues sometimes. However, if this is the > > only source for the exception to be thrown, couldn't we just omit the > > check and return the value or if you want max ( v, 0.0 ) ? > > > > In applications it is somewhat unexpected to get an exception when > > just asking for a variance estimation on valid data. > > > > Thank you > > Peter > > > ------------------------------------------------------------------------------ > _______________________________________________ > QuantLib-dev mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev > -- <http://leanpub.com/implementingquantlib/> <http://implementingquantlib.com> <http://twitter.com/lballabio> |
|
From: Peter C. <pca...@gm...> - 2015-08-27 07:16:19
|
... another idea would be to remove the core from IncrementalStatistics and replace it with boost accumulators (they are present since 1.36, so it should be ok), just leaving the interface in place. Shall I do that ? Peter On 20 August 2015 at 17:56, Peter Caspers <pca...@gm...> wrote: > Hi, > > here > > https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 > > is a check for a negative variance estimation. Indeed I observe this > happens due to numerical issues sometimes. However, if this is the > only source for the exception to be thrown, couldn't we just omit the > check and return the value or if you want max ( v, 0.0 ) ? > > In applications it is somewhat unexpected to get an exception when > just asking for a variance estimation on valid data. > > Thank you > Peter |
|
From: Ben C. <be...@be...> - 2015-08-24 16:25:59
|
Hi all, I'm looking to return to quant finance after taking a stint (almost 2 years) in academia. I did a FX desk quant internship at JPM in 2013. It seems to me that contributing to QuantLib might be a good way to re-familiarize myself with quant finance and "clean off the rust". I have read the developer introduction <http://quantlib.org/newdeveloper.shtml>. In addition to the suggestions in that document (and obligatory "RTFM" via the docs <http://quantlib.org/docs.shtml> page), maybe I could start by trying to fix some bugs <http://sourceforge.net/p/quantlib/bugs/>? It's not totally clear to me where I might start with the bugs, since they are all priority 5 (and some of the entries there are getting a bit old)! Apart from the bugs on Sourceforge, It looks like there are also some bugs listed on GitHub <https://github.com/lballabio/quantlib/issues> and in the reference manual <http://quantlib.org/reference/bug.html>. I would also be grateful for further suggestions about where to start. I've had a quick look through the archives, but undoubtedly have missed things. I look forward to the opportunity of working with you all! Thanks, Ben |
|
From: Eric E. <eri...@re...> - 2015-08-23 19:47:36
|
Hi All,
ObjectHandler / QuantLibAddin / QuantLibXL version 1.6 has been
released. Here is the link to the downloads page:
https://sourceforge.net/projects/quantlib/files/
Here are the links to the web sites:
http://www.objecthandler.org
http://www.quantlibaddin.org
http://www.quantlibxl.org
As before the binary release of QuantLibXL includes XLLs for 32- and
64-bit Excel. The source code for QuantLibXL 1.6.0 is compatible with
either QuantLib 1.6.0 or 1.6.1.
This release includes the updated VBA Framework application (thanks to
Paolo Mazzocchi). This application only works under 32-bit Excel. The
initialization of the application has been simplified and this change
is explained in the documentation
(http://quantlib.org/quantlibxl/framework.html).
Support for the LibreOffice addin has been re-enabled (thanks to Lars
Callenbach).
Kind Regards,
Eric
|
|
From: Peter C. <pca...@gm...> - 2015-08-20 15:56:36
|
Hi, here https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/math/statistics/incrementalstatistics.cpp#L56 is a check for a negative variance estimation. Indeed I observe this happens due to numerical issues sometimes. However, if this is the only source for the exception to be thrown, couldn't we just omit the check and return the value or if you want max ( v, 0.0 ) ? In applications it is somewhat unexpected to get an exception when just asking for a variance estimation on valid data. Thank you Peter |
|
From: Eric E. <eri...@re...> - 2015-08-20 10:33:48
|
Hello, > I am adding this into github.com/japari/quantlib/tree/Calc_linuxmake > This is a branch that I created from the PR you sent to Eric but when > I uploaded to GitHub it only lets me PR to Erics fork. Can you take > the changes into your branch please? I prefer that rather than > issuing a PR to Eric. One way or another, whatever enhancements are made to the Calc addin, I would love to get them into my repo eventually. Kind Regards, Eric |
|
From: <ja...@fr...> - 2015-08-20 08:33:19
|
Hello Lars, Most of the differences in making worksheets run I have noticed so far are not too important: some of these might have nothing to do with the code but the way Calc works, some might be my build. I have just started to play with it so it might just be some stupid input I am entering. -> Objects do not get automatic ids so the ones with an empty id are in error. They have to have overwrite set to true as a result; this is related to not having counters I guess. -> Default values not assigned? Or at least empty fields need to be there separated by commas. -> If you open the wsheet and hit F2 on a formula it might give you a "#MACRO?" message. If you go into the Function Wizard or modify an input the same formula would work. Subsequent calls within the cell work ok. F9 does not do the trick either; I am going one by one now. -> When trying to get a TS object I get an error (tried for default and yield TS) ERROR: qlYieldTSDiscount: empty Handle cannot be dereferenced. This one of course stops everything else. -> When creating an schedule I get an 'unrecognized type' error: see cell CreditMarket::D38 if I use a function call within the call (for the date in this case) I am testing on this worksheet: QuantLibXL/StandaloneExamples/Credit/RiskyBonds.xls So far only the first too sheets. which I am uploading to https://github.com/japari/quantlib/tree/Calc_linuxmake My LibreOffice: Version: 4.2.8.2 Build ID: 420m0(Build:2 . boost 157 gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) On the error messages; fine yes I see the errors. Its just the unrecognised function left. But thats not a big deal. Best Pepe ----- Original Message ----- > > > > > Hi Pepe, > > I have not implemented a counter for objects id's. But I have > activated "ohObjectSave", "ohObjectLoad" and some logging functions > from the ObjectHandler (serialization.xml and logging.xml) - it > works under Linux. > > Since the handling of the basic types is defined a lot of functions > in xml files can be activated/checked. I have not looked for all > addin functions (that can be activated for Calc) since I want to > test the activated functions at first. I would like to have some > sample spreadsheets showing their application. Maybe we can share > the work of testing and extending the xml files for Calc? > > > One remark concerning OhRangeRetrieveError: I think it is not > necessary in the current implementation since the return type of > addin functions is SEQ(SEQ(ANY)) [matrix of any (string, float) > value]- in the case of exceptions the error message will be returned > instead of the objectID/calculated results. You should see this in > the code and in Calc. > > Kind regards, > Lars > > > Gesendet: Mittwoch, 19. August 2015 um 10:07 Uhr > Von: ja...@fr... > An: "Lars Callenbach" <lar...@gm...> > Cc: qua...@li... > Betreff: Re: [Quantlib-dev] Calc Addin under Linux for > QuantLibAddin-1.5.0 > I have started to debug/test worksheets and things sort of work. > Something that I dont understand; is OH working? Why I can not see > the instantiation numbering (or whatever you call it) after the > object name? Do you see this on MacOS? > > Best > Pepe > > > ----- Original Message ----- > > Hello again Lars, > > Sorry for the blackout; I was struggling with it and had not much > > to > > contribute with. But your last branch did help me a lot and save me > > quite a bit of time an effort. A big thank you. > > > > I am building it ok on Linux and running the worksheets. I am > > providing a pedestrian Makefile for it. I can not do it with > > Makefile.oo as it is now. The Makefile is very basic but the idea > > is > > that eventually both Makefiles merge into a proper am file. It just > > provides a dynamic linked lib and installs it. Prerequisites on the > > environment are the same ones you mention. > > > > There are a couple of differences. I dont install the way you do > > (my > > system needs sudo for that); I use a component file and my manifest > > file is fixed (this is the only collision I see with your make). > > Its > > similar to the standard add-in example in the uno sdk. Also the way > > I generate from the idl has a few unnecessary dependences, its also > > taken from the example. > > > > I am adding this into > > github.com/japari/quantlib/tree/Calc_linuxmake > > This is a branch that I created from the PR you sent to Eric but > > when I uploaded to GitHub it only lets me PR to Erics fork. Can you > > take the changes into your branch please? I prefer that rather than > > issuing a PR to Eric. > > > > Is there anyone working on this on Windows? > > > > Best > > Pepe > > > > My TODO list (comments on Makefile.linux results) > > -Useful functions like OHrangeRetrieveError are missing. > > -At least some functions, if not all, fail when called without all > > arguments given; i.e. there are no default values taken in. > > -Error codes as numbers are ugly. > > -Consider renaming the Add-In service to "QuantLib" ? This might be > > more tidy when looking for a function in the Calc drop down menu. > > -Debug the Makefile dependencies; when launching the Makefile with > > '-j' things go wrong: ...'at times'... theres no ./com/* > > generation, > > or too late and as a result the f's are not shown. No complains > > about missing includes though.... > > -Trim the idl compilation; lots of stuff there not used. > > > > > > > > > > > > ----- Original Message ----- > > > Hi all, > > > > > > Pepe, changed index.xml to remove inflation dependencies. > > > Eric, pushed anotther version without generated files in Calc > > > directory > > > - do I have to start another pull request or is the old one still > > > active > > > and includes the last changes? > > > > > > Best regards, > > > Lars > > > > > > Am Donnerstag, den 16.07.2015, 06:19 +0200 schrieb > > > ja...@fr...: > > > > Hi all, > > > > Lars, I have tried your branch and I the AddIn compilation > > > > fails > > > > at > > > > the inflation bonds registration so it looks like I need the > > > > xml > > > > files you mentioned. Can I have a look at them please? Can you > > > > add > > > > those to github? > > > > Thank you. > > > > Pepe > > > > > > > > > > > > ----- Original Message ----- > > > > > Hi Eric, > > > > > > > > > > set up a pull request against 1.6. > > > > > > > > > > @Pepe: is something missing or does everything work fine for > > > > > you > > > > > (I > > > > > have > > > > > written some more xml files for inflation, model calibration > > > > > etc. > > > > > which > > > > > are not included in this pull request)? > > > > > > > > > > > > > > > Best regards, > > > > > Lars > > > > > > > > > > > > > > > Am Sonntag, den 12.07.2015, 12:57 +0300 schrieb Eric Ehlers: > > > > > > Hi Lars, > > > > > > > > > > > > This is great! > > > > > > > > > > > > Would it be possible for you to send me a pull request for > > > > > > this? > > > > > > If > > > > > > you could do it against my v1.6.x branch then I will > > > > > > include > > > > > > it > > > > > > in > > > > > > the > > > > > > 1.6 release which I am preparing now. Otherwise if you do > > > > > > it > > > > > > against > > > > > > my master then it will go in to 1.7. > > > > > > > > > > > > Kind Regards, > > > > > > Eric > > > > > > > > > > > > On Fri, 10 Jul 2015 19:05:55 +0200 > > > > > > Lars Callenbach <lar...@gm...> wrote: > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > I have extended the addin code for the LibreOffice calc > > > > > > > plugin. > > > > > > > Changes: 1) vetor return values (iteration over > > > > > > > std::vector > > > > > > > results) > > > > > > > 2) return type seqseq(ANY) for all addin functions to > > > > > > > provide > > > > > > > addin > > > > > > > access to exceptions (exception messages will be > > > > > > > displayed > > > > > > > in > > > > > > > cells) > > > > > > > 3) implementation of default value handling > > > > > > > (ANY::hasValue() > > > > > > > function) > > > > > > > 4) works clean with dynamic libraries (and with static > > > > > > > linking) > > > > > > > > > > > > > > I have changed a lot of XML config files and some python > > > > > > > files > > > > > > > for the > > > > > > > calc addin and I suggest to include my changes in the > > > > > > > official > > > > > > > code. > > > > > > > How shall we proceed to include these changes in the > > > > > > > official > > > > > > > version? Who is responsible for the maintenance of the > > > > > > > calc > > > > > > > code? > > > > > > > Can > > > > > > > I help maintaining the calc code? > > > > > > > > > > > > > > The generated code is available under > > > > > > > " https://www.callenbach.eu ". > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > Lars > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > QuantLib-dev mailing list > > Qua...@li... > > https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > |
|
From: Lars C. <lar...@gm...> - 2015-08-19 21:29:35
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div> <div>Hi Pepe,</div> <div> </div> <div>I have not implemented a counter for objects id's. But I have activated "ohObjectSave", "ohObjectLoad" and some logging functions from the ObjectHandler (serialization.xml and logging.xml) - it works under Linux.</div> <div> </div> <div>Since the handling of the basic types is defined a lot of functions in xml files can be activated/checked. I have not looked for all addin functions (that can be activated for Calc) since I want to test the activated functions at first. I would like to have some sample spreadsheets showing their application. Maybe we can share the work of testing and extending the xml files for Calc?</div> <div> </div> <div> </div> <div>One remark concerning OhRangeRetrieveError: I think it is not necessary in the current implementation since the return type of addin functions is SEQ(SEQ(ANY)) [matrix of any (string, float) value]- in the case of exceptions the error message will be returned instead of the objectID/calculated results. You should see this in the code and in Calc.</div> <div> </div> <div>Kind regards,</div> <div> Lars</div> <div> </div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Mittwoch, 19. August 2015 um 10:07 Uhr<br/> <b>Von:</b> ja...@fr...<br/> <b>An:</b> "Lars Callenbach" <lar...@gm...><br/> <b>Cc:</b> qua...@li...<br/> <b>Betreff:</b> Re: [Quantlib-dev] Calc Addin under Linux for QuantLibAddin-1.5.0</div> <div name="quoted-content">I have started to debug/test worksheets and things sort of work. Something that I dont understand; is OH working? Why I can not see the instantiation numbering (or whatever you call it) after the object name? Do you see this on MacOS?<br/> <br/> Best<br/> Pepe<br/> <br/> <br/> ----- Original Message -----<br/> > Hello again Lars,<br/> > Sorry for the blackout; I was struggling with it and had not much to<br/> > contribute with. But your last branch did help me a lot and save me<br/> > quite a bit of time an effort. A big thank you.<br/> ><br/> > I am building it ok on Linux and running the worksheets. I am<br/> > providing a pedestrian Makefile for it. I can not do it with<br/> > Makefile.oo as it is now. The Makefile is very basic but the idea is<br/> > that eventually both Makefiles merge into a proper am file. It just<br/> > provides a dynamic linked lib and installs it. Prerequisites on the<br/> > environment are the same ones you mention.<br/> ><br/> > There are a couple of differences. I dont install the way you do (my<br/> > system needs sudo for that); I use a component file and my manifest<br/> > file is fixed (this is the only collision I see with your make). Its<br/> > similar to the standard add-in example in the uno sdk. Also the way<br/> > I generate from the idl has a few unnecessary dependences, its also<br/> > taken from the example.<br/> ><br/> > I am adding this into github.com/japari/quantlib/tree/Calc_linuxmake<br/> > This is a branch that I created from the PR you sent to Eric but<br/> > when I uploaded to GitHub it only lets me PR to Erics fork. Can you<br/> > take the changes into your branch please? I prefer that rather than<br/> > issuing a PR to Eric.<br/> ><br/> > Is there anyone working on this on Windows?<br/> ><br/> > Best<br/> > Pepe<br/> ><br/> > My TODO list (comments on Makefile.linux results)<br/> > -Useful functions like OHrangeRetrieveError are missing.<br/> > -At least some functions, if not all, fail when called without all<br/> > arguments given; i.e. there are no default values taken in.<br/> > -Error codes as numbers are ugly.<br/> > -Consider renaming the Add-In service to "QuantLib" ? This might be<br/> > more tidy when looking for a function in the Calc drop down menu.<br/> > -Debug the Makefile dependencies; when launching the Makefile with<br/> > '-j' things go wrong: ...'at times'... theres no ./com/* generation,<br/> > or too late and as a result the f's are not shown. No complains<br/> > about missing includes though....<br/> > -Trim the idl compilation; lots of stuff there not used.<br/> ><br/> ><br/> ><br/> ><br/> ><br/> > ----- Original Message -----<br/> > > Hi all,<br/> > ><br/> > > Pepe, changed index.xml to remove inflation dependencies.<br/> > > Eric, pushed anotther version without generated files in Calc<br/> > > directory<br/> > > - do I have to start another pull request or is the old one still<br/> > > active<br/> > > and includes the last changes?<br/> > ><br/> > > Best regards,<br/> > > Lars<br/> > ><br/> > > Am Donnerstag, den 16.07.2015, 06:19 +0200 schrieb ja...@fr...:<br/> > > > Hi all,<br/> > > > Lars, I have tried your branch and I the AddIn compilation fails<br/> > > > at<br/> > > > the inflation bonds registration so it looks like I need the xml<br/> > > > files you mentioned. Can I have a look at them please? Can you<br/> > > > add<br/> > > > those to github?<br/> > > > Thank you.<br/> > > > Pepe<br/> > > ><br/> > > ><br/> > > > ----- Original Message -----<br/> > > > > Hi Eric,<br/> > > > ><br/> > > > > set up a pull request against 1.6.<br/> > > > ><br/> > > > > @Pepe: is something missing or does everything work fine for<br/> > > > > you<br/> > > > > (I<br/> > > > > have<br/> > > > > written some more xml files for inflation, model calibration<br/> > > > > etc.<br/> > > > > which<br/> > > > > are not included in this pull request)?<br/> > > > ><br/> > > > ><br/> > > > > Best regards,<br/> > > > > Lars<br/> > > > ><br/> > > > ><br/> > > > > Am Sonntag, den 12.07.2015, 12:57 +0300 schrieb Eric Ehlers:<br/> > > > > > Hi Lars,<br/> > > > > ><br/> > > > > > This is great!<br/> > > > > ><br/> > > > > > Would it be possible for you to send me a pull request for<br/> > > > > > this?<br/> > > > > > If<br/> > > > > > you could do it against my v1.6.x branch then I will include<br/> > > > > > it<br/> > > > > > in<br/> > > > > > the<br/> > > > > > 1.6 release which I am preparing now. Otherwise if you do it<br/> > > > > > against<br/> > > > > > my master then it will go in to 1.7.<br/> > > > > ><br/> > > > > > Kind Regards,<br/> > > > > > Eric<br/> > > > > ><br/> > > > > > On Fri, 10 Jul 2015 19:05:55 +0200<br/> > > > > > Lars Callenbach <lar...@gm...> wrote:<br/> > > > > ><br/> > > > > > > Hello,<br/> > > > > > ><br/> > > > > > > I have extended the addin code for the LibreOffice calc<br/> > > > > > > plugin.<br/> > > > > > > Changes: 1) vetor return values (iteration over std::vector<br/> > > > > > > results)<br/> > > > > > > 2) return type seqseq(ANY) for all addin functions to<br/> > > > > > > provide<br/> > > > > > > addin<br/> > > > > > > access to exceptions (exception messages will be displayed<br/> > > > > > > in<br/> > > > > > > cells)<br/> > > > > > > 3) implementation of default value handling<br/> > > > > > > (ANY::hasValue()<br/> > > > > > > function)<br/> > > > > > > 4) works clean with dynamic libraries (and with static<br/> > > > > > > linking)<br/> > > > > > ><br/> > > > > > > I have changed a lot of XML config files and some python<br/> > > > > > > files<br/> > > > > > > for the<br/> > > > > > > calc addin and I suggest to include my changes in the<br/> > > > > > > official<br/> > > > > > > code.<br/> > > > > > > How shall we proceed to include these changes in the<br/> > > > > > > official<br/> > > > > > > version? Who is responsible for the maintenance of the calc<br/> > > > > > > code?<br/> > > > > > > Can<br/> > > > > > > I help maintaining the calc code?<br/> > > > > > ><br/> > > > > > > The generated code is available under<br/> > > > > > > "<a href="https://www.callenbach.eu" target="_blank">https://www.callenbach.eu</a>".<br/> > > > > > ><br/> > > > > > ><br/> > > > > > > Best regards,<br/> > > > > > > Lars<br/> > > > > ><br/> > > > ><br/> > > > ><br/> > > > ><br/> > ><br/> > ><br/> > ><br/> ><br/> > ------------------------------------------------------------------------------<br/> > _______________________________________________<br/> > QuantLib-dev mailing list<br/> > Qua...@li...<br/> > <a href="https://lists.sourceforge.net/lists/listinfo/quantlib-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/quantlib-dev</a><br/> ></div> </div> </div> </div></div></body></html> |