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
