Re: [Math] Review of "genetic algorithm" module
Hello.
Le lun. 28 févr. 2022 à 07:11, Avijit Basak a écrit :
>
> Hi All
>
> Please see my comments below.
>
> > [...]
> >I just had a very quick look.
> >IIUC, you always provide "convenience" methods (e.g. the various
> >signatures for the "evolve" functionality).
> >Prior to merging into "master", we should simplify and limit the
> >discussion to the core functionality, i.e. not try and make decisions
> >for the user (like default values, ...). Please keep the API as simple
> >as possible
> -- I have removed the mentioned evolve method.
> However, I had to catch two checked exceptions (InterruptedException,
> ExecutionException) and rethrow them. As of now I have handled them using
> the GeneticIllegalArgumentException. I think we need to introduce another
> exception class to handle this. Please share your thought regarding this.
I don't think that it's the right way to go; instantiating an "ExecutorService"
belongs to the GA application, not the GA library (whose relevant classes
need "only" be thread-safe).
There is some misunderstanding to be clarified in a dedicated discussion
(please file a new JIRA ticket).
Side note: Conflicts and duplicate commits have accumulated in the
dedicated "feature__MATH-1563__genetic_algorithm" branch.
I did not know how to proceed in order to avoid ending up with a messy
history in "master"; so I created a new branch (with the same name) with
all the new GA-related files added as a single commit.
Currently, this branch (based on your PR #205) fails the default goal,
because of a CheckStyle issue. You shoudl always check locally that
running "mvn" without arguments does not generate any errors.
I also noticed that classes in "examples-ga" use "forbidden" library
classes: "GeneticIllegalArgumentException" is an "internal" class; we
must not advertize such classes in the example applications.
In general, it seems that "examples-ga" contains several classes and
methods that do not need to be "public". This is especially true for
classes like "MathFunction" and "Coordinate". [Having those "private"
helps users to tell what is part of the library's functionality from what is
just "dummy" placeholder code.]
Finally (for now), I've just noticed that there exist several classes named
"MathFunction", with same implementation!
Code duplication must be avoided, especially where we purport to display
best practices.
The various "Standalone" classes also look quite similar; consolidating the
"examples-ga" module (including full Javadoc) is necessary. I still don't
understand why there are "...-legacy" modules in module "examples-ga".
If you want to offer the option of running the "old" implementation, you
could add a "legacy" flag (as "@Option" in the "Standalone" application).
Please use the new branch for all these ("cleanup") changes, as the basis
a PR (with a *single* commit). Thanks.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[numbers] GSoC 2022 - NUMBERS-186 Proposal
SUBJECT: A proposal for Commons numbers (NUMBERS-186) Hi Alex, I am Sumanth and new to Open source development. I would like to start by participating in GSOC 22. I came across your NUMBERS-186 GSOC mini project idea and took an initial stab at it If I understand the wish list correctly, we need to implement an efficient Complex List collection that supports all operations defined in the Complex class In my first attempt, I have implemented a ComplexList that is backed by two primitive double arrays for real and imaginary parts. The backing arrays grow as needed similar to the ArrayList implementation and supports all operations of the List interface I have added methods for operations from the Complex class with the following variations for each operation a) Operation for a single complex number at given index b) Operation for range of complex numbers with startIndex and length ComplexList applies all the operations in place modifying the backing arrays as per the requirement. I have also added support for an ImmutableComplexList that returns a copy of the List for each of the operations. My partial implementation (with TODOs for many operations) is available here. https://github.com/sumanth-rajkumar/commons-numbers/blob/sumanth-gsoc-22/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/ComplexList.java I would like to re-use the implementations from Complex class. For some of the simpler operations I exposed the private static methods from Complex class. However, in order to fully reuse all operations, the Complex class will require more refactoring... Am I on the right track? Will it be ok to refactor the Complex class to allow reuse of operation methods between Complex and ComplexList classes or should I just copy the implementations to List class? I have also added a sample unit test for ComplexList similar to the existing ComplexTest. Based on feedback, I plan to complete all the TODO implementations & comments, add full unit test coverage and any other tasks required to raise a PR Further, if there is interest, I also plan to extend the ComplexList for higher dimensions (2D, 3D, 4D etc..) -Sumanth [1] https://issues.apache.org/jira/browse/NUMBERS-186 [2] https://markmail.org/message/n4zpcxh7d7knq5tb?q=NUMBERS-186+list:org%2Eapache%2Ecommons%2Edev/ I have posted two ideas for GSoC mini projects under: > > https://issues.apache.org/jira/browse/STATISTICS-54 > https://issues.apache.org/jira/browse/NUMBERS-186 > > Alex > >
Re: [VOTE] Release Apache Commons Daemon 1.3.0 based on RC1
+1 It's a shame about the unhelpful release notes IMO. Tested with the Zip source: SHA512 OK, ASC OK. Built binaries on Windows. Built jars and site on macOS with Java 8. Microsoft Windows [Version 10.0.19042.1526] Microsoft (R) Program Maintenance Utility Version 14.29.30137.0 Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30137 for x64 Microsoft (R) Incremental Linker Version 14.29.30137.0 Gary On Fri, Mar 11, 2022 at 11:51 AM Mark Thomas wrote: > On 11/03/2022 13:37, Gary Gregory wrote: > > Hi Mark, > > > > Thank you for rolling a release candidate. > > > > The release notes should contain the changes not a link to part of a web > > site, > > The release notes have been this way since 2017. > > > and the link is broken too > > > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/site/changes-report.html > > That is because the web site is not part of the release and not part of > the release vote so it hasn't been uploaded to dist.a.o > > > If I download the zip or tar i should have the release notes right there. > > I'm not sure how you created the RC, but we normally generate the release > > notes from the changes.xml file through a Maven plugin. > > That isn't how Daemon has been set up. If you want to change this feel > free and we can pick up the change in the next RC (if there is one) or > the next release. > > I will note that: > > mvn deploy -Dcommons.release.isDistModule=true -Prelease > > didn't complete cleanly but didn't appear to affect the release > artifacts. I've now figured out that was due to MNG-7316 and I'll add an > note to HOW-TO-RELEASE.txt for future reference. > > Mark > > > > > Gary > > > > On Fri, Mar 11, 2022, 08:32 Mark Thomas wrote: > > > >> Since the 1.2.4 release, the minimum Java version has been updated to > >> Java 7 and a handful of bugs have been fixed so I would like to release > >> Apache Commons Daemon 1.3.0. > >> > >> Apache Commons Daemon 1.3.0 RC1 is available for review here: > >> https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1 > >> (svn revision 52984) > >> > >> The Git tag commons-daemon-1.3.0-RC1 commit for this RC is > >> 73708a0d774304cd4e02eb675fc599f42bc5e150 which you can browse here: > >> > >> > >> > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=73708a0d774304cd4e02eb675fc599f42bc5e150 > >> You may checkout this tag using: > >> git clone https://gitbox.apache.org/repos/asf/commons-daemon.git > >> --branch commons-daemon-1.3.0-RC1 commons-daemon-1.3.0-RC1 > >> > >> Maven artifacts are here: > >> > >> > >> > https://repository.apache.org/content/repositories/orgapachecommons-1579/commons-daemon/commons-daemon/1.3.0/ > >> > >> These are the artifacts and their hashes: > >> > >> #Release SHA-512s > >> > >> > commons-daemon-1.3.0.jar=748f3ac828feb9284b192e9c3f7d50cbe3c3bc101ba477a269070b296b9a3a69f626cd546bab45e7a24ac9b9503c01a56d7774192c16765b5995a96f8fc3c3e0 > >> > >> > commons-daemon-1.3.0-bin.tar.gz=53c1fee9bb14ae84034ec06e45693b86927493124fb050a598928884a985c54878710f63063e45b095469ffe45050ed87663de320df2140e0678642e21938592 > >> > >> > commons-daemon-1.3.0-bin.zip=cacc6d59b5baa9bd4c94da2ae1818d08d32cb25ddab6a21aa9e44e735b274cc78599c6342a3af34337152c3915e84055b28e4081e18b6c29e8cb73a604af4e70 > >> > >> > commons-daemon-1.3.0-bin-windows.zip=ff545f4b1c8a5f10b471e579e0b4c739e6e1f393f74f36ff35cfe62cced3febef20451b15b418e534c9e3640a9502e4c9da47a59e7ff3c772b439f8b8929f223 > >> > >> > commons-daemon-1.3.0-native-src.tar.gz=86588c1ce9e26a365235d8629137a6fea8b7bd1f4920063d620f7bf713e17bafc2fd152f46a52edd420d8090122dac4250a531e683b435948ae12462175807b4 > >> > >> > commons-daemon-1.3.0-native-src.zip=2732e26dd0e98867d01155bbcec8dc01810a4c573bc4eeb1ab398071428bafc698588238365e1436cc8ba9838735769637f43a899f51440b3112d7b42283bfb1 > >> > >> > commons-daemon-1.3.0-src.tar.gz=392ae1a4f36294c31f8f549c61bdf0a9fcd59a1e4eee3c54ceba30473066184271636b11ee6073526640c245d3f3a94d1d4d34413787c5b3323e6eedc7026816 > >> > >> > commons-daemon-1.3.0-src.zip=932d907ae51d59818f67d083fcd8f769b71644ac2d7af7131550b1abe729299a25bbada617cb418af4159006f2a3fc2cc44f8292e058ab6e1aa5b1072c1ffad1 > >> > >> Note the Windows binaries are also signed using the Digicert ONE code > >> signing service with the Commons PMC key. > >> > >> > >> Details of changes since 1.2.4 are in the release notes: > >> > >> > >> > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/RELEASE-NOTES.txt > >> > >> > >> > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/site/changes-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, > >> > >> Mark Thomas, > >> Release Manager (using key
Re: [geometry] PointMap and PointSet
Hello.
Le ven. 11 mars 2022 à 16:18, Matt Juntunen
a écrit :
>
> Hello,
>
> I recently posted a PR [1] for GEOMETRY-142 [2], which is for adding
> PointMap and PointSet implementations. These are Map and Set
> implementations specifically designed to use Points as keys.
Is there a gentle introduction to how it works and/or the intended
use cases?
> They
> support fuzzy key comparison, meaning that points do not have to be
> exactly equal to each other in order to be considered equal by the
> map/set. (Note that this means these types do not follow the strict
> Map/Set contracts since they are not consistent with equals. This is
> documented in the PointMap/PointSet javadocs.)
Does it entail issues about some use cases or applications that
need this functionality? Or do they not generally care about that
contract?
If so, maybe this collection shouldn't implement the standard JDK
interfaces (?).
> I've completely hidden
> the implementation details from the public API
Thanks.
> since I anticipate
> changes in the future with regard to the algorithms used.
Where does the anticipation come from?
> Instances
> are created through factory classes in each space. Ex:
>
> PointMap map = EuclideanCollections.pointMap3D(precision);
> PointSet set = SphericalCollections.pointSet2S(precision);
>
> Since fuzzy key comparison is used, I've added the following methods
> to the interfaces to allow access to the exact, "canonical" version of
> the key stored in the collection.
>
> PointMap {
> // return the key corresponding to pt, or null if not found
> P resolveKey(P pt);
>
> // return the map entry corresponding to pt, or null if not found
> Map.Entry resolveEntry(P pt);
> }
>
> PointSet {
> // return the key corresponding to pt, or null if not found
> P resolve(P pt);
> }
I don't quite follow; which are the corresponding "non-canonical"
accessors?
>
> Reviews and comments are welcome.
Is there a notion of neighbours (as in: return the "n" entries that
are closest to a given point)?
Regards,
Gilles
>
> Regards,
> Matt Juntunen
>
>
> [1] https://github.com/apache/commons-geometry/pull/194
> [2] https://issues.apache.org/jira/projects/GEOMETRY/issues/GEOMETRY-142
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
