On 7/11/15 3:38 PM, Gilles wrote: > On Sat, 11 Jul 2015 15:12:29 -0700, Phil Steitz wrote: >> On 7/11/15 3:06 PM, Gilles wrote: >>> On Sat, 11 Jul 2015 12:08:16 -0700, Phil Steitz wrote: >>>> The code implemented in MATH-1242 to improve performance of KS >>>> monteCarloP in-lines efficient generation of random boolean >>>> arrays. >>>> Unfortunately, I think the implementation is not quite random >>>> (see >>>> comments on the ticket). To verify it, we need to be able to test >>>> the random boolean array generation directly. To do that, we have >>>> to either expose the method (at least as protected) in the KS >>>> class >>>> or add it somewhere else. I propose the latter but am not sure >>>> where to put it. For speed, we need to avoid array copies, so the >>>> API will have to be something like randomize(boolean[], nTrue). >>> >>> Are you sure that copying is an issue for speed? >>> I mean, the randomization will anyways copy new values into the >>> array... >> >> The algorithm is used in a tight loop that would be slowed down >> considerably by allocating and copying arrays to / from the stack. > > Numbers? > IIRC, someone said: "First make it correct, then make it faster (if > necessary)". [I.e. the computation may always be inlined later.]
This is part of an optimization. It replaces a much slower implementation that did a lot more copying of data. > > [And I don't get the "copying to / from the stack"...] Yeah, that's not the issue. It's all the allocations and garbage collection that would slow things down. Phil > > Gilles > >>>> It >>>> could go in the swelling MathArrays class, or RandomDataGenerator. >>>> The latter probably makes more sense, but the API does not fit too >>>> well. Any ideas? >>> >>> Isn't there some relationship with >>> https://issues.apache.org/jira/browse/MATH-1158 >>> ? >> >> No. >> >> Phil >>> >>> >>> Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
