[Libreoffice-commits] core.git: Changes to 'refs/changes/32/1232/2'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/32/1232/3'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/32/1232/4'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/32/1232/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/47/1447/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/95/1195/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Re: additional calc functions produce warnings
AFAIR you recently added the pricing functions. When running calc to test my code changes, I get lots of: warn:legacy.osl:11918:1:/home/w.donkers/git/libo/tools/source/rc/resmgr.cxx:773: file:///home/w.donkers/git/libo/solver/unxlngi6/installation/opt/program/../program/resource/pricingen-US.res Class: 256, Id: 0. Cannot free resource! Thanks for the info, but I'm not sure how to debug this. Maybe someone else can comment what Class: 256, Id: 0 is and what a possible cause of the warning may be? I could only guess it's something to do with UNO as there's no dynamic allocations in the core calculations. Also, what did you change, and did you get the same warnings before? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: additional calc functions produce warnings
Now I can see them with that obvious tip. Resource
RID_PRICING_DEFFUNCTION_NAME is empty in
scaddins/source/pricing/pricing.src
Ah yes, thanks for that. I left that empty because I assumed this was
optional and I didn't understand the point of it. It seemed something
to do with translating function names (the other add-ins only
contain a German translation and again the English version).
In any case, the attached diff will get rid of the warnings. Don't
know if it's ok to leave ItemList empty, but at least no warnings are
printed, except for
core/sfx2/source/control/dispatch.cxx:1477: Childwindow slot missing!
which I guess is unrelated.
-
./core/scaddins/source/pricing/pricing.src
--
Resource RID_PRICING_DEFFUNCTION_NAMES
{
StringArray PRICING_DEFFUNCNAME_OptBarrier
{
ItemList =
{
};
};
StringArray PRICING_DEFFUNCNAME_OptTouch
{
ItemList =
{
};
};
StringArray PRICING_DEFFUNCNAME_OptProbHit
{
ItemList =
{
};
};
StringArray PRICING_DEFFUNCNAME_OptProbInMoney
{
ItemList =
{
};
};
};
diff --git a/scaddins/source/pricing/pricing.src
b/scaddins/source/pricing/pricing.src
index 6aa1675..67ae69f 100644
--- a/scaddins/source/pricing/pricing.src
+++ b/scaddins/source/pricing/pricing.src
@@ -432,5 +432,32 @@ Resource RID_PRICING_FUNCTION_NAMES
// for translating function names
Resource RID_PRICING_DEFFUNCTION_NAMES
{
+StringArray PRICING_DEFFUNCNAME_OptBarrier
+{
+ItemList =
+{
+};
+};
+
+
+StringArray PRICING_DEFFUNCNAME_OptTouch
+{
+ItemList =
+{
+};
+};
+StringArray PRICING_DEFFUNCNAME_OptProbHit
+{
+ItemList =
+{
+};
+};
+
+StringArray PRICING_DEFFUNCNAME_OptProbInMoney
+{
+ItemList =
+{
+};
+};
};
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: license statement
Hi Markus, Many thanks for the commits and sorting out the warnings. Also: All of my past future contributions to LibreOffice may be licensed under the MPL/LGPLv3+ dual license. Cheers, Tino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
Small problems: - compiler warnings from within boost We need to patch them out otherwise the Werror build will fail. It seems that these warnings are also fixed upstream. This really confuses me. The warnings I'm getting are of the form ...boost/random/binomial_distribution.hpp:47:5: warning: declaration of 'p' shadows a member of 'this' [-Wshadow] I'm also getting similar warnings even with boost 1.52, however only if boost resides in a non-standard directory. Linking boost to /usr/local/include and using -I/usr/local/include makes all the -Wshadow warnings disappear. Don't know if you can confirm this but this is beyond me: # ln -s .../core/solver/unxlngx6.pro/inc/external/boost /usr/local/include # ln -s .../core/solver/unxlngx6.pro/inc/external/boost /tmp/include $ cd .../core/sc/source/core/tool $ g++ -Wall -Wshadow -c random.cxx -I/tmp/include ... [warnings] ... $ g++ -Wall -Wshadow -c random.cxx -I/usr/local/include [no warning] Just a few more comments about the patch. We need to ifdef all unused methods in random.[ch]xx otherwise they will be removed in nearly no time. We are removing unused functions to clean the codebase. Please also don't leave old code commented, we have git for code history so we don't need to keep all code as comments. Before I'll push the change with these modifications I'll check with a big file containing a lot of RANDOM functions to check that we are not introducing a performance regression. Yes, thanks, that makes sense. I hope it speeds up slightly... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
just happened to reimplement RAND() with a B.A Wichmann
and I.D Hill generator.. see
As they are entitled to. No doubt we'll come up with a comprehensive,
nicely architected and beautiful solution of our own :-)
Ok, I'll go ahead with a suggestion then. :)
Attached patch is just a simple wrapper around boost, to be used like
sc::rng::seed() to replace libc srand()
sc::rng::rand() to replace libc rand()
and a few more distributions.
I've also modified ScInterpreter::ScRandom()
to simply call sc::rng::uniform()
which should solve bug 33365.
I've not modified RANDBETWEEN(a,b) yet but this could simply call
sc::rng::uniform_int(a,b).
Also, the rand in Basic could be changed in the future.
Small problems:
- compiler warnings from within boost
- few asserts might need to be replaced
From 569a0e05f1c2320041786be051842a552aca885c Mon Sep 17 00:00:00 2001
From: tino ttk...@gmail.com
Date: Thu, 6 Dec 2012 14:05:11 +
Subject: [PATCH] fdo#33365 added wrapper for boost random, use that in RAND()
Change-Id: Iafc524d12c76423f74dc16b42595e52fbc5a1e54
---
sc/Library_sc.mk | 1 +
sc/source/core/data/global.cxx | 2 +
sc/source/core/inc/random.hxx| 35 ++
sc/source/core/tool/interpr1.cxx | 4 +-
sc/source/core/tool/random.cxx | 255 +++
5 files changed, 296 insertions(+), 1 deletion(-)
create mode 100644 sc/source/core/inc/random.hxx
create mode 100644 sc/source/core/tool/random.cxx
diff --git a/sc/Library_sc.mk b/sc/Library_sc.mk
index 348300f..10918e4 100644
--- a/sc/Library_sc.mk
+++ b/sc/Library_sc.mk
@@ -213,6 +213,7 @@ $(eval $(call gb_Library_add_exception_objects,sc,\
sc/source/core/tool/progress \
sc/source/core/tool/queryentry \
sc/source/core/tool/queryparam \
+ sc/source/core/tool/random \
sc/source/core/tool/rangelst \
sc/source/core/tool/rangenam \
sc/source/core/tool/rangeseq \
diff --git a/sc/source/core/data/global.cxx b/sc/source/core/data/global.cxx
index 4e449c5..e18d241 100644
--- a/sc/source/core/data/global.cxx
+++ b/sc/source/core/data/global.cxx
@@ -75,6 +75,7 @@
#include sc.hrc
#include scmod.hxx
#include appoptio.hxx
+#include random.hxx
// ---
@@ -557,6 +558,7 @@ void ScGlobal::Init()
// names from the compiler.
ScParameterClassification::Init();
srand( (unsigned) time( NULL ) ); // Random Seed Init fuer Interpreter
+sc::rng::seed( time( NULL ) ); // seed for libc rand() replacement
InitAddIns();
diff --git a/sc/source/core/inc/random.hxx b/sc/source/core/inc/random.hxx
new file mode 100644
index 000..dc068b1
--- /dev/null
+++ b/sc/source/core/inc/random.hxx
@@ -0,0 +1,35 @@
+/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
+/*
+ * This file is part of the LibreOffice project.
+ *
+ * This Source Code Form is subject to the terms of the Mozilla Public
+ * License, v. 2.0. If a copy of the MPL was not distributed with this
+ * file, You can obtain one at http://mozilla.org/MPL/2.0/.
+ */
+
+#ifndef SC_RANDOM_HXX
+#define SC_RANDOM_HXX
+
+namespace sc
+{
+namespace rng
+{
+
+void seed(int i); // set initial seed (equivalent of libc srand())
+uint32_t max(); // max number by rand() (equivalent of RAND_MAX)
+uint32_t min(); // min number by rand() (most likely 0)
+uint32_t rand();// replacement for libc's rand()
+
+int uniform_int(int from, int to); // uniform distribution given int range
+double uniform(); // uniform distribution in [0,1)
+double normal();// normal distribution N(0,1)
+double normal(double mu, double sigma); // N(mu, sigma^2)
+double lognormal(); // lognormal distribution: exp(N(0,1))
+double lognormal(double mu, double sigma);
+
+} // namespace
+} // namespace
+
+#endif
+
+/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sc/source/core/tool/interpr1.cxx b/sc/source/core/tool/interpr1.cxx
index 43a21eb..adecc75 100644
--- a/sc/source/core/tool/interpr1.cxx
+++ b/sc/source/core/tool/interpr1.cxx
@@ -44,6 +44,7 @@
#include globstr.hrc
#include attrib.hxx
#include jumpmatrix.hxx
+#include random.hxx
#include comphelper/processfactory.hxx
#include comphelper/string.hxx
@@ -1711,7 +1712,8 @@ void ScInterpreter::ScPi()
void ScInterpreter::ScRandom()
{
RTL_LOGFILE_CONTEXT_AUTHOR( aLogger, sc, er, ScInterpreter::ScRandom );
-PushDouble((double)rand() / ((double)RAND_MAX+1.0));
+//PushDouble((double)rand() / ((double)RAND_MAX+1.0));
+PushDouble(sc::rng::uniform());
}
diff --git a/sc/source/core/tool/random.cxx b/sc/source/core/tool/random.cxx
new file mode 100644
index 000..4195e26
--- /dev/null
+++ b/sc/source/core/tool/random.cxx
@@ -0,0 +1,255 @@
+/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
+/*
+ * This file is part of the LibreOffice project
Re: random number generators for calc
What about implementation in random.cxx and creating random.hxx so all the random stuff is in one place? Why do you want this abstraction? Following KISS I would just start implementing the functions in ScInterpreter and extract commonly used parts into an own method. If at some point other parts of Libreoffice also need random functions with known statistical properties we can still extract them. I'm happy to propose a patch this way. Just need to be aware that RANDBETWEEN() which is part of scaddins would also need a replacement of rand(). Also, another consideration is the way to implement different non-uniform distribution, just wondering if anyone has a strong view on this: (1) implementation similar to rand() and srand(), where the state of the generator is saved in a global variable (which is not exposed via a header file and can only be changed by srand), and all other non-uniform generators draw from the same rand(). this requires an srand() call ideally at the start of libreoffice or calc, currently done in ./sc/source/core/data/global.cxx (2) each rand_nonuniform() function draws from it's own private rand() generator with its own state, which is defined as a static variable and initialised at the first call. For a general purpose library one would probably do (1) (or (1) and encapsulated in a class) but for calc both versions are fine in my opinion. Memory requirements for boost::mt19937 is 625*sizeof(uint32_t) so I guess even if we had 10 copies (one for each non-uniform rand) of it that wouldn't be a problem? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] adding calc add-in for option pricing
Do I also have to change the function name exported to the cell, e.g.
OPT_BARRIER()?
My concern here would be that potentially calc function naming is not
always a great match to UNO constraints - and yet those functions are
defined as IDL. Some functions have '.'s in them IIRC, others might want
to have _'s (?) and translating functions is prolly not feasible via the
UNO interface.
Not sure I understand, would you prefer to see no '_' and rather
me to change OPT_BARRIER() to OPTBARRIER() or something?
I've attached a patch to sort out the internal UNO variable/function
naming issue.
Cheers, Tino
From 4e61de11fb73973519d409c39ec66c84d3316f9b Mon Sep 17 00:00:00 2001
From: tino ttk...@gmail.com
Date: Tue, 4 Dec 2012 17:26:52 +
Subject: [PATCH] changed function names and variables to conform with UNO
style
Change-Id: I3de884b54083a6916a5baed4d475016aa9d4ddec
---
.../com/sun/star/sheet/addin/XPricingFunctions.idl | 46 +++---
scaddins/source/pricing/pricing.cxx| 20 +-
scaddins/source/pricing/pricing.hrc| 34
scaddins/source/pricing/pricing.hxx| 8 ++--
scaddins/source/pricing/pricing.src| 16
5 files changed, 63 insertions(+), 61 deletions(-)
diff --git a/scaddins/idl/com/sun/star/sheet/addin/XPricingFunctions.idl b/scaddins/idl/com/sun/star/sheet/addin/XPricingFunctions.idl
index 495891a..12d66d8d 100644
--- a/scaddins/idl/com/sun/star/sheet/addin/XPricingFunctions.idl
+++ b/scaddins/idl/com/sun/star/sheet/addin/XPricingFunctions.idl
@@ -38,34 +38,36 @@ module addin
*/
interface XPricingFunctions : com::sun::star::uno::XInterface
{
-/// opt_barrier()
-double getOpt_barrier( [in] double spot, [in] double vol,
-[in] double r, [in] double rf, [in] double T, [in] double strike,
-[in] double barrier_low, [in] double barrier_up,
-[in] double rebate,
-[in] string put_call, [in] string in_out,
-[in] string continuous, [in] any greek )
+/// OPT_BARRIER(), pricing of a barrier option.
+double getOptBarrier( [in] double Spot, [in] double Vol,
+[in] double Rate, [in] double RateForeign,
+[in] double Maturity, [in] double Strike,
+[in] double BarrierLow, [in] double BarrierUp,
+[in] double Rebate,
+[in] string PutCall, [in] string InOut,
+[in] string Continuous, [in] any Greek )
raises( com::sun::star::lang::IllegalArgumentException );
-/// opt_touch()
-double getOpt_touch( [in] double spot, [in] double vol,
-[in] double r, [in] double rf, [in] double T,
-[in] double barrier_low, [in] double barrier_up,
-[in] string for_dom, [in] string in_out,
-[in] string continuous, [in] any greek )
+/// OPT_TOUCH(), pricing of a touch/no-touch option.
+double getOptTouch( [in] double Spot, [in] double Vol,
+[in] double Rate, [in] double RateForeign,
+[in] double Maturity,
+[in] double BarrierLow, [in] double BarrierUp,
+[in] string ForeignDomestic, [in] string InOut,
+[in] string Continuous, [in] any Greek )
raises( com::sun::star::lang::IllegalArgumentException );
-/// opt_prob_hit()
-double getOpt_prob_hit( [in] double spot, [in] double vol,
-[in] double mu, [in] double T,
-[in] double barrier_low, [in] double barrier_up )
+/// OPT_PROB_HIT(), probability of hitting a barrier.
+double getOptProbHit( [in] double Spot, [in] double Vol,
+[in] double Mu, [in] double Maturity,
+[in] double BarrierLow, [in] double BarrierUp )
raises( com::sun::star::lang::IllegalArgumentException );
-/// opt_prob_inmoney()
-double getOpt_prob_inmoney( [in] double spot, [in] double vol,
-[in] double mu, [in] double T,
-[in] double barrier_low, [in] double barrier_up,
-[in] any strike, [in] any put_call )
+/// OPT_PROB_INMONEY(), probability of ending up in-the-money.
+double getOptProbInMoney( [in] double Spot, [in] double Vol,
+[in] double Mu, [in] double Maturity,
+[in] double BarrierLow, [in] double BarrierUp,
+[in] any Strike, [in] any PutCall )
raises( com::sun::star::lang::IllegalArgumentException );
};
diff --git a/scaddins/source/pricing/pricing.cxx b/scaddins/source/pricing/pricing.cxx
index ba4cb31..cf65787 100644
--- a/scaddins/source/pricing/pricing.cxx
+++ b/scaddins/source/pricing/pricing.cxx
@@ -110,10 +110,10 @@ ScaResId::ScaResId( sal_uInt16 nId, ResMgr rResMgr ) :
const ScaFuncDataBase pFuncDataArr[] =
{
- FUNCDATA( Opt_barrier, 13, ScaCat_Finance,UNIQUE, STDPAR),
- FUNCDATA( Opt_touch, 11, ScaCat_Finance
Re: opinions on additional calc functions
I've also got an example/test spreadsheet, but didn't quite know where to put it. The right solution is to extend the existing function (import) tests in sc/qa/unit/subsequent_filters-test.cxx with the test file being in sc/qa/unit/data/ods/functions.ods Ok, this is something I'll keep in mind for the future, but won't be able to do quickly. What about example files for the end user to see the functions of an add-in in action? My example file is 130k. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] adding calc add-in for option pricing
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1232 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/32/1232/1 adding calc add-in for option pricing Change-Id: Ica4b621a7ae7e5ab447192ae3fe7b8911295bef2 --- M Repository.mk M postprocess/packcomponents/makefile.mk A scaddins/AllLangResTarget_pricing.mk M scaddins/InternalUnoApi_scaddins.mk A scaddins/Library_pricing.mk M scaddins/Module_scaddins.mk A scaddins/idl/com/sun/star/sheet/addin/PricingFunctions.idl A scaddins/idl/com/sun/star/sheet/addin/XPricingFunctions.idl A scaddins/source/pricing/black_scholes.cxx A scaddins/source/pricing/black_scholes.hxx A scaddins/source/pricing/pricing.component A scaddins/source/pricing/pricing.cxx A scaddins/source/pricing/pricing.hrc A scaddins/source/pricing/pricing.hxx A scaddins/source/pricing/pricing.src M scp2/source/calc/file_calc.scp M scp2/source/calc/module_calc.scp M solenv/gbuild/extensions/pre_MergedLibsList.mk 18 files changed, 3,030 insertions(+), 1 deletion(-) -- To view, visit https://gerrit.libreoffice.org/1232 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ica4b621a7ae7e5ab447192ae3fe7b8911295bef2 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Tino ttk...@gmail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: opinions on additional calc functions
but I must be missing something? you are missing the wonder that is scp2 :-/ that is the thing which defines which files end up where in the installation; if you don't add it there it won't be installed. Haha, brilliant thanks, that helped a lot! I've submitted my changes via gerrit, hope I've not made any more silly mistakes. Given that Gnumeric already implemented or will implement the functions I would strictly follow them for interoperability. You can have the I haven't actually implemented any function which is already in Gnumeric, but I'm following their pattern of parameters inputs in so far as to use one character to identify things like put or call. I've also extended this to the optional greek parameter which now also takes char inputs (but accepts full strings also, e.g. d and delta, g and gamma, etc). I've also got an example/test spreadsheet, but didn't quite know where to put it. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
of course it doesn't have fancy features like ranges or non-uniform distribution... That's ok, I wouldn't use that against it, because these things are independent. Any uniform int generator can easily be extended to ranges, and uniform [0,1] distribution. And at least in theory, any non-uniform distribution can then be generated using rand_some_non_uniform() = F_inv( rand_uniform01() ); where F_inv() is the inverse cdf (cumulative distribution function) which in practice is not always easily available. Gnumeric has access to the inverse cdf's through R. Boost also has them implemented already (not as comprehensive as R though). Btw, boost has the same structure, boost::mt19937 only generates integers, and this forms the basis for all other distributions. ... looking at random.cxx it appears to use a MD5 hash to generate the random bytes; initialization is via seconds/nanoseconds of current time and thread-id. since the cryptographic hash implementations in sal/rtl don't look heavily optimized this is likely not be the fastest way to generate random numbers, if that is a concern... Speed is not my concern here (I guess parsing a cell is of an order of magnitude slower?). My problem is with statistical properties, and until somebody knows exactly what random.cxx does, I'd advice against using it. I'm also no expert and I may well be wrong but an MD5 based random number generator sounds a bit like a home made generator where we don't even know if it's truly uniform distributed. We should not implement them in rtl/math.hxx until there are more users than calc's interpreter that need it. Lets not overcomplicate this stuff as long as it is not necessary. What about implementation in random.cxx and creating random.hxx so all the random stuff is in one place? Tino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
the header is sal/inc/rtl/random.h (which is apparently a C interface).
Exactly, the C++ interface is missing. Also, the source doesn't have
any comments to say what algorithm is implemented etc. Do you know?
but why do we need a wrapper around boost in sal? i mean i haven't
looked at the boost random stuff but unless its interface is horrible
(always a possibility with boost i guess) _and_ there are multiple
places where we'd want to call it, then why not use it directly from
Calc's formula implementation?
I guess that's for someone more experienced to comment on. My simple
reason was rtl::math seems a good collection of maths functions this
may fit in, and there's no decision yet if RANDNORMAL() etc should be
implemented in sc or scaddins (or at all?).
The boost code would look something like this:
#include boost/random.hpp
// the underlying random number generator as global variable
// using Mersenne twister algorithm
#define BOOST_RNG_ALGO boost::mt19937
BOOST_RNG_ALGO global_rng;
// set initial state of generator
void rand_set(int i){
global_rng.seed(i);
}
// rand from a discrete uniform (same as RANDBETWEEN())
int rand_uniform_int(int from, int to){
assert(fromto);
static boost::variate_generatorBOOST_RNG_ALGO,
boost::random::uniform_int_distribution
myrand(global_rng,
boost::random::uniform_int_distribution());
myrand.distribution().param(
boost::random::uniform_int_distribution::param_type(from,to));
return myrand();
}
// rand from a Chi-squared Chi^2(k) distribution
double rand_chisq(int k) {
assert(k0);
static boost::variate_generatorBOOST_RNG_ALGO,
boost::random::chi_squared_distribution
myrand(global_rng,
boost::random::chi_squared_distribution());
myrand.distribution().param(
boost::random::chi_squared_distribution::param_type(k));
return myrand();
}
...
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
I've had a look at what Gnumeric offers, and they've done a big job on random number generation. Comparing with what is available in boost I've separated the list into rand functions which could be quickly implemented using boost and those which can't (and would require more intelligence to implement). Another problem might be that boost 1.44 which is currently used in libreoffice has even fewer distribution functions implemented. If there's interest, I'd be happy to work on a patch to implement the first half of the functions into core/sal/rtl/source/math.cxx or maybe random.cxx? However, random.* seems not that well maintained as there's no random.hxx. http://www.boost.org/doc/libs/1_52_0/doc/html/boost_random/reference.html#boost_random.reference.distributions gnumeric rand functions (available in boost) randbernoulli random variate from a Bernoulli distribution randbetween a random integer number between and including bottom and randbinom random variate from a binomial distribution randcauchy random variate from a Cauchy or Lorentz distribution randchisq random variate from a Chi-square distribution randdiscreterandom variate from a finite discrete distribution randexp random variate from an exponential distribution randfdist random variate from an F distribution randgamma random variate from a Gamma distribution randgeomrandom variate from a geometric distribution randlognorm random variate from a lognormal distribution randnegbinomrandom variate from a negative binomial distribution randnormrandom variate from a normal distribution randpoisson random variate from a Poisson distribution randtdist random variate from a Student t distribution randuniform random variate from the uniform distribution from a to b randweibull random variate from a Weibull distribution gnumeric rand functions (not available in boost) randbetarandom variate from a Beta distribution randexppow random variate from an exponential power distribution randgumbel random variate from a Gumbel distribution randhyperg random variate from a hypergeometric distribution randlandau random variate from the Landau distribution randlaplace random variate from a Laplace distribution randlevyrandom variate from a Levy distribution randlog random variate from a logarithmic distribution randlogisticrandom variate from a logistic distribution randnormtailrandom variate from the uppertail of a normal distribution randpareto random variate from a Pareto distribution randrayleighrandom variate from a Rayleigh distribution randrayleightailrandom variate from the tail of a Rayleigh distri randsnorm random variate from a skew normal distribution randstdist random variate from a skew t distribution ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] added option pricing functions to scaddins
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1195 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/95/1195/1 added option pricing functions to scaddins Change-Id: I942fa08f9bf0e855eebd6293ad996b45ebfade57 --- M .git-hooks/commit-msg M scaddins/Library_analysis.mk M scaddins/idl/com/sun/star/sheet/addin/XAnalysis.idl M scaddins/source/analysis/analysis.hrc M scaddins/source/analysis/analysis.hxx M scaddins/source/analysis/analysis.src M scaddins/source/analysis/analysis_deffuncnames.src M scaddins/source/analysis/analysis_funcnames.src M scaddins/source/analysis/analysishelper.cxx A scaddins/source/analysis/black_scholes.cxx A scaddins/source/analysis/black_scholes.hxx M scaddins/source/analysis/financial.cxx 12 files changed, 1,519 insertions(+), 135 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1195 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I942fa08f9bf0e855eebd6293ad996b45ebfade57 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Tino ttk...@gmail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
Isn't boost::mt19937 somewhat overkill for the simple RAND() functions? 3) It so happens that the algorithm used in boost is slightly faster than glibc's, which is an added bonus. If that's the case then my objection is moot :-) The only problem with boost is the thousand or so header files it includes and so slows down compilation but yes as the algorithm goes, it's fast and has good statistical properties. It seems it also made its way into the std library: http://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine As for RANDNORMAL() I'm very keen for this to happen because as far as statistics is concerned it'll be used more than RAND(). I clearly don't know about ODFF and which functions it includes but if it includes density functions of statistical distributions then it should in my opinion also contain their random generators. Independently of whether you decide to allow the use of boost, at least the normal distribution generator can be easily implemented as: RANDNORMAL() = sqrt(-2.0*log(RAND())) * cos(2.0*M_PI*RAND()) RANDNORMAL(mu, sigma) = mu + sigma * sqrt(-2.0*log(RAND())) * cos(2.0*M_PI*RAND()) Other distributions can be more complicated ... Tino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: opinions on additional calc functions
I suggest to open a new directory under scaddins/source, e.g.
scaddins/source/pricing (or scaddins/source/financial if you plan to add
other functionality than pricing) and create a new Add-In, for a simple
approach how to create an Add-In see scaddins/source/datefunc
Ok, will do. I've already submitted a patch which placed everything
under scaddins/source/analysis (the one where you pointed out the
error with commit-msg). Do I need to delete this patch or can I just
leave it on gerrit?
Btw, if Gnumeric already has them, how does it write them to ODF? We
should do the same for interoperability.
Within content.xml it writes something like
table:... table:formula=of:=[.E$9]*ORG.GNUMERIC.OPT_BS([.E$8];...
As for parameters they are mainly of double type but some are of enum
type. The enums could be mapped to integers but I've a slight
preference for STRING inputs but not sure how that is viewed here with
regard to localisation? E.g. I'm currently using p to specify a put
and c for a call, and i for in, o for out, and delta for delta
(d/dS), gamma for gamma (d^2/dS^2), etc.
Constant string arguments to functions MUST NOT be localized. I'd rather
use integers there, so no one can complain about unlocalized terms.
Which also eliminates the need of cascaded if(){}else if(){}else if(){}
... chains with slow string comparisons and use switch case statements
instead.
What I like about the char/string inputs is that they are descriptive.
Integers are much less intuitive to the user. Gnumeric currently
implements p/c inputs but they are strongly opposed to delta,
gamma, etc and move them into the function names, e.g.
opt_bs_delta(), opt_bs_gamma() and so have 7 instead of one function
(something I won't repeat). If there are no strong objections, I'd
prefer to go with char/string inputs or anything which is more
intuitive for the user?
Thanks, Tino
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: opinions on additional calc functions
This UNO add-in thing turns out a bit too complex for me. I've managed as far as getting a libpricinglo.so compiled but make install doesn't copy it into destination. Also there's no entry of the new add-in in services.rdb, which I think is needed. I've already modified Repository.mk scaddins/*.mk postprocess/packcomponents/makefile.mk solenv/gbuild/extensions/pre_MergedLibsList.mk but I must be missing something? Given that Gnumeric already implemented or will implement the functions I would strictly follow them for interoperability. You can have the 7 different functions at formula level and still internally have them call one function with an enum, or however you would like to implement it. Doing things differently doesn't help users. The only function which is already in Gnumeric and I'm trying to implement here is opt_bs() and I'll keep the parameters the same then. Having 7-9 different functions may be ok if you only have one option pricing function, but my plan is for 4 functions and I'm not going to spam calc with 4*9=36 functions. :) I should say I'm also trying to add two pricing functions (opt_barrier() and opt_touch()) in Gnumeric but I've not reached an agreement with the developers on exactly this issue so it probably will simply be implemented without the Greek flag (delta, gamma, vega, etc). If there are no strong objections, I'd prefer to go with char/string inputs or anything which is more intuitive for the user? I don't see that specifying a parameter with the name is more intuitive than using a function with the same name appended. To the contrary, function names can be localized while string arguments can't. No, that's right, but that would explode the number of functions unnecessarily. If string inputs are a big problem then I'd rather go for char inputs (or even int as a last resort). Cheers, Tino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
added option pricing functions to scaddins
Tino has abandoned this change. Change subject: added option pricing functions to scaddins .. Patch Set 1: Abandoned new suggestion is to add the new pricing function under a separate add-in -- To view, visit https://gerrit.libreoffice.org/1195 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I942fa08f9bf0e855eebd6293ad996b45ebfade57 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Tino ttk...@gmail.com Gerrit-Reviewer: Eike Rathke er...@redhat.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
opinions on additional calc functions
Hi,
I'm new to libreoffice dev and I'm working on implementing some
additional financial (option pricing) functions for calc. So far I've
used
./core/scaddins/source/analysis/
locally to add my functions but I've been told scaddins is mainly for
ms excel functions and ./core/sc/ is certainly not the right place. So
I'd need some advice where to place the new functions.
Also, any opinions on naming and parameter inputs are welcome.
The functions in question return prices and greeks (partial
derivatives of the price to certain input values) of some basic
financial options, all using the classic Black-Scholes model.
OPT_BS(...): option price of a put/call option
OPT_DIGITAL(...): option price of a digital/binary option
OPT_BARRIER(...): barrier options (=put/call with barriers)
OPT_TOUCH(...): touch/no-touch options (=digitals with barriers)
...
I've modelled the names on what is implemented in Gnumeric which has a
range of opt_foo(...) functions.
As for parameters they are mainly of double type but some are of enum
type. The enums could be mapped to integers but I've a slight
preference for STRING inputs but not sure how that is viewed here with
regard to localisation? E.g. I'm currently using p to specify a put
and c for a call, and i for in, o for out, and delta for delta
(d/dS), gamma for gamma (d^2/dS^2), etc.
I've attached a code snipped of OPT_BARRIER(...) interface
implementation.
Cheers, Tino
#include black_scholes.hxx
using namespace sca::analysis;
bool opt_getinput_putcall(bs::types::PutCall pc, const STRING str) {
if(str.compareToAscii(c,1)==0) {
pc=bs::types::Call;
} else if(str.compareToAscii(p,1)==0) {
pc=bs::types::Put;
} else {
return false;
}
return true;
}
bool opt_getinput_inout(bs::types::BarrierKIO kio, const STRING str) {
if(str.compareToAscii(i,1)==0) {
kio=bs::types::KnockIn;
} else if(str.compareToAscii(o,1)==0) {
kio=bs::types::KnockOut;
} else {
return false;
}
return true;
}
bool opt_getinput_barrier(bs::types::BarrierActive cont, const STRING str) {
if(str.compareToAscii(c,1)==0) {
cont=bs::types::Continuous;
} else if(str.compareToAscii(e,1)==0) {
cont=bs::types::Maturity;
} else {
return false;
}
return true;
}
bool opt_getinput_fordom(bs::types::ForDom fd, const STRING str) {
if(str.compareToAscii(f,1)==0) {
fd=bs::types::Foreign;
} else if(str.compareToAscii(d,1)==0) {
fd=bs::types::Domestic;
} else {
return false;
}
return true;
}
bool opt_getinput_greek(bs::types::Greeks greek, const ANY anyval) {
STRING str;
if(anyval.getValueTypeClass() == ::com::sun::star::uno::TypeClass_STRING) {
anyval = str;
} else if(anyval.getValueTypeClass() == ::com::sun::star::uno::TypeClass_VOID) {
str=value;
} else {
return false;
}
if(str.compareToAscii(value)==0 || str.compareToAscii(price)==0 ) {
greek=bs::types::Value;
} else if(str.compareToAscii(delta)==0) {
greek=bs::types::Delta;
} else if(str.compareToAscii(gamma)==0) {
greek=bs::types::Gamma;
} else if(str.compareToAscii(theta)==0) {
greek=bs::types::Theta;
} else if(str.compareToAscii(vega)==0) {
greek=bs::types::Vega;
} else if(str.compareToAscii(volga)==0) {
greek=bs::types::Volga;
} else if(str.compareToAscii(vanna)==0) {
greek=bs::types::Vanna;
} else if(str.compareToAscii(rho)==0) {
greek=bs::types::Rho_d;
} else if(str.compareToAscii(rhof)==0) {
greek=bs::types::Rho_f;
} else {
return false;
}
return true;
}
double SAL_CALL AnalysisAddIn::getOpt_barrier( double spot, double vol,
double r, double rf, double T, double strike,
double barrier_low, double barrier_up, double rebate,
const STRING put_call, const STRING in_out,
const STRING barriercont, const ANY greekstr ) THROWDEF_RTE_IAE
{
bs::types::PutCall pc;
bs::types::BarrierKIO kio;
bs::types::BarrierActive bcont;
bs::types::Greeks greek;
// read and check input values
if( spot=0.0 || vol=0.0 || T0.0 || strike0.0 ||
!opt_getinput_putcall(pc,put_call) ||
!opt_getinput_inout(kio,in_out) ||
!opt_getinput_barrier(bcont,barriercont) ||
!opt_getinput_greek(greek,greekstr) ){
THROW_IAE;
}
double fRet=bs::barrier(spot,vol,r,rf,T,strike, barrier_low,barrier_up,
rebate,pc,kio,bcont,greek);
RETURN_FINITE( fRet );
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
random number generators for calc
Hi, There are currently only uniform random number generators available in calc, namely RAND() and RANDBETWEEN(...). I'd be interested in generators for other distributions, like normal, exponential etc. I'd suggest using boost/random.hpp and then implementation will be straight forward. We could also replace rand()/(RAND_MAX+1) in RAND() with a boost random generator (rand() under windows can be extremely poorly implemented and only have 2^16 different values or so). This would also solve this windows only bug: https://bugs.freedesktop.org/show_bug.cgi?id=33365 Opinions? Cheers, Tino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
So, Michael Stahl commented in the bug that we do have our own
random number generator function. One way is to just replace the
direct call to rand() to this function instead. That should be very
easy to do and I have no objection against it.
Just to be clear, I believe glibc's implementation of rand() is
excellent and doesn't need replacement unless one needs particular
statistical properties (the problem is only with windows rand()).
Boost offers generators I believe similar to glibc's rand() as well as
a few which have even better statistical properties but are slower.
The advantage of boost is that it includes transformations which lead
to all sorts of distributions ([0-1] uniform, normal, exponential ...).
This would allow for easy implementation of new functions like
RANDNORMAL(mu, sigma)
As for the bug report, if he's referring to
./core/sal/inc/rtl/random.h
then I can't see any function we can easily use for our purposes. It
seems to me all this does is generating and managing a random binary
array. From a quick look at the source it seems to use the
Wichmann-Hill algorithm, which apparently has a period of 16 million
(2^24) which is worse than glibc's rand().
Cheers, Tino
./core/sal/rtl/source/random.cxx
#define RTL_RANDOM_RNG(x, y, z) \
{ \
(x) = 170 * ((x) % 178) - 63 * ((x) / 178); \
if ((x) 0) (x) += 30328L; \
\
(y) = 171 * ((y) % 177) - 2 * ((y) / 177); \
if ((y) 0) (y) += 30269L; \
\
(z) = 172 * ((z) % 176) - 35 * ((z) / 176); \
if ((z) 0) (z) += 30307L; \
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
Thanks for the additional insight. Well, I can see two possibilities:
1) Use boost's generator for Windows platform-only, while we keep
the glibc's version for Linux. I wonder what the situation is on
Mac...
2) Use boost's generator for all platforms.
If there are no issues with using boost then I'd suggest 2) and use
boost's implementation of Mersenne Twister (boost::mt19937) as default
for all.
http://en.wikipedia.org/wiki/Mersenne_twister
I've attached a simple example on how the boost generator works. It
also turns out to be slightly faster than rand().
What is your opinion on implementing generators for other
distributions like normal and all the ones listed under statistics
(which calculate densities but don't generate)? With boost this is
simple so just a matter of extending the UNO interface.
Cheers, Tino
#include cstdio
#include cstdlib
#include ctime
#include boost/random.hpp
#include sys/time.h
// timer
double stoptime(void) {
struct timeval t;
gettimeofday(t,NULL);
return (double) t.tv_sec + t.tv_usec/100.0;
}
// glibc's rand, uniform [0,1]
double grand01() {
return (1.0/(RAND_MAX+1.0)) * rand();
}
// boost rand, uniform [0,1]
double brand01() {
static boost::mt19937 rng(time(0));
static boost::uniform_01boost::mt19937 rnd01(rng);
return rnd01();
}
// boost rand, normal N(0,1)
double brand_normal() {
static boost::mt19937 rng(time(0));
static boost::variate_generatorboost::mt19937,
boost::normal_distribution
rnd_normal(rng, boost::normal_distribution());
return rnd_normal();
}
// ==
// Name: main
// Description: main function, executed at runtime
// ==
int main(int argc, char** argv) {
const int n=1000;
double sum;
double t;
srand(time(0)); // initialise glibc's rand()
printf(glibc rand uniform: ); fflush(stdout);
sum=0.0;
t=stoptime();
for(int i=0; in; i++){
sum+=grand01();
}
printf(avg=%f (%.3fs)\n,sum/n,stoptime()-t); fflush(stdout);
printf(boost rand uniform: ); fflush(stdout);
sum=0.0;
t=stoptime();
for(int i=0; in; i++){
sum+=brand01();
}
printf(avg=%f (%.3fs)\n,sum/n,stoptime()-t); fflush(stdout);
printf(boost rand normal: ); fflush(stdout);
sum=0.0;
t=stoptime();
for(int i=0; in; i++){
sum+=brand_normal();
}
printf(avg=%f (%.3fs)\n,sum/n,stoptime()-t); fflush(stdout);
return EXIT_SUCCESS;
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
What is your opinion on implementing generators for other distributions like normal and all the ones listed under statistics (which calculate densities but don't generate)? Well, re-implementing the existing RAND and RANDBETWEEN with the new generator is no brainer. But I'm not sure if we really need to provide multiple variants for different random number generators. What we could do is to specify a run-time option for the algorithm for the normal RAND and RANDBETWEEN functions rather than providing multiple variants. That would be my preference. We already have formula engine options in Tools - Options (in the Formula tab page), so adding another one shouldn't be too difficult. Not sure I understand. My suggestion is that boost::mt19937 is the only underlying generator algorithm (generating int's) which is then transformed to get RAND() and RANDBETWEEN(i,j). Yet both are simple uniform distributions but the user might need Normal distributed random variables and then RAND() is of little use. So a function like RANDNORMAL() which generates N(0,1) (still using boost::mt19937) random numbers would be a useful addition, wouldn't it? Cheers, Tino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Proofing API Performance
I am making spelling/grammar/hyphenation extensions that query a remote service, and have some performance issues that I hope there are existing solutions for. In all cases, the extensions must work with check spelling/grammar as you type enabled. - How can I limit the request rate or make it smarter? Currently, LO seems to call the API for every word (or even letter) typed, which is incredibly wasteful as grammar checking only makes sense at sentence level. I also don't really want the whole paragraph at each call; just the last finished sentence. - Why doesn't LO remember the results? It draws the squigglies, but it then calls the checker again when right-clicking on an error, even if no changes are made in the interim. I can cache this in the extension, but it feels like something that should be handled in LO itself. In general, it feels like as you type incurs 50x more calls than needed. So if I missed some obvious option toggle or existing solution, I'd love to know. -- Tino Didriksen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
