Re: random number generators for calc
Hey Tino, 2012/12/6 tino ttk...@gmail.com: 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 We need to patch them out otherwise the Werror build will fail. It seems that these warnings are also fixed upstream. - few asserts might need to be replaced asserts are fine in the code. They are only used in debug and dbgutil builds, so will normally not show up in releases but helpt to find bugs earlier. 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. Regards, Markus ___ 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
Hey 2012/12/7 tino ttk...@gmail.com: 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] It is actually only partly fixed upstream. I opened boost#7774 for the missing change and fixed it for our internal boost with http://cgit.freedesktop.org/libreoffice/core/commit/?id=632cdffd08df8cdaeba47c6c42c7f718aaf9e751 I'll have a look at the remaining parts now. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
Hi, On Friday, 2012-12-07 17:04:52 +0100, Markus Mohrhard wrote: 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. I'd rather prefer if we did not patch external modules for Werror but instead use the warnings guard header mechanism, for example see i18npool/inc/warnings_guard_unicode_calendar.h Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgp6FFYJNfMNt.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
Hey tino, 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() I pushed this part of the patch. and a few more distributions. I did not push them. As soon as we have users for them it makes sense to add them. There is no good reason to add functions that might maybe used later. If we use them somewhere we can still use the patch for their implementation. I've also modified ScInterpreter::ScRandom() to simply call sc::rng::uniform() which should solve bug 33365. Pushed that without the old line. 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 The compiler warning is fixed. And here the link to the patch: http://cgit.freedesktop.org/libreoffice/core/commit/?id=8450a99c744e9005f19173e4df35d65640bcf5c4 Thanks a lot for the patch. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
On Wed, 2012-12-05 at 17:12 +0100, Eike Rathke wrote: 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 :-) ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ 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
Hi tino, On Saturday, 2012-12-01 11:22:09 +, tino wrote: 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, Actually rtl::math offers methods available with one or the other compiler but not all or unifying them, like isFinite() and erf() and such, or methods of general interest like approx...() and the safe sin(), cos(), ... methods. IMHO rtl::math is not a place for an abundant choice of RNGs. I can also hardly imagine that other applications than Calc would actually need them, anyhow, keeping all in one source file under sc/source/core/tool/ that could be moved down to svl/ if needed looks best to me. and there's no decision yet if RANDNORMAL() etc should be implemented in sc or scaddins (or at all?). I'd prefer in sc. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpFPzLynOTQQ.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
On 12/05/2012 11:29 AM, Eike Rathke wrote: and there's no decision yet if RANDNORMAL() etc should be implemented in sc or scaddins (or at all?). I'd prefer in sc. Yup, me too, FWIW. -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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: random number generators for calc
On 12/02/2012 04:06 PM, Markus Mohrhard wrote: On Sun, Dec 02, 2012 at 11:47:01AM +, tino wrote: 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? 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. Yes; please keep the sal interface as small and simple as possible. Stephan ___ 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
On Sun, Dec 02, 2012 at 11:47:01AM +, tino wrote: ... 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?). Speed has to be nearly always a concern in calc core. We don't parse the cell formula for each evaluation. We have an intermediate format that is extremely fast to evaluate and we have to be very careful that we are not introducing more performance regressions. For a single cell this seems not important but on a sheet with thousand of depending cells it is quite important that a function is not slower than necessary. 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. Well in most cases the statistical properties of a random function will not matter in Libreoffice. I agree that it is different in Calc and seeing that the rand() function in Windows is suboptimal we should think about a solution for Calc's RANDOM function. 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? 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. Regards, Markus ___ 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
On 01/12/12 12:22, tino wrote: the header is sal/inc/rtl/random.h (which is apparently a C interface). Exactly, the C++ interface is missing. but that isn't really a problem, is it? using it is as simple as: static rtlRandomPool aPool = rtl_random_createPool(); sal_Int32 nRandom; rtl_random_getBytes(aPool, nRandom, sizeof(nRandom)); of course it doesn't have fancy features like ranges or non-uniform distribution... Also, the source doesn't have any comments to say what algorithm is implemented etc. Do you know? actually i don't know much about random numbers, except that C standard library implementations thereof may be of arbitrarily bad quality, so one shouldn't use them in portable code. i bet whatever rtlRandomPool uses is better than a worst case rand() implementation, otherwise it wouldn't exist. but likely whatever fancy thing boost implements is better still, though it is unclear whether it is better in a way that makes a difference in practice (while apparently actual users do complain about rand()). ... 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... #define RTL_RANDOM_DIGEST rtl_Digest_AlgorithmMD5 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: well that looks reasonably simple; my concern is more that rtl/math.hxx is part of the stable URE interface so once something is added there it can't be removed, so better get the interface right if you want to add it there (also, you have to edit sal/util/sal.map file to get it exported which is annoying). does anybody have an opinion whether we want this functionality in rtl/math.hxx or not? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
On Sat, Dec 01, 2012 at 10:17:31PM +0100, Michael Stahl wrote: On 01/12/12 12:22, tino wrote: the header is sal/inc/rtl/random.h (which is apparently a C interface). Exactly, the C++ interface is missing. but that isn't really a problem, is it? using it is as simple as: static rtlRandomPool aPool = rtl_random_createPool(); sal_Int32 nRandom; rtl_random_getBytes(aPool, nRandom, sizeof(nRandom)); of course it doesn't have fancy features like ranges or non-uniform distribution... Also, the source doesn't have any comments to say what algorithm is implemented etc. Do you know? actually i don't know much about random numbers, except that C standard library implementations thereof may be of arbitrarily bad quality, so one shouldn't use them in portable code. i bet whatever rtlRandomPool uses is better than a worst case rand() implementation, otherwise it wouldn't exist. but likely whatever fancy thing boost implements is better still, though it is unclear whether it is better in a way that makes a difference in practice (while apparently actual users do complain about rand()). ... 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... #define RTL_RANDOM_DIGEST rtl_Digest_AlgorithmMD5 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: Personally I prefer to implement useful functions inside ScInterpreter and not in scaddins. Eike might have better comments for one or the other way. well that looks reasonably simple; my concern is more that rtl/math.hxx is part of the stable URE interface so once something is added there it can't be removed, so better get the interface right if you want to add it there (also, you have to edit sal/util/sal.map file to get it exported which is annoying). does anybody have an opinion whether we want this functionality in rtl/math.hxx or not? 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. ___ 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
Re: random number generators for calc
On 30/11/12 17:07, tino wrote: 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 newer versions of boost have desirable features then upgrading that is always an option, but that needs a lot of testing because of the wide variety of different compilers and versions thereof that are currently supposed to be able to build LO, and boosts tendency to use every obscure C++ feature... 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. the header is sal/inc/rtl/random.h (which is apparently a C interface). 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? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
Hi, On Wednesday, 2012-11-28 17:41:14 -0500, Kohei Yoshida wrote: On Wed, Nov 28, 2012 at 5:07 PM, tino ttk...@gmail.com wrote: Well, re-implementing the existing RAND and RANDBETWEEN with the new generator is no brainer. Btw, see the pointers I added to https://bugs.freedesktop.org/show_bug.cgi?id=33365#c13 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). Isn't boost::mt19937 somewhat overkill for the simple RAND() functions? 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? Ah ok. I think I mis-understood. Bear with me, as I'm not that versed with random number generation algorithms at the moment. Well, my position is that, since you know the subject matter very well, and if you think it's a useful addition then I'm with you. My only concern is that, we try to be compliant with ODF formula specification, and I'm not sure how adding a custom function (that only we understand) would affect that compliance and interoperability with other ODF generators. If we wrote such functions as, for example, ORG.LIBREOFFICE.RANDNORMAL we would be compliant, similar to other functions listed at http://wiki.documentfoundation.org/Development/ODF_Implementer_Notes#LibreOffice_OpenFormula_extensions Of course interoperability depends on other ODF readers' implementation. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpa69aCxKHh0.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
On 11/28/2012 05:41 PM, Kohei Yoshida wrote: 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? Ah ok. I think I mis-understood. Bear with me, as I'm not that versed with random number generation algorithms at the moment. Well, my position is that, since you know the subject matter very well, and if you think it's a useful addition then I'm with you. My only concern is that, we try to be compliant with ODF formula specification, and I'm not sure how adding a custom function (that only we understand) would affect that compliance and interoperability with other ODF generators. I still want to encourage adding new and useful functions; I just want to know what sort of things we need to be aware of when adding our own custom functions. Eike, do you have any insight on this? Kohei A few thoughts: Breaking ODF compatibility is probably a bad thing. I did not check, but I assume that the normal distribution is either specified or assumed for ODF. I assume that introducing new functions breaks ODF, or at least means that other systems that support ODF will not support what is done. As such, is there any way that random functions with different distributions can be implemented in an addin / extension? -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
On 11/29/2012 07:42 AM, Eike Rathke wrote: Hi, On Wednesday, 2012-11-28 17:41:14 -0500, Kohei Yoshida wrote: On Wed, Nov 28, 2012 at 5:07 PM, tino ttk...@gmail.com wrote: Well, re-implementing the existing RAND and RANDBETWEEN with the new generator is no brainer. Btw, see the pointers I added to https://bugs.freedesktop.org/show_bug.cgi?id=33365#c13 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). Isn't boost::mt19937 somewhat overkill for the simple RAND() functions? Well, again, I can't comment on the algorithm itself, but my reasoning is as follows. 1) Casual users of RAND probably don't really care the specifics of the algorithm used to generate random numbers. They will be just as happy with any algorithm as long as the numbers generated appear to be random enough for their casual use cases. 2) Advanced users of RAND will probably appreciate the new algorithm especially on Windows, since the Windows implementation of rand() is (based on the input we've received so far) quite bad. Advanced users on non-Windows platforms will hopefully be just as happy with the new algorithm as with the glibc one, if not happier. 3) It so happens that the algorithm used in boost is slightly faster than glibc's, which is an added bonus. 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? Ah ok. I think I mis-understood. Bear with me, as I'm not that versed with random number generation algorithms at the moment. Well, my position is that, since you know the subject matter very well, and if you think it's a useful addition then I'm with you. My only concern is that, we try to be compliant with ODF formula specification, and I'm not sure how adding a custom function (that only we understand) would affect that compliance and interoperability with other ODF generators. If we wrote such functions as, for example, ORG.LIBREOFFICE.RANDNORMAL we would be compliant, similar to other functions listed at http://wiki.documentfoundation.org/Development/ODF_Implementer_Notes#LibreOffice_OpenFormula_extensions Excellent! So we are at least safe as long as the functions are namespaced. Thanks for the pointer. Of course interoperability depends on other ODF readers' implementation. Yup, indeed. But at least this shouldn't limit ourselves from adding useful functions (if they are indeed useful and make sense as cell functions). Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
On 11/29/2012 09:12 AM, Andrew Douglas Pitonyak wrote: A few thoughts: Breaking ODF compatibility is probably a bad thing. I did not check, but I assume that the normal distribution is either specified or assumed for ODF. I checked, and I don't see any such assumption in the standard. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html#__RefHeading__1018560_715980110 I assume that introducing new functions breaks ODF, Not necessarily. As Eike pointed out, as long as the new functions are under our own namespace it doesn't break the standard. or at least means that other systems that support ODF will not support what is done. There is standard ODF and extended one that we support. We already have our own functions that are not yet in ODF proper, and IIRC gnumeric has their own. As with anything else that we do add to LibreOffice that's not yet specified in ODF (there are plenty of those), adding something new will always runs the risk of degrading interoperability, but IMO that's something we cannot avoid. What's important is if other ODF generators find the new idea useful, then we can work toward adding that to the standard later on. As such, is there any way that random functions with different distributions can be implemented in an addin / extension? We could add it to scaddins rather than sc, in which case we will probably namespace it under ORG.LIBREOFFICE. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: random number generators for calc
Hi, On Thursday, 2012-11-29 10:15:22 -0500, Kohei Yoshida wrote: On 11/29/2012 07:42 AM, Eike Rathke wrote: 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 :-) Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpverRms0kI0.pgp Description: PGP signature ___ 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
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
On 11/28/2012 09:17 AM, tino wrote: 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? 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. Or, is boost's random number generator better than our own? Does anyone know? Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ 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
On 11/28/2012 01:00 PM, tino wrote: 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. (...) 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. 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. I don't see the need to replace it for Linux if it's not broken. OTOH, making this platform-dependent may make the maintenance a bit more difficult. Especially when the behavior of the random number generator changes between platforms it may have an undesirable effect. Having said that, since we are talking about random numbers, having slightly different behaviors between platforms may not be such a big issue. I don't really have any preferences for one over the other. But I do like to see this problem solved especially on Windows. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ 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
On 11/28/2012 02:41 PM, tino wrote: 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. Yup, I agree with that. That's probably the better approach. It also turns out to be slightly faster than rand(). Good. This was my only concern toward use of boost's generator over glibc's. But now there is one less reason not to use boost's. 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. With boost this is simple so just a matter of extending the UNO interface. Well, these functions are implemented in the core interpreter in the sc module (ScInterpreter). Not scaddins. So, no UNO interface involved there. :-) Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ 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
Re: random number generators for calc
On Wed, Nov 28, 2012 at 5:07 PM, tino ttk...@gmail.com wrote: 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? Ah ok. I think I mis-understood. Bear with me, as I'm not that versed with random number generation algorithms at the moment. Well, my position is that, since you know the subject matter very well, and if you think it's a useful addition then I'm with you. My only concern is that, we try to be compliant with ODF formula specification, and I'm not sure how adding a custom function (that only we understand) would affect that compliance and interoperability with other ODF generators. I still want to encourage adding new and useful functions; I just want to know what sort of things we need to be aware of when adding our own custom functions. Eike, do you have any insight on this? Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
