Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library

[Avijit Basak]

Hi All

I have started to work in genetic module. I want to push the new
module as part of a new feature branch "*feature/MATH-1563*". Changes
include mostly the existing code and modfication due to the new Exception
class. I have encountered the following error which indicates my Github Id "
*avijitbasak*" is not permitted to check-in code in the repository. Could
anyone kindly grant me access to the repository. Let me know if I need to
do anything else regarding this.

git.exe push --progress "origin" feature/MATH-1563
remote: Permission to apache/commons-math.git denied to avijitbasak.
fatal: unable to access '*https://github.com/apache/commons-math.git/
*': The requested URL returned
error: *403*

Thanks & Regards
--Avijit Basak

On Sun, 8 Aug 2021 at 10:49, Avijit Basak  wrote:

> Hi
>
>  I have created two new subtasks for Jira *MATH-1563* to explain
> the requirement of changes and a new JIRA MATH-1618
> .
>   Let me know if that helps. We can continue the discussion here
> in case of any queries.
>
> Thanks & Regards
> --Avijit Basak
>
> On Wed, 28 Jul 2021 at 23:22, Gilles Sadowski 
> wrote:
>
>> Hello.
>>
>> Le mer. 28 juil. 2021 à 10:23, Avijit Basak  a
>> écrit :
>> >
>> > Hi
>> >
>> > I shall try to describe my proposed changes with proper context
>> in
>> > my next communication. Regarding the stats, I need a library that can be
>> > used for any statistical calculation needed.
>>
>> Are the calculations needed for the GA to work (e.g. as part of a stopping
>> criterion), or are they only meant to inform the user (e.g. for computing
>> current average fitness and the like)?
>>
>> In the latter case, (IIUC) I don't think that we need to introduce such a
>> dependency: Couldn't "out-of-band" functionality be defined through a
>> plugin infrastructure?
>>
>> > I don't want to use the one
>> > from math3 legacy component as that will include all other legacy
>> > components too.
>>
>> If you intend to improve the "genetics" package within the current
>> "commons-math-legacy" module, you can use all the code in there,
>> (including the "o.a.c.math4.stat" package, although that will make it
>> more difficult to create a new module free of those dependencies.
>>
>> Please clarify what goal you are pursuing.
>>
>> > If the commons-statistics component is an isolated one then
>> > that can be re-used once released.
>>
>> I don't understand what you mean.
>>
>> > It will be nice to have a library for plotting graph. Earlier I
>> > used jFreeChart (Lesser GNU Public License), which works fine for this
>> kind
>> > of requirement. Any suggestion regarding this?
>>
>> If you suggest that a Commons component should depend on
>> a plotting library, it's likely "no go".
>> Would a GA implementation need this?
>> Again, if the purpose is to follow progress of the computation, we
>> should define appropriate interfaces to allow data collection in
>> real time.  How those are processed (e.g. plotting statistics of the
>> current population) is probably out-of-scope.
>>
>> Regards,
>> Gilles
>>
>> >
>> > Thanks & Regards
>> > --Avijit Basak
>> >
>> >
>> > On Tue, 27 Jul 2021 at 19:33, Gilles Sadowski 
>> wrote:
>> >
>> > > Hello.
>> > >
>> > > Le mar. 27 juil. 2021 à 09:15, Avijit Basak 
>> a
>> > > écrit :
>> > > >
>> > > > Hi All
>> > > >
>> > > > Please find the proposed changes for the Genetic Algorithm
>> > > library in commons.maths.
>> > > > Changes in Model:
>> > > > 1) GeneticAlgorithm class is broken into a hierarchy to accommodate
>> > > commons implementation in an Abstract class AbstractGeneticAlgorithm.
>> New
>> > > AdaptiveGeneticAlgorithm class has also been introduced.
>> > > > 2) Introduced Elitism interface which is implemented by
>> > > ElitisticListPopulation.
>> > > > 3) Interface Fitness has been removed.
>> > > > 4) Interface FitnessCalculator has been introduced.
>> > > > 5) Chromosome has been updated with FitnessCalculator interface and
>> > > accessor.
>> > > > 6) Operations in AbstractChromosome has been updated with
>> > > FitnessCalculator as interface.
>> > > > 7) New BinaryChromosome class has been added.
>> > > > 8) Interface PermutationChromosome has been replaced by
>> > > IndirectlyEncodedChromosome as the interface primarily represents
>> > > chromosomes with indirect encoding. A more appropriate name can be
>> > > suggested.
>> > > > 9) RandomKey class operations have been updated with
>> FitnessCalculator.
>> > > > 10) I would like to include a new class PermutationChromosome as we
>> have
>> > > corresponding crossover operators like OrderedCrossover.
>> > > > 11) crossover method in CrossoverPolicy interface has been updated
>> with
>> > > additional argument probability to support dynamic probability
>> generation.
>> > > This would impact all implementation classes.
>> > > > 12) mutate method in MutationPolicy has been added 

Re: [MATH][DESIGN] Design Discussion for Genetic Algorithm Library

