[Math] Please review GA implementation
Hello. I've just created a "feature__MATH-1563__genetic_algorithm" branch[1] in the git repository, with the code provided by Avijit Basak in PR #200, a proposed replacement of the "o.a.c.math4.legacy.genetics" package.[2] Reviews welcome. Regards, Gilles [1] https://gitbox.apache.org/repos/asf?p=commons-math.git;a=shortlog;h=refs/heads/feature__MATH-1563__genetic_algorithm [2] https://issues.apache.org/jira/browse/MATH-1563 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
> Am 03.01.2022 um 18:24 schrieb Thomas Vandahl : > > Hi folks, > > We have fixed quite a few bugs and added some significant enhancements since > Apache Commons JCS 3.0 was released, so I would like to release Apache > Commons JCS 3.1. > > [X] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... My vote. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi folks, We have fixed quite a few bugs and added some significant enhancements since Apache Commons JCS 3.0 was released, so I would like to release Apache Commons JCS 3.1. Note that, although the core library of Log4j is an optional dependency to commons-jcs, we have addressed CVE-2021-44228 by updating log4j-api and log4j-core to version 2.17.1. Apache Commons JCS 3.1 rc2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2 (svn revision 51880) The Git tag commons-jcs3-3.1-rc2 commit for this RC is 5cd1ad02a8ddd196c9594fbb208d708440f87734 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=5cd1ad02a8ddd196c9594fbb208d708440f87734 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch commons-jcs3-3.1-rc2 commons-jcs3-3.1-rc2 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/commons-jcs3/3.1/ These are the distribution artifacts and their hashes: commons-jcs3-dist-3.1-bin.tar.gz 2d64ec75177934524353adcc7cccb92b05b4a5b6014f75b10f16dae2265954da0c0f4c0eb68013fee71d4ec53a49b02f7689de5fce6ff34ae90cd83705a56362 commons-jcs3-dist-3.1-bin.zip cba57f84ce1e0654239b0ea72663c166e47cf582c0ffc4a2743fd583d35eabbbcb03576fb1aac3e425a48a5b55068c554ab13b3b210a4d50151f62fa9e79894c commons-jcs3-dist-3.1-src.tar.gz d76daa3e8449e711e91e3f3ec73dc00b212d10db28f0f9a726c4df35bb9578cc1649ee8c5f20159f8cda0f58c569fa5821c3736a3f65fc03cfff74da200b790d commons-jcs3-dist-3.1-src.zip 1990533137ca75dbbfa702bb8dedb680e2f6d96d301cf263794d96da845c2c72072c1e84b6e50b7dd0588f96fd9512be0d7a61cd08463f1e01044a55a75b0ed5 I have tested this with ***'mvn clean verify site site:stage'*** using: Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Java version: 1.8.0_311, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_311.jdk/Contents/Home/jre Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" Details of changes since 3.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/index.html (note some *relative* links are broken and the 3.1 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 3.0): https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/commons-jcs3-core/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/commons-jcs3-core/rat-report.html KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner that 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, Thomas Vandahl (tv), Release Manager (using key 88817402) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH][GENETICS][PR-199] Decision on use and customization of RNG functionality for randomization
Hi All Please see my comments below. >> >As I've already indicated, "ThreadLocalRandomSource" is, IMHO, a >> >sort of workaround for a multi-thread application that does not want >> >to bother managing per-thread RNG instance(s). >> -- I am not clear on this. ThreadLocalRandomSource maintains >> an EnumMap>. What is meant >> by it "does not want to bother managing per-thread RNG instance(s)" Could >>> you please elaborate more on this. If this is an issue in RNG why don't we >>> think of fixing the same or providing a different internal implementation. >There is no issue in "Commons RNG"; it provides a tool. >I think that it is not the right tool for a multi-threaded GA library. --If we try to avoid use of ThreadLocalRandomSource, it will introduce threadlocal objects for each GA operator, which are currently immutable. Is that acceptable? In my opinion that is not the right design. > >> >The library should not make that decision for the application since we >> >can care for both usages: Every piece of the GA that needs a RNG can >> >provide factory methods that either take a "RandomSource" argument >> >or create a default one. >> -- Library can always use a default option or provide an option for >> customization at a global level but it need not be at the operator >> level(IMHO). >How can a GA operator work without a RNG? >It can't; it is one of the main settings of such an operator, and the >reason it should be customizable. -- Indeed GA operators cannot work without RNG. We can definitely customize the same and keep the user provided instance of RandomSource as a final reference variable. Then ThreadLocalRandomSource can use the same. >> I don't see much use of it. >That's OK; that's why I proposed for this kind a use a way to >generate a default instance, without any burden for the caller. --Default instance should always be there. > > > > >> >2. Less/no flexibility (no user's choice of random source). > > >> -- Agreed. > > -- Do we really need this much flexibility here? > > >My main concern is that IMO the RNG is a prominent part of a GA > >and it is not a good design to use "ThreadLocalRandomSource". > -- RNG is definitely a prominent part. However, if we have a sharing issue > with ThreadLocalRandomSource we need to think of it's alternate > implementation. >There is a misunderstanding; there is no sharing issue, there is >a design issue. > >How many is "too many instances"? > >The memory used by an operator is tiny compared to a chromosome, > >even less to a population of chromosome, or two populations of them > >(parents and offsprings). > --My concern is we are trying to provide a fix for a performance problem in > another library and that is going to consume additional memory. >Nothing (at all) that we should be worried (and discussing further): >Most RNG implementations are quite lean (a few hundred bytes to >a few KB). You multiply this by the number of threads (a few tens >at most), and you are well below 1 MB. What is this amount when >compared to the average Java application nowadays? -- This is not about the RNG implementation. If we don't use ThreadLocalRandomSource then we need to introduce threadlocal instances for our GA operators. A deep copy option should also be needed for them. Let me know if you have any separate thoughts. > > So I think we have a design tradeoff here performance vs memory > > consumption. I am more worried about memory as that might restrict use of > > this library beyond a certain number of dimensions in some areas. > > >I'm referring to separate copies for each thread. > >How many threads/virtual CPUs are common nowadays? > >> However, > >> creating deep copy would only be possible when we strictly restrict > >> extension of operators which I want to avoid. > > >How to avoid deep copies in a multi-thread library? > >Through synchronization? > -- The operator interfaces are designed like a functional interface. > Accordingly, the current implementation of all operators are read only. The > implementation does not maintain any mutable properties during computations > too. So they are perfectly suitable for multi-threaded operation. Great! > If you > see any deviation to it please notify me. Sure. Sorry I did not have the time to look into the code yet. --I have created a fresh repository and a new PR. Kindly go through it. It will be easier to discuss it once we are on the same page. > > > > >> So even if we provide > > >> the customization at the operator level we cannot avoid sharing. > > > > >We can, and we should. > > >What we probably can't avoid sharing is the instance that represents the > > >population of chromosomes. > > *--* In a multi-threaded optimization the chromosome instances are shared > > in case the same chromosome is chosen for crossover by the selection > > process. I missed this point earlier. > > ... > > Chromosomes can be shared (if they are read-only). > --They are read-only. >And immutable? --Yes they
Re: [commons-jcs] branch release-3.1 updated: Update release notes
IMO, you'll want to highlight the Log4j update in the announcement email. Gary On Mon, Jan 3, 2022 at 9:07 AM wrote: > This is an automated email from the ASF dual-hosted git repository. > > tv pushed a commit to branch release-3.1 > in repository https://gitbox.apache.org/repos/asf/commons-jcs.git > > > The following commit(s) were added to refs/heads/release-3.1 by this push: > new 20326a4 Update release notes > 20326a4 is described below > > commit 20326a48f741a5f223d011d4b52502ae522b2c5f > Author: Thomas Vandahl > AuthorDate: Mon Jan 3 15:06:55 2022 +0100 > > Update release notes > --- > RELEASE-NOTES.txt | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/RELEASE-NOTES.txt b/RELEASE-NOTES.txt > index 0a3e544..dada678 100644 > --- a/RELEASE-NOTES.txt > +++ b/RELEASE-NOTES.txt > @@ -41,6 +41,8 @@ o Add BlockDiskKeyStore.isEmpty(). Thanks to > Gary Gregory. > o Add IndexedDisk.isEmpty(). Thanks to Gary Gregory. > > Fixed Bugs: > +o Use new SecureRandom() instead of > SecureRandom.getStrongInstance() to > +avoid potential performance problems on Linux Thanks to Bruno > Kinoshita. > o JCS-228: Attempt to fix osgi import packages Thanks to Patrick Ziegler. > o JCS-191: Fix for Server Failover mechanism not working, add test > Thanks to Prajakta Uplaikar. > o JCS-186: Use configured listener address for UDP service broadcast > Thanks to Alex L. > @@ -48,7 +50,7 @@ o JCS-186: Fix UDP service discovery with LateralCache > Thanks to Alex L. > o Fix shutdown race conditions > > Changes: > -o Update from Apache Log4j 2.15.0 to 2.17.0 Thanks to Gary > Gregory. > +o Update from Apache Log4j 2.14.1 to 2.17.1 Thanks to Gary > Gregory. > o Autodetect lateral service address on the interface used for > multicast - > depending on the multicast protocol: > IPv6 link-local address for IPv6 multicast, > @@ -69,7 +71,7 @@ o Update from Apache Commons Lang 3.10 to > 3.12.0. Thanks to Gary Grego > o Bump build actions/setup-java from v1.4.3 to v2. Thanks to > Gary Gregory. > o Update from Apache Commons IO 2.8.0 to 2.10.0, #72. Thanks to > Gary Gregory, Dependabot. > o Bump actions/cache from 2.1.5 to 2.1.6 #70. Thanks to > Dependabot. > -o Bump log4j-api from 2.13.2 to 2.17.0 #79. Thanks to > Dependabot. > +o Bump log4j-api from 2.13.2 to 2.17.1 #79, #81. Thanks to > Dependabot. > > Removed: > o Remove support for long deprecated and inconsistent >
