[jira] [Resolved] (MATH-1621) "PointValuePair" equality
[
https://issues.apache.org/jira/browse/MATH-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved MATH-1621.
---
Resolution: Fixed
Commit b5d21665ff0c3a420564537cd1da88c8f77ab5a5 ("master" branch).
> "PointValuePair" equality
> -
>
> Key: MATH-1621
> URL: https://issues.apache.org/jira/browse/MATH-1621
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Major
> Fix For: 4.0
>
>
> Class {{PointValuePair}} (in package {{o.a.c.m.legacy.optim}}) is missing an
> override of method {{equals(Object)}}.
> The behaviour inherited from class {{Pair}} entails that numerically equal
> values fail the equality check (because references are compared).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MATH-1466) CMAES Optimization Fails to find Actual Optimum if Solution Value is Negative
[
https://issues.apache.org/jira/browse/MATH-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved MATH-1466.
---
Resolution: Cannot Reproduce
> CMAES Optimization Fails to find Actual Optimum if Solution Value is Negative
> -
>
> Key: MATH-1466
> URL: https://issues.apache.org/jira/browse/MATH-1466
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Rebecca
>Priority: Major
> Labels: Optimization
>
> Class CMAESOptimizer
> ([java.lang.Object|http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html?is-external=true]
> [org.apache.commons.math3.optim.BaseOptimizer|http://commons.apache.org/proper/commons-math/javadocs/api-3.4/org/apache/commons/math3/optim/BaseOptimizer.html]
> [org.apache.commons.math3.optim.BaseMultivariateOptimizer|http://commons.apache.org/proper/commons-math/javadocs/api-3.4/org/apache/commons/math3/optim/BaseMultivariateOptimizer.html]<[PointValuePair|http://commons.apache.org/proper/commons-math/javadocs/api-3.4/org/apache/commons/math3/optim/PointValuePair.html]>
> [org.apache.commons.math3.optim.nonlinear.scalar.MultivariateOptimizer|http://commons.apache.org/proper/commons-math/javadocs/api-3.4/org/apache/commons/math3/optim/nonlinear/scalar/MultivariateOptimizer.html]
> org.apache.commons.math3.optim.nonlinear.scalar.noderiv.CMAESOptimizer)
> I cannot provide code as I work for a private company with IP. However, my
> tests indicate that if the we are minimizing a cost function, and the
> function's value is a negative value, the resulting solution is incorrect.
> For example, say I were minimizing y = x^2 - 100
> The solution should be x = 0, with a value of -100. However, this CMAES
> optimizer would find random solutions, like x = 3 or x = -2 (with solutions
> of -91 and -96 respectively).
> I used the BOBYQA solver, and it was able to find the solution of x = 0 with
> a value of y = -100. I tested y = x^2 + 100 and the CMAES solver was able to
> find a solution of x = 0, y = 100. I tested y = x^2 and the CMAES the CMAES
> solver was able to find a solution of x = 0, y = 0. I tested y = x^2 -1 and
> the CMAES solver was NOT able to find a solution of x = 0, y = -1.
> I know it is highly inconvenient, but if someone wants to take a look at my
> cost function I can try to get an NDA. I think this bug is reproducible
> without it. Feel free to contact me at
> [rwolk...@umich.edu|mailto:rwolk...@umich.edu] if more info is needed.
> I think it has to do with the following stop criteria, which ends early if
> the cost is negative:
> if (stopFitness != 0 && bestFitness < (isMinimize ? stopFitness :
> -stopFitness)) {
> break generationLoop;
> }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] coveralls edited a comment on pull request #161: Improve Travis CI build Performance
coveralls edited a comment on pull request #161: URL: https://github.com/apache/commons-imaging/pull/161#issuecomment-91926 [](https://coveralls.io/builds/42317857) Coverage remained the same at 76.725% when pulling **399f0ba7ca69d577381fc1084769e92519658081 on YunLemon:Modify_Travis_1** into **e6aa3ace5ddf3c5ebecf7c47a614c081755118c7 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jexl] coveralls edited a comment on pull request #61: Improve Travis CI build Performance
coveralls edited a comment on pull request #61: URL: https://github.com/apache/commons-jexl/pull/61#issuecomment-91127 [](https://coveralls.io/builds/42317849) Coverage increased (+0.03%) to 87.122% when pulling **490fcac30fef4f426a47b88cb8ce493f7cc806aa on YunLemon:Modify_Travis_1** into **570e3e4c470bbdca8579160f579593ef8b2acf3e on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] coveralls commented on pull request #217: Documentation nits
coveralls commented on pull request #217: URL: https://github.com/apache/commons-compress/pull/217#issuecomment-903162775 [](https://coveralls.io/builds/42316703) Coverage remained the same at 86.36% when pulling **ed8df128857f603b00843e8899e5af6bc04a7a59 on HelderMagalhaes:documentation-nits** into **da22ecf0fd91cdd5abd105692ff81ba40a5c27cf on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] HelderMagalhaes opened a new pull request #217: Documentation nits
HelderMagalhaes opened a new pull request #217: URL: https://github.com/apache/commons-compress/pull/217 Redid #199 (and implicitly #198 and #197) from scratch: * Now "rebased" on master as hinted by @garydgregory (on #199) * More squashed than previous as advised by @PeterAlfredLee (on #199) * A separate commit for whitespace as suggested by @bodewig ([follow-up](https://github.com/apache/commons-compress/pull/192#issuecomment-846393334) from #192) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1618: --- Description: *1) Creation of abstraction for GeneticAlgorithm*: In order to have different types of implementation for Genetic Algorithm like adaptive GA along with the existing one, we need to introduce an abstraction and a hierarchy of algorithm. AbstracttGeneticAlgorithm class needs to be implemented which would be extended by all other Algorithm class. This would also ease any future extension. Removed Components: None New Components: AbstractGeneticAlgorithm Affected Components: GeneticAlgorithm *2) Delegation of fitness calculation*: As per the current design Fitness interface is implemented by chromosome class, which forces implementation of fitness() method for any concrete chromosome. However this restricts the use of same concrete chromosome implementation to be reused for different problem domain. This inheritance based implementation should be replaced by composition. A new interface FitnessCalculator would be introduced. An instance of FitnessCalculator will be provided during creation of every concrete chromosome. This will enable reuse of concrete chromosome classes in different problem domain and hence improve extensibility and re-usability. This will require addition of an argument for each factory method and constructors. Removed Components: Fitness New Components: FitnessCalculator Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, RandomKey *3) Enable finer control for mutation and crossover probability*: Current design uses the crossover and mutation probability at the chromosome level. For finer control of mutation and crossover process the probability would be managed within MutationPolicy and CrossoverPolicy implementations. Probability would be passed as an argument to the respective operations. This way the corresponding operations will be responsible for managing probability and apply in convenient way. I have seen the controlling the mutation probability at the allele(gene) level improves the exploring capability of the optimization process and hence improves robustness. Removed Components: None New Components: None Affected Components: MutationPolicy, CrossoverPolicy and all other implementation classes *4) Addition of new Simulation Stopping conditions*: New simulation stopping conditions would be added based on population statistical characteristics. The simulation can be stopped based on variations of population average fitness or best fitness. These parameters are much better to represent nature of convergence. This will improve robustness to a considerable extent. Removed Components: None New Components: UnchangedAvgFitness, UnchangedBestFitness, PopulationStatisticalSummary Affected Components: SimulationStoppingCondition, GeneticAlgorithm, FixedElapsedTime, FixedGenerationCount *5) Introduction of Convergence listeners*: New convergence listener interface and registry would be introduced to enable tracking of convergence. Removed components: None New Components: ConvergenceListener, ListenerRegistry Affected Components: AbstractGeneticAlgorithm, GeneticAlgorithm was: *1) Creation of abstraction for GeneticAlgorithm*: In order to have different types of implementation for Genetic Algorithm like adaptive GA along with the existing one, we need to introduce an abstraction and a hierarchy of algorithm. AbstracttGeneticAlgorithm class needs to be implemented which would be extended by all other Algorithm class. This would also ease any future extension. Removed Components: None New Components: AbstractGeneticAlgorithm Affected Components: GeneticAlgorithm *2) Delegation of fitness calculation*: As per the current design Fitness interface is implemented by chromosome class, which forces implementation of fitness() method for any concrete chromosome. However this restricts the use of same concrete chromosome implementation to be reused for different problem domain. This inheritance based implementation should be replaced by composition. A new interface FitnessCalculator would be introduced. An instance of FitnessCalculator will be provided during creation of every concrete chromosome. This will enable reuse of concrete chromosome classes in different problem domain and hence improve extensibility and re-usability. This will require addition of an argument for each factory method and constructors. Removed Components: Fitness New Components: FitnessCalculator Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, RandomKey *3) Enable finer control for mutation and crossover probability*: Current design uses the crossover and mutation probability at the chromosome level. For finer control of mutation and crossover process the probability would be managed within
[jira] [Commented] (MATH-1627) ChiSquareTest computes NaN with zero observations
[
https://issues.apache.org/jira/browse/MATH-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402614#comment-17402614
]
Alex Herbert commented on MATH-1627:
If there is at least 1 observation (so total is non-zero) this issue still
manifests if any row or column in the input contingency table sums to zero due
to the division by the expected value:
{code:java}
double sumSq = 0.0d;
for (int row = 0; row < nRows; row++) {
for (int col = 0; col < nCols; col++) {
// *** Will create NaN if expected is zero ***
double expected = (rowSum[row] * colSum[col]) / total;
sumSq += ((counts[row][col] - expected) *
(counts[row][col] - expected)) / expected;
}
}
{code}
In this case two options are available:
# Raise an exception if any column or row total is zero
# Ignore the rows and columns from the sum of squared deviations
Option 2 may be more robust. The columns that are ignored still contribute to
the degrees of freedom of the test:
{code:java}
long[][] count = ...;
double df = ((double) counts.length -1) * ((double) counts[0].length - 1);
{code}
Note that R will compute NaN for the chi-square statistic in this case but is
OK if all columns and rows have at least 1 count above 0:
{code:r}
> m <- array(c(1,0,1,0), dim = c(2,2))
> chisq.test(m)
Pearson's Chi-squared test
data: m
X-squared = NaN, df = 1, p-value = NA
Warning message:
In chisq.test(m) : Chi-squared approximation may be incorrect
> m <- array(c(1,0,0,1), dim = c(2,2))
> chisq.test(m)
Pearson's Chi-squared test with Yates' continuity correction
data: m
X-squared = 0, df = 1, p-value = 1
Warning message:
In chisq.test(m) : Chi-squared approximation may be incorrect
{code}
Thus R is detecting if all observations are zero (and raising an error) but
will not raise an error if rows or columns are zero, instead computing NaN.
If the rows/columns are ignored (i.e. if expected=0, sum of square
deviations=0) then chi-square for this is 0.0. This is true for a 2x2 table
irrespective of the number of counts in a single entry:
{noformat}
[400, 0]
[0, 0]
chi2 = 0.0
{noformat}
This effectively ignores rows/columns. Ignoring columns/rows is reducing the
degrees of freedom (DoF) of the chi-square statistic. In the 2x2 case it
reduces the DoF to a level that is invalid.
This could be formalised in the class to ignore any column or row with all zero
entries. With the current code:
{code:java}
ChiSquareTest chi2Test = new ChiSquareTest();
long[][] counts = {{1, 2}, {3, 4}};
System.out.println(chi2Test.chiSquare(counts));
long[][] counts2 = {{1, 0, 2}, {0, 0, 0}, {3, 0, 4}};
System.out.println(chi2Test.chiSquare(counts2));
{code}
Outputs:
{noformat}
0.07936507936507939
NaN
{noformat}
If the rows and columns are ignored when the expected value is zero then the
chi-square is computed:
{noformat}
0.07936507936507939
0.07936507936507939
{noformat}
This effectively removes from the input contingency table any rows or columns
with no data. The degrees of freedom for the chi-square distribution would have
to be updated. This adds complexity to the class. It is preferable to leave it
to the caller to eliminate categories from the contingency table data that have
no observations.
A suggested fix is:
Raise a ZeroException if all input counts are zero
Raise a ZeroException if any column or row total is zero
The documentation should be updated to make the user aware this is possible.
This type of input is invalid for the chi-square computation.
> ChiSquareTest computes NaN with zero observations
> -
>
> Key: MATH-1627
> URL: https://issues.apache.org/jira/browse/MATH-1627
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Alex Herbert
>Priority: Trivial
>
> Zero observations input to the ChiSquareTest will compute NaN:
> {code:java}
> ChiSquareTest chi2Test = new ChiSquareTest();
> final long[][] counts = new long[2][2];
> // NaN
> double chi2 = chi2Test.chiSquare(counts);
> {code}
> This is due to a divide by zero error. This bug was identified by sonarcloud
> analysis.
> The unit tests use R as a reference. In R this case will raise an error that
> at least one entry must be positive. Setting a value to 1 allows R to compute
> a Chi-square test value but the value is not valid:
> {code:r}
> > m <- array(c(1,0,0,0), dim = c(2,2))
> > chisq.test(m)
> Pearson's Chi-squared test
> data: m
> X-squared = NaN, df = 1, p-value = NA
> Warning message:
> In chisq.test(m) : Chi-squared approximation may be incorrect
> {code}
> Other methods in the ChiSquareTest will raise a ZeroException if the
> observations are zero for an entire array of observations or if a pair of
> observations in a bin are both zero.
> The Chi square test has assumptions that do
[GitHub] [commons-pool] coveralls edited a comment on pull request #95: Improve Travis CI build Performance
coveralls edited a comment on pull request #95: URL: https://github.com/apache/commons-pool/pull/95#issuecomment-94998 [](https://coveralls.io/builds/42315597) Coverage decreased (-0.03%) to 84.961% when pulling **4db0030a150f2cff81f9a0a9f53beb20661b8c0b on YunLemon:Modify_Travis_1** into **b35f9a2f4ec4d3ca0fd409a4dabef7479306274d on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] coveralls edited a comment on pull request #178: Improve Travis CI build Performance
coveralls edited a comment on pull request #178: URL: https://github.com/apache/commons-csv/pull/178#issuecomment-899953168 [](https://coveralls.io/builds/42315534) Coverage remained the same at 98.323% when pulling **2f5092186bf401f394f9a451b05ba879f999560a on YunLemon:Modify_Travis_1** into **d714ff63ebe25eb6bddb1160f814c465f8764b89 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-geometry] darkma773r closed pull request #183: Simplify assertions with equivalent but more simple.
darkma773r closed pull request #183: URL: https://github.com/apache/commons-geometry/pull/183 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DBCP-509) Not all methods are consistent in PerUserPooldataSource and InstanceKeyDataSource
[ https://issues.apache.org/jira/browse/DBCP-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402608#comment-17402608 ] Gary D. Gregory commented on DBCP-509: -- Yeah, breaking BC is a no-go within 2.x. > Not all methods are consistent in PerUserPooldataSource and > InstanceKeyDataSource > - > > Key: DBCP-509 > URL: https://issues.apache.org/jira/browse/DBCP-509 > Project: Commons DBCP > Issue Type: Improvement >Affects Versions: 2.4.0 >Reporter: Bruno P. Kinoshita >Priority: Major > Fix For: 2.10.0 > > Time Spent: 40m > Remaining Estimate: 0h > > While working on DBCP-504 tests, I wrote a few files to help me automating > some of the tests (e.g. > https://gist.github.com/kinow/053b6d1f293fdc208a2a14571f246786). > In PerUserPooldataSource, I realized I had to change some tests that were > failing to handle null values. But not all methods. So I had a look at the > methods, and the majority was following a pattern > * using primitives > * default'ing to the class/parent method getDefaultPropertyZ() whenever Z > property was null > But three values were using objects instead of primitives, and allowing > null's: > * defaultAutoCommit > * defaultReadOnly > * perUserDefaultAutoCommit > I prepared a pull request that falls back to the default method's values. > It's more of a discussion issue, just to document what I found during > DBCP-504. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-796) SetUniqueList.createSetBasedOnList doesn't add list elements to return value
[ https://issues.apache.org/jira/browse/COLLECTIONS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402607#comment-17402607 ] Gary D. Gregory commented on COLLECTIONS-796: - [~owen-mc] Thank you for you report. May you please provide a PR (with a test) on GitHub? > SetUniqueList.createSetBasedOnList doesn't add list elements to return value > > > Key: COLLECTIONS-796 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-796 > Project: Commons Collections > Issue Type: Bug > Components: List >Affects Versions: 4.3, 4.4 >Reporter: Owen Mansel-Chan >Priority: Minor > Labels: easyfix, newbie > Original Estimate: 1h > Remaining Estimate: 1h > > SetUniqueList.createSetBasedOnList doesn't add list elements to the return > value any more. The documentation says it does, and it used to up to version > 4.2, but a call to `addAll` was accidentally deleted. I found where the > mistake was introduced on github: > https://github.com/apache/commons-collections/commit/b1c45ac691d46a8c609f2534d2adfa59c0599527#diff-8e53271d5d8299a76d43b0e3c81740fbe660083ae71c5bf2be63846d52156f23L344 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] darkma773r commented on pull request #183: Simplify assertions with equivalent but more simple.
darkma773r commented on pull request #183: URL: https://github.com/apache/commons-geometry/pull/183#issuecomment-903114414 These assertions were purposely written this way to fully exercise the `equals` methods in question and avoid any shortcuts used by JUnit (such as null checks) during evaluation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-geometry] darkma773r merged pull request #184: Simplify conditions avoiding redundant null check.
darkma773r merged pull request #184: URL: https://github.com/apache/commons-geometry/pull/184 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MATH-1627) ChiSquareTest computes NaN with zero observations
Alex Herbert created MATH-1627:
--
Summary: ChiSquareTest computes NaN with zero observations
Key: MATH-1627
URL: https://issues.apache.org/jira/browse/MATH-1627
Project: Commons Math
Issue Type: Bug
Affects Versions: 4.0
Reporter: Alex Herbert
Zero observations input to the ChiSquareTest will compute NaN:
{code:java}
ChiSquareTest chi2Test = new ChiSquareTest();
final long[][] counts = new long[2][2];
// NaN
double chi2 = chi2Test.chiSquare(counts);
{code}
This is due to a divide by zero error. This bug was identified by sonarcloud
analysis.
The unit tests use R as a reference. In R this case will raise an error that at
least one entry must be positive. Setting a value to 1 allows R to compute a
Chi-square test value but the value is not valid:
{code:r}
> m <- array(c(1,0,0,0), dim = c(2,2))
> chisq.test(m)
Pearson's Chi-squared test
data: m
X-squared = NaN, df = 1, p-value = NA
Warning message:
In chisq.test(m) : Chi-squared approximation may be incorrect
{code}
Other methods in the ChiSquareTest will raise a ZeroException if the
observations are zero for an entire array of observations or if a pair of
observations in a bin are both zero.
The Chi square test has assumptions that do not hold when the number of
observations are small. The limit for the number of observations per category
is variable. The document referenced in the code javadoc recommends an expected
level of 5 per bin. To avoid setting limits on the sample size a suggested fix
is to raise a zero exception if the sum of all counts is zero. This will avoid
a NaN computation. Use of a suitable number of observations is left to the
caller.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MATH-1618) Change in Existing Design
[ https://issues.apache.org/jira/browse/MATH-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1618: --- Description: *1) Creation of abstraction for GeneticAlgorithm*: In order to have different types of implementation for Genetic Algorithm like adaptive GA along with the existing one, we need to introduce an abstraction and a hierarchy of algorithm. AbstracttGeneticAlgorithm class needs to be implemented which would be extended by all other Algorithm class. This would also ease any future extension. Removed Components: None New Components: AbstractGeneticAlgorithm Affected Components: GeneticAlgorithm *2) Delegation of fitness calculation*: As per the current design Fitness interface is implemented by chromosome class, which forces implementation of fitness() method for any concrete chromosome. However this restricts the use of same concrete chromosome implementation to be reused for different problem domain. This inheritance based implementation should be replaced by composition. A new interface FitnessCalculator would be introduced. An instance of FitnessCalculator will be provided during creation of every concrete chromosome. This will enable reuse of concrete chromosome classes in different problem domain and hence improve extensibility and re-usability. This will require addition of an argument for each factory method and constructors. Removed Components: Fitness New Components: FitnessCalculator Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, RandomKey *3) Enable finer control for mutation and crossover probability*: Current design uses the crossover and mutation probability at the chromosome level. For finer control of mutation and crossover process the probability would be managed within MutationPolicy and CrossoverPolicy implementations. Probability would be passed as an argument to the respective operations. This way the corresponding operations will be responsible for managing probability and apply in convenient way. I have seen the controlling the mutation probability at the allele(gene) level improves the exploring capability of the optimization process and hence improves robustness. Removed Components: None New Components: None Affected Components: MutationPolicy, CrossoverPolicy and all other implementation classes *4) Addition of new Simulation Stopping conditions*: New simulation stopping conditions would be added based on population statistical characteristics. The simulation can be stopped based on variations of population average fitness or best fitness. These parameters are much better to represent nature of convergence. This will improve robustness to a considerable extent. Removed Components: None New Components: UnchangedAvgFitness, UnchangedBestFitness, PopulationStatisticalSummary Affected Components: SimulationStoppingCondition, GeneticAlgorithm, FixedElapsedTime, FixedGenerationCount was: *1) Creation of abstraction for GeneticAlgorithm*: In order to have different types of implementation for Genetic Algorithm like adaptive GA along with the existing one, we need to introduce an abstraction and a hierarchy of algorithm. AbstracttGeneticAlgorithm class needs to be implemented which would be extended by all other Algorithm class. This would also ease any future extension. Removed Components: None New Components: AbstractGeneticAlgorithm Affected Components: GeneticAlgorithm *2) Delegation of fitness calculation*: As per the current design Fitness interface is implemented by chromosome class, which forces implementation of fitness() method for any concrete chromosome. However this restricts the use of same concrete chromosome implementation to be reused for different problem domain. This inheritance based implementation should be replaced by composition. A new interface FitnessCalculator would be introduced. An instance of FitnessCalculator will be provided during creation of every concrete chromosome. This will enable reuse of concrete chromosome classes in different problem domain and hence improve extensibility and re-usability. This will require addition of an argument for each factory method and constructors. Removed Components: Fitness New Components: FitnessCalculator Affected Components: Chromosome, AbstractListChromosome, BinaryChromosome, RandomKey *3) Enable finer control for mutation and crossover probability*: Current design uses the crossover and mutation probability at the chromosome level. For finer control of mutation and crossover process the probability would be managed within MutationPolicy and CrossoverPolicy implementations. Probability would be passed as an argument to the respective operations. This way the corresponding operations will be responsible for managing probability and apply in convenient way. I have seen the controlling the mutation probability
[GitHub] [commons-lang] coveralls edited a comment on pull request #789: Improve Travis CI build Performance
coveralls edited a comment on pull request #789: URL: https://github.com/apache/commons-lang/pull/789#issuecomment-899514610 [](https://coveralls.io/builds/42315234) Coverage increased (+0.0003%) to 94.985% when pulling **310c8adc63031f7fd58cde28b79ef0376611384b on YunLemon:Modify_Travis_1** into **a6df7f74564b9432bf38fe33c4adc0bc529bf7c9 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-fileupload] coveralls edited a comment on pull request #106: Improve Travis CI build Performance
coveralls edited a comment on pull request #106: URL: https://github.com/apache/commons-fileupload/pull/106#issuecomment-899943609 [](https://coveralls.io/builds/42315242) Coverage remained the same at 78.117% when pulling **04456d24a9bfb40b80c08dec05e6b817886d651c on YunLemon:Modify_Travis_1** into **9024c19c0dfcceae9f303692b00fddcc607eb28c on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-codec] coveralls edited a comment on pull request #90: Improve Travis CI build Performance
coveralls edited a comment on pull request #90: URL: https://github.com/apache/commons-codec/pull/90#issuecomment-899512486 [](https://coveralls.io/builds/42315228) Coverage remained the same at 94.682% when pulling **380b4007923ffa8871eb17d2d7b537d5fc670e2e on YunLemon:Modify_Travis_1** into **b7ba05ad6b99ae9d5f93cd18e936b3e8908202fb on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] HelderMagalhaes closed pull request #199: Whitespace improvement, site nits and assorted typos
HelderMagalhaes closed pull request #199: URL: https://github.com/apache/commons-compress/pull/199 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] HelderMagalhaes edited a comment on pull request #199: Whitespace improvement, site nits and assorted typos
HelderMagalhaes edited a comment on pull request #199: URL: https://github.com/apache/commons-compress/pull/199#issuecomment-903098704 Closing down this PR as it seemed to get rot (lots of unexpected code changes), possibly due to something wrong during the rebase. Will open a new one briefly. Thanks to @PeterAlfredLee for the feedback. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] HelderMagalhaes commented on pull request #199: Whitespace improvement, site nits and assorted typos
HelderMagalhaes commented on pull request #199: URL: https://github.com/apache/commons-compress/pull/199#issuecomment-903098704 Closing down this PR as it seemed to get rot, possibly due to something wrong during rebase. Will open a new one briefly. Thanks to @PeterAlfredLee for the feedback. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter
[
https://issues.apache.org/jira/browse/LANG-1593?focusedWorklogId=640443=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640443
]
ASF GitHub Bot logged work on LANG-1593:
Author: ASF GitHub Bot
Created on: 21/Aug/21 10:16
Start Date: 21/Aug/21 10:16
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #784:
URL: https://github.com/apache/commons-lang/pull/784#discussion_r693335904
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -3922,6 +3922,37 @@ public static String join(final boolean[] array, final
char delimiter) {
* @since 3.12.0
*/
public static String join(final boolean[] array, final char delimiter,
final int startIndex, final int endIndex) {
+return join(array, String.valueOf(delimiter), startIndex, endIndex);
+}
+
+/**
+ * Joins the elements of the provided array into a single String
containing the provided list of elements.
Review comment:
The first sentence in a Javadoc comment is special, it is the summary
and should not be additionally wrapped in a paragraph.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 640443)
Time Spent: 4h 20m (was: 4h 10m)
> Common behaviour for StringUtils join APIs when called with char or String
> delimiter
>
>
> Key: LANG-1593
> URL: https://issues.apache.org/jira/browse/LANG-1593
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 3.4, 3.11
>Reporter: Kiruahxh
>Priority: Minor
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> For now, join(int[], char) is working well.
> However, the same join method called with a string delimiter behaves
> differently : it returns a single memory address which is not the desired
> behavior.
> I think that, for coherence, calling StringUtils with a char or String
> delimiter should return the exact same value.
> Ex :
> {code:java}
> CLASSPATH="./commons-lang3-3.11.jar" jshell
> | Welcome to JShell -- Version 11.0.8
> jshell> import org.apache.commons.lang3.StringUtils
> jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
> jshell> String result = StringUtils.join(arr, '-');
> result ==> "1-2-3-4-5-6-7"
> jshell> String result = StringUtils.join(arr, "-");
> result ==> "[I@69663380-"
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on a change in pull request #784: [LANG-1593] Common behavior for StringUtils join APIs when called with char or String delimiter
garydgregory commented on a change in pull request #784:
URL: https://github.com/apache/commons-lang/pull/784#discussion_r693335904
##
File path: src/main/java/org/apache/commons/lang3/StringUtils.java
##
@@ -3922,6 +3922,37 @@ public static String join(final boolean[] array, final
char delimiter) {
* @since 3.12.0
*/
public static String join(final boolean[] array, final char delimiter,
final int startIndex, final int endIndex) {
+return join(array, String.valueOf(delimiter), startIndex, endIndex);
+}
+
+/**
+ * Joins the elements of the provided array into a single String
containing the provided list of elements.
Review comment:
The first sentence in a Javadoc comment is special, it is the summary
and should not be additionally wrapped in a paragraph.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (MATH-1626) Variance weighted evaluation may have unexpected output (negative or NaN variance)
Alex Herbert created MATH-1626:
--
Summary: Variance weighted evaluation may have unexpected output
(negative or NaN variance)
Key: MATH-1626
URL: https://issues.apache.org/jira/browse/MATH-1626
Project: Commons Math
Issue Type: Bug
Affects Versions: 4.0
Reporter: Alex Herbert
The Variance class implements WeightedEvaluation:
{code:java}
double evaluate(double[] values, double[] weights);
double evaluate(double[] values, double[] weights, int begin, int length);
{code}
This applies a weight to each input value. However the default behaviour is to
compute the bias corrected variance by dividing by the sum of the weights minus
1. This will result in:
* a negative variance if the weights sum to less than 1
* a NaN variance if the weights sum to 1
The weights are verified by the MathArrays.verifyValues method to have at least
1 non-zero weight in the evaluated range and no negative weights. But no
validation is performed to ensure the weights sum to above 1.
A suggested fix is to document this behaviour. The bias corrected weighted
evaluation for the variance should only be applied when the weights correspond
to observed counts of values in a population. Ideally the sum of the weights is
the total number of observations and should be at least 2.
This issue can also be avoided by using the non-bias corrected variance.
This issue applies to any weighted evaluation based on the Variance:
* StandardDeviation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter
[
https://issues.apache.org/jira/browse/LANG-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402543#comment-17402543
]
Hubert Wojciechowski commented on LANG-1593:
h3. Evidences
{code:java}
hubert@mac target % jshell -class-path './commons-lang3-3.13.0-SNAPSHOT.jar'
| Welcome to JShell -- Version 16
| For an introduction type: /help intro
jshell> import org.apache.commons.lang3.StringUtils
jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
arr ==> int[7] { 1, 2, 3, 4, 5, 6, 7 }
jshell> String result = StringUtils.join(arr, '-');
result ==> "1-2-3-4-5-6-7"
jshell> String result = StringUtils.join(arr, "-");
result ==> "1-2-3-4-5-6-7"
{code}
> Common behaviour for StringUtils join APIs when called with char or String
> delimiter
>
>
> Key: LANG-1593
> URL: https://issues.apache.org/jira/browse/LANG-1593
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 3.4, 3.11
>Reporter: Kiruahxh
>Priority: Minor
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> For now, join(int[], char) is working well.
> However, the same join method called with a string delimiter behaves
> differently : it returns a single memory address which is not the desired
> behavior.
> I think that, for coherence, calling StringUtils with a char or String
> delimiter should return the exact same value.
> Ex :
> {code:java}
> CLASSPATH="./commons-lang3-3.11.jar" jshell
> | Welcome to JShell -- Version 11.0.8
> jshell> import org.apache.commons.lang3.StringUtils
> jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
> jshell> String result = StringUtils.join(arr, '-');
> result ==> "1-2-3-4-5-6-7"
> jshell> String result = StringUtils.join(arr, "-");
> result ==> "[I@69663380-"
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1593) Common behaviour for StringUtils join APIs when called with char or String delimiter
[
https://issues.apache.org/jira/browse/LANG-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402541#comment-17402541
]
Hubert Wojciechowski commented on LANG-1593:
[~erans]
All changes ready. Build is green.
Please check if you find a moment.
https://github.com/apache/commons-lang/pull/784
> Common behaviour for StringUtils join APIs when called with char or String
> delimiter
>
>
> Key: LANG-1593
> URL: https://issues.apache.org/jira/browse/LANG-1593
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 3.4, 3.11
>Reporter: Kiruahxh
>Priority: Minor
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> For now, join(int[], char) is working well.
> However, the same join method called with a string delimiter behaves
> differently : it returns a single memory address which is not the desired
> behavior.
> I think that, for coherence, calling StringUtils with a char or String
> delimiter should return the exact same value.
> Ex :
> {code:java}
> CLASSPATH="./commons-lang3-3.11.jar" jshell
> | Welcome to JShell -- Version 11.0.8
> jshell> import org.apache.commons.lang3.StringUtils
> jshell> int[] arr = {1, 2, 3, 4, 5, 6, 7};
> jshell> String result = StringUtils.join(arr, '-');
> result ==> "1-2-3-4-5-6-7"
> jshell> String result = StringUtils.join(arr, "-");
> result ==> "[I@69663380-"
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