[Avijit Basak]

Hi

 I have created two new subtasks for Jira *MATH-1563* to explain
the requirement of changes and a new JIRA MATH-1618
.
  Let me know if that helps. We can continue the discussion here in
case of any queries.

Thanks & Regards
--Avijit Basak

On Wed, 28 Jul 2021 at 23:22, Gilles Sadowski  wrote:

> Hello.
>
> Le mer. 28 juil. 2021 à 10:23, Avijit Basak  a
> écrit :
> >
> > Hi
> >
> > I shall try to describe my proposed changes with proper context
> in
> > my next communication. Regarding the stats, I need a library that can be
> > used for any statistical calculation needed.
>
> Are the calculations needed for the GA to work (e.g. as part of a stopping
> criterion), or are they only meant to inform the user (e.g. for computing
> current average fitness and the like)?
>
> In the latter case, (IIUC) I don't think that we need to introduce such a
> dependency: Couldn't "out-of-band" functionality be defined through a
> plugin infrastructure?
>
> > I don't want to use the one
> > from math3 legacy component as that will include all other legacy
> > components too.
>
> If you intend to improve the "genetics" package within the current
> "commons-math-legacy" module, you can use all the code in there,
> (including the "o.a.c.math4.stat" package, although that will make it
> more difficult to create a new module free of those dependencies.
>
> Please clarify what goal you are pursuing.
>
> > If the commons-statistics component is an isolated one then
> > that can be re-used once released.
>
> I don't understand what you mean.
>
> > It will be nice to have a library for plotting graph. Earlier I
> > used jFreeChart (Lesser GNU Public License), which works fine for this
> kind
> > of requirement. Any suggestion regarding this?
>
> If you suggest that a Commons component should depend on
> a plotting library, it's likely "no go".
> Would a GA implementation need this?
> Again, if the purpose is to follow progress of the computation, we
> should define appropriate interfaces to allow data collection in
> real time.  How those are processed (e.g. plotting statistics of the
> current population) is probably out-of-scope.
>
> Regards,
> Gilles
>
> >
> > Thanks & Regards
> > --Avijit Basak
> >
> >
> > On Tue, 27 Jul 2021 at 19:33, Gilles Sadowski 
> wrote:
> >
> > > Hello.
> > >
> > > Le mar. 27 juil. 2021 à 09:15, Avijit Basak  a
> > > écrit :
> > > >
> > > > Hi All
> > > >
> > > > Please find the proposed changes for the Genetic Algorithm
> > > library in commons.maths.
> > > > Changes in Model:
> > > > 1) GeneticAlgorithm class is broken into a hierarchy to accommodate
> > > commons implementation in an Abstract class AbstractGeneticAlgorithm.
> New
> > > AdaptiveGeneticAlgorithm class has also been introduced.
> > > > 2) Introduced Elitism interface which is implemented by
> > > ElitisticListPopulation.
> > > > 3) Interface Fitness has been removed.
> > > > 4) Interface FitnessCalculator has been introduced.
> > > > 5) Chromosome has been updated with FitnessCalculator interface and
> > > accessor.
> > > > 6) Operations in AbstractChromosome has been updated with
> > > FitnessCalculator as interface.
> > > > 7) New BinaryChromosome class has been added.
> > > > 8) Interface PermutationChromosome has been replaced by
> > > IndirectlyEncodedChromosome as the interface primarily represents
> > > chromosomes with indirect encoding. A more appropriate name can be
> > > suggested.
> > > > 9) RandomKey class operations have been updated with
> FitnessCalculator.
> > > > 10) I would like to include a new class PermutationChromosome as we
> have
> > > corresponding crossover operators like OrderedCrossover.
> > > > 11) crossover method in CrossoverPolicy interface has been updated
> with
> > > additional argument probability to support dynamic probability
> generation.
> > > This would impact all implementation classes.
> > > > 12) mutate method in MutationPolicy has been added another argument
> > > probability to support dynamic probability generation. This would
> impact
> > > all implementation classes.
> > > > 13) Two new evolution StoppingCondition has been added
> > > UnchangedAvgFitness and UnchangedBestFitness.
> > > > 14) An interface ProbabilityGenerator has been introduced with few
> > > selective implementations to be used by AdaptiveGeneticAlgorithm
> class. The
> > > signature of the probability generation method has been kept generic to
> > > keep strategies interchangeable.
> > >
> > > I'd have a hard time commenting as we mostly miss the context: AFAIK,
> > > nobody here has ever used CM's GA implementation and nobody knows
> > > how its design structure should be changed in order to improve its
> > >  * usability,
> > >  * performance,
> > >  * robustness,
> > >  * extensibility, or
> > >  * maintenance;
> > > hence the listing of changes is not very useful without some hint as
> to why
> > > things are to be 

Re: [Math] Repository cleanup

[Alex Herbert]

On Sat, 7 Aug 2021 at 15:48, Gilles Sadowski  wrote:

> Hi.
>
> There are many rotten branches in the repository.[1]
> Most are outdated (having been merged to "master" or
> having been used as a sandbox, a long time ago).
>
> I'd only keep those that
>   * were used for a release (obviously), or
>   * refer to issues not yet marked as resolved (e.g.
> "feature-MATH-1333").
>
> OK to delete[2] the following branches:
>   MATH-1153 [ y/n ]
>   complex-and-primitive-arrays [ y/n ]
>   develop [ y/n ]
>   feature-MATH-1290 [ y/n ]
>   feature-MATH-1372 [ y/n ]
>   feature-MATH-1416 [ y/n ]
>   field-ode [ y/n ]
>   fix-math-1342 [ y/n ]
>   h10-builds [ y/n ]
>   master-old [ y/n ]
>   modularized_master [ y/n ]
>   task-MATH-1366 [ y/n ]
> ?
>

If the branches have no current (or future) work planned on them then they
won't be missed. I'm fine with deleting them.

Alex

JDK 17 is now in the Release Candidate Phase

[Rory O'Donnell]

Hi Benedikt,

*Per the JDK 17 schedule , we are now in the Release Candidate Phase 
[1][2].*


*
*

*Please advise if you find any issues while testing the latest Early 
Access builds.*


 * Schedule:
 o *2021/08/05   Initial Release Candidate *
 o 2021/08/19    Final Release Candidate
 o 2021/09/14    General Availability


The overall feature set is frozen. No further JEPs will be targeted to 
this release.


 * Features integrated in JDK 17:

 o JEP 306: Restore Always-Strict Floating-Point Semantics
   
 o JEP 356: Enhanced Pseudo-Random Number Generators
   
 o JEP 382: New macOS Rendering Pipeline
   
 o JEP 391: macOS/AArch64 Port 
 o JEP 398: Deprecate the Applet API for Removal
   
 o JEP 403: Strongly Encapsulate JDK Internals
   
 o JEP 406: Pattern Matching for switch (Preview)
   
 o JEP 407: Remove RMI Activation 
 o JEP 409: Sealed Classes 
 o JEP 410: Remove the Experimental AOT and JIT Compiler
   
 o JEP 411: Deprecate the Security Manager for Removal
   
 o JEP 412: Foreign Function & Memory API (Incubator)
   
 o JEP 414: Vector API (Second Incubator)
   
 o JEP 415: Context-Specific Deserialization Filters
   

*
*

*OpenJDK 17 Early Accessbuild 35 is available at 
**https://jdk.java.net/17* 


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 
 * Release Notes are available at https://jdk.java.net/17/release-notes
   
 * Changes in recent builds that maybe of interest:
 o JDK-8270866: NPE in DocTreePath.getTreePath()[build 33]
 + Reportedby jOOQ

**Topics of Interest: *
*

 * The latest Newscast covers 17's JEP 356
   : Enhanced Pseudo-Random Number
   Generators - Here
   
 * The latest JEP Café cover 17's JEP 409
    : Sealed Classes - Here
   
 * A few updates to JEP 411 :
   Deprecate the Security Manager for Removal - Here
   

*
*

*OpenJDK**18 Early Access build 9 is available at 
**https://jdk.java.net/18* 


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 
 * Release Notes are available at https://jdk.java.net/18/release-notes
   
 * Changes in recent builds that maybe of interest:
 o JDK-8225082: Remove IdenTrust certificate that is expiring in
   September 2021 [build 9]
 o JDK-8251329: Zip File System Provider Throws ZipException when
   entry name element contains "." or ".." [build 9]
 o JDK-8271359: NPE in DocTreePath.getTreePath() [build 8]
 + Reported by jOOQ

*July 2021 Critical Patch Update Released*

 * As part of the July 2021, we released JDK 16.0.2, JDK 11.0.12 LTS,
   JDK 8u301 and JDK 7u311 as well as OpenJDK 16.0.2 (publicly available)


Rgds,Rory

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-August/005894.html
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-August/005906.html

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

[Math] Repository cleanup

[Gilles Sadowski]

Hi.

There are many rotten branches in the repository.[1]
Most are outdated (having been merged to "master" or
having been used as a sandbox, a long time ago).

I'd only keep those that
  * were used for a release (obviously), or
  * refer to issues not yet marked as resolved (e.g.
"feature-MATH-1333").

OK to delete[2] the following branches:
  MATH-1153 [ y/n ]
  complex-and-primitive-arrays [ y/n ]
  develop [ y/n ]
  feature-MATH-1290 [ y/n ]
  feature-MATH-1372 [ y/n ]
  feature-MATH-1416 [ y/n ]
  field-ode [ y/n ]
  fix-math-1342 [ y/n ]
  h10-builds [ y/n ]
  master-old [ y/n ]
  modularized_master [ y/n ]
  task-MATH-1366 [ y/n ]
?

Gilles

[1] This suggestion is a rehash of
https://markmail.org/message/wtuvaij74agbrm2l
[2] git push origin --delete branch_name

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org