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?
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.