random number generators for calc

[Kohei Yoshida]

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