random number generators for calc
kohei.yoshida at gmail.com
Thu Nov 29 07:15:22 PST 2012
On 11/29/2012 07:42 AM, Eike Rathke wrote:
> On Wednesday, 2012-11-28 17:41:14 -0500, Kohei Yoshida wrote:
>> On Wed, Nov 28, 2012 at 5:07 PM, tino <ttk448 at 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
>>> 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
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
Kohei Yoshida, LibreOffice hacker, Calc
More information about the LibreOffice