Yes it is going to not be exported of we do it. -viral On 15 Sep 2014 16:29, "Stefan Karpinski" <[email protected]> wrote:
> 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 >> > >> >> >
