random number generators for calc

Michael Stahl mstahl at redhat.com
Sat Dec 1 13:17:31 PST 2012

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

> 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?

More information about the LibreOffice mailing list