Hey Tino,
2012/12/6 tino ttk...@gmail.com:
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
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:47:5:
Hey
2012/12/7 tino ttk...@gmail.com:
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
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 external
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 makes
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,
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 just a
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'd want
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
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 point
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
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
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 heavily
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 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
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
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
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 would
Hi,
On Wednesday, 2012-11-28 17:41:14 -0500, Kohei Yoshida wrote:
On Wed, Nov 28, 2012 at 5:07 PM, tino ttk...@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
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
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 ttk...@gmail.com wrote:
Well, re-implementing the existing RAND and RANDBETWEEN with the new
generator is no brainer.
Btw, see the pointers I
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.
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 bonus.
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 so header
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 implementation will be
straight forward. We
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
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
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
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 using
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
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 sure if we
On Wed, Nov 28, 2012 at 5:07 PM, tino ttk...@gmail.com 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
32 matches
Mail list logo
