Honestly this sounds like a horrible workaround for a DSFMT library design problem. If this is going to be scoped inside a DSFMT module then fine, it's a low-level API that is tied to a particular library and we have plenty of those. But as part of our high-level RNG API, yuck.
On Mon, Sep 15, 2014 at 6:50 AM, Viral Shah <[email protected]> wrote: > MersenneTwisterArray sounds like a good idea, separating it clearly from > the scalar version. Even the method names could be different to avoid any > confusion. > > -viral > > > > > On 15-Sep-2014, at 6:25 am, Andreas Noack <[email protected]> > wrote: > > > > The problem is that we cannot mix the calls to the scalar and array > generators. Maybe a solution could be to define a new MersenneTwisterArray > type that only has methods defined for arrays. > > > > Med venlig hilsen > > > > Andreas Noack > > > > 2014-09-14 10:21 GMT-04:00 <[email protected]>: > > I wonder if we should provide access to DSFMT's random array generation, > so that one can use an array generator. The requirements are that one has > to generate at least 384 random numbers at a time or more, and the size of > the array must necessarily be even. > > > > We should not allow this with the global seed, and it can be through a > randarray!() function. We can even avoid exporting this function by > default, since there are lots of conditions it needs, but it gives really > high performance. > > Are the conditions needed limited to n>384 and n even? > > > > Why not providing it by default then with a single if statement to check > for the n>384 condition? The n even condition is not really a problem as > Julia does not allocate the exact amount of data needed. Even for > fixed-size array, adding 1 extra element (not user accessible) does not > seem to be much of a drawback. > > > > > > > > -viral > > > >
