[GitHub] commons-collections pull request: Add CollectionUtils#deepMerge me...
GitHub user kaching88 opened a pull request: https://github.com/apache/commons-collections/pull/12 Add CollectionUtils#deepMerge method. This method provides fast and convenient way to merge all deepest content in iterableOfiterablesOfiterables... etc. in one chosen collection. Method name is get from conventional Arrays.deep* methods but i am open to community suggestions. I also fixed some trivial mistakes in javadoc on CollectionUtils page. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kaching88/commons-collections deepMerge Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-collections/pull/12.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #12 commit 69524cebcc5283fa10b964672606b9ccaa0d73a7 Author: kaching88 Date: 2015-07-11T10:59:21Z Add CollectionUtils#deepMerge method. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[math] random boolean arrays
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). 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? Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] random boolean arrays
On 07/11/2015 09:08 PM, 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). 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? If it is just for testing purposes, you can also access the method in question via reflection, see an example here: http://stackoverflow.com/questions/34571/how-to-test-a-class-that-has-private-methods-fields-or-inner-classes Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] random boolean arrays
On 11 July 2015 at 20:29, Thomas Neidhart wrote: > On 07/11/2015 09:08 PM, 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). 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? > > If it is just for testing purposes, you can also access the method in > question via reflection, see an example here: > http://stackoverflow.com/questions/34571/how-to-test-a-class-that-has-private-methods-fields-or-inner-classes Or make it package-protected (with a comment saying why this was done) and create the unit test in the same package. If the tests really need to go in a different package, then add a public access method in the test class in the same package > Thomas > > - > 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
Re: [math] random boolean arrays
On 7/11/15 12:29 PM, Thomas Neidhart wrote: > On 07/11/2015 09:08 PM, 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). 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? > If it is just for testing purposes, you can also access the method in > question via reflection, see an example here: > http://stackoverflow.com/questions/34571/how-to-test-a-class-that-has-private-methods-fields-or-inner-classes Do you think it *should* be a private method of the K-S class? Phik > Thomas > > - > 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
Re: [math] random boolean arrays
How about a Randomize utility class? Cheers, - Ole On 07/11/2015 02:40 PM, sebb wrote: On 11 July 2015 at 20:29, Thomas Neidhart wrote: On 07/11/2015 09:08 PM, 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). 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? If it is just for testing purposes, you can also access the method in question via reflection, see an example here: http://stackoverflow.com/questions/34571/how-to-test-a-class-that-has-private-methods-fields-or-inner-classes Or make it package-protected (with a comment saying why this was done) and create the unit test in the same package. If the tests really need to go in a different package, then add a public access method in the test class in the same package Thomas - 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 . - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] random boolean arrays
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... 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 ? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] random boolean arrays
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. > >> 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
Re: [math] random boolean arrays
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.] [And I don't get the "copying to / from the stack"...] 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
Re: [math] random boolean arrays
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
