Hey tino,
>
> Attached patch is just a simple wrapper around boost, to be used like
>
> sc::rng::seed() to replace libc srand()
> sc::rng::rand() to replace libc rand()
I pushed this part of the patch.
>
> and a few more distributions.
I did not push them. As soon as we have users for them it m
Hi,
On Friday, 2012-12-07 17:04:52 +0100, Markus Mohrhard wrote:
> > Small problems:
> > - compiler warnings from within boost
>
> We need to patch them out otherwise the Werror build will fail. It
> seems that these warnings are also fixed upstream.
I'd rather prefer if we did not patch exter
Hey
2012/12/7 tino :
>> > Small problems:
>> > - compiler warnings from within boost
>>
>> We need to patch them out otherwise the Werror build will fail. It
>> seems that these warnings are also fixed upstream.
>
> This really confuses me. The warnings I'm getting are of the form
>
> ...boost/r
> > Small problems:
> > - compiler warnings from within boost
>
> We need to patch them out otherwise the Werror build will fail. It
> seems that these warnings are also fixed upstream.
This really confuses me. The warnings I'm getting are of the form
...boost/random/binomial_distribution.hpp:
Hey Tino,
2012/12/6 tino :
>> > just happened to reimplement RAND() with a B.A Wichmann
>> > and I.D Hill generator.. see
>>
>> As they are entitled to. No doubt we'll come up with a comprehensive,
>> nicely architected and beautiful solution of our own :-)
>
> Ok, I'll go ahead with a sugge
> > just happened to reimplement RAND() with a B.A Wichmann
> > and I.D Hill generator.. see
>
> As they are entitled to. No doubt we'll come up with a comprehensive,
> nicely architected and beautiful solution of our own :-)
Ok, I'll go ahead with a suggestion then. :)
Attached patch is j
On Wed, 2012-12-05 at 17:12 +0100, Eike Rathke wrote:
> just happened to reimplement RAND() with a B.A Wichmann
> and I.D Hill generator.. see
As they are entitled to. No doubt we'll come up with a comprehensive,
nicely architected and beautiful solution of our own :-)
ATB,
On 12/05/2012 11:29 AM, Eike Rathke wrote:
and there's no decision yet if RANDNORMAL() etc should be
implemented in sc or scaddins (or at all?).
I'd prefer in sc.
Yup, me too, FWIW.
--
Kohei Yoshida, LibreOffice hacker, Calc
___
LibreOffice mailin
Hi tino,
On Saturday, 2012-12-01 11:22:09 +, tino wrote:
> > 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
Hi,
On Thursday, 2012-11-29 13:42:00 +0100, 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 wrote:
> > > > Well, re-implementing the existing RAND and RANDBETWEEN with the new
> > > > generator is no brainer.
>
> Btw,
> > What about implementation in random.cxx and creating random.hxx so all
> > the random stuff is in one place?
>
> Why do you want this abstraction? Following KISS I would just start
> implementing the functions in ScInterpreter and extract commonly used
> parts into an own method. If at some po
On 12/02/2012 04:06 PM, Markus Mohrhard wrote:
On Sun, Dec 02, 2012 at 11:47:01AM +, tino wrote:
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.
What about imple
On Sun, Dec 02, 2012 at 11:47:01AM +, tino wrote:
>
> > ... 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
> of course it doesn't have fancy features like ranges or non-uniform
> distribution...
That's ok, I wouldn't use that against it, because these things are
independent. Any uniform int generator can easily be extended to
ranges, and uniform [0,1] distribution. And at least in theory, any
non-unifo
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:
>
>
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 nR
> the header is sal/inc/rtl/random.h (which is apparently a C interface).
Exactly, the C++ interface is missing. Also, the source doesn't have
any comments to say what algorithm is implemented etc. Do you know?
> but why do we need a wrapper around boost in sal? i mean i haven't
> looked at the
On 30/11/12 17:07, tino wrote:
> I've had a look at what Gnumeric offers, and they've done a big job on
> random number generation. Comparing with what is available in boost
> I've separated the list into rand functions which could be quickly
> implemented using boost and those which can't (and wou
I've had a look at what Gnumeric offers, and they've done a big job on
random number generation. Comparing with what is available in boost
I've separated the list into rand functions which could be quickly
implemented using boost and those which can't (and would require more
intelligence to impleme
> > >Isn't boost::mt19937 somewhat overkill for the simple RAND() functions?
> >
> > 3) It so happens that the algorithm used in boost is slightly faster
> > than glibc's, which is an added bonus.
>
> If that's the case then my objection is moot :-)
The only problem with boost is the thousand or
Hi,
On Thursday, 2012-11-29 10:15:22 -0500, Kohei Yoshida wrote:
> On 11/29/2012 07:42 AM, Eike Rathke wrote:
> >Isn't boost::mt19937 somewhat overkill for the simple RAND() functions?
>
> 3) It so happens that the algorithm used in boost is slightly faster
> than glibc's, which is an added bonu
On 11/29/2012 09:12 AM, Andrew Douglas Pitonyak wrote:
A few thoughts:
Breaking ODF compatibility is probably a bad thing. I did not check, but
I assume that the normal distribution is either specified or assumed for
ODF.
I checked, and I don't see any such assumption in the standard.
http://
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 wrote:
Well, re-implementing the existing RAND and RANDBETWEEN with the new
generator is no brainer.
Btw, see the pointers I added to
https://bu
On 11/28/2012 05:41 PM, Kohei Yoshida wrote:
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). Yet both are simple
uniform distributions but the
Hi,
On Wednesday, 2012-11-28 17:41:14 -0500, Kohei Yoshida wrote:
> On Wed, Nov 28, 2012 at 5:07 PM, tino 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
On Wed, Nov 28, 2012 at 5:07 PM, tino wrote:
> > >What is your opinion on implementing generators for other
> > >distributions like normal and all the ones listed under statistics
> > >(which calculate densities but don't generate)?
> >
> > Well, re-implementing the existing RAND and RANDBETWEEN
> >What is your opinion on implementing generators for other
> >distributions like normal and all the ones listed under statistics
> >(which calculate densities but don't generate)?
>
> Well, re-implementing the existing RAND and RANDBETWEEN with the new
> generator is no brainer. But I'm not sur
On 11/28/2012 02:41 PM, tino wrote:
Thanks for the additional insight. Well, I can see two possibilities:
1) Use boost's generator for Windows platform-only, while we keep
the glibc's version for Linux. I wonder what the situation is on
Mac...
2) Use boost's generator for all platforms.
If
> Thanks for the additional insight. Well, I can see two possibilities:
>
> 1) Use boost's generator for Windows platform-only, while we keep
> the glibc's version for Linux. I wonder what the situation is on
> Mac...
>
> 2) Use boost's generator for all platforms.
If there are no issues with
On 11/28/2012 01:00 PM, tino wrote:
So, Michael Stahl commented in the bug that we do have our own
random number generator function. One way is to just replace the
direct call to rand() to this function instead. That should be very
easy to do and I have no objection against it.
Just to be cle
> So, Michael Stahl commented in the bug that we do have our own
> random number generator function. One way is to just replace the
> direct call to rand() to this function instead. That should be very
> easy to do and I have no objection against it.
Just to be clear, I believe glibc's implement
On 11/28/2012 09:17 AM, tino wrote:
Hi,
There are currently only uniform random number generators available in
calc, namely RAND() and RANDBETWEEN(...). I'd be interested in
generators for other distributions, like normal, exponential etc.
I'd suggest using boost/random.hpp and then implementat
32 matches
Mail list logo
