Re: [VOTE] Release of Commons Collections 4.0-alpha1 based on RC2
Le 30/06/2013 23:57, Thomas Neidhart a écrit : Hi, I'd like to call a vote for releasing Commons Collections 4.0-alpha1 based on RC2. The following changes have been applied since RC1: * upgrade to maven-javadoc-plugin 2.9.1 (due to CVE-2013-1571) * fixed COLLECTIONS-474, thanks to sebb * fixed download page (contained wrong component id) * added html version of release notes for site The artifacts / site have been built with Oracle JDK 1.5 build 1.5.0_22-b03. The files: The artifacts are deployed to Nexus: https://repository.apache.org/content/repositories/orgapachecommons-092/org/apache/commons/commons-collections4/4.0-alpha1/ Distribution files: https://dist.apache.org/repos/dist/dev/commons/collections/ The tag: https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_ALPHA1_RC2/ The site: http://people.apache.org/builds/commons/collections/4.0-alpha1/RC2/ Additional Notes: o the download page and api links to older releases only work on the published site and will be corrected after release. Please take a look at the commons-collections-4.0-alpha1 artifacts and vote! [X] +1 release it. Thanks Thomas, Luc [ ] +0 go ahead; I don't care. [ ] -0 there are a few minor glitches: ... [ ] -1 no, do not release it because ... Vote will remain open for at least 72 hours. Thanks in advance, 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: [VOTE] Release of Commons Collections 4.0-alpha1 based on RC2
2013/7/1 Thomas Neidhart thomas.neidh...@gmail.com: Hi, I'd like to call a vote for releasing Commons Collections 4.0-alpha1 based on RC2. The following changes have been applied since RC1: * upgrade to maven-javadoc-plugin 2.9.1 (due to CVE-2013-1571) * fixed COLLECTIONS-474, thanks to sebb * fixed download page (contained wrong component id) * added html version of release notes for site The artifacts / site have been built with Oracle JDK 1.5 build 1.5.0_22-b03. The files: The artifacts are deployed to Nexus: https://repository.apache.org/content/repositories/orgapachecommons-092/org/apache/commons/commons-collections4/4.0-alpha1/ Distribution files: https://dist.apache.org/repos/dist/dev/commons/collections/ The tag: https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_ALPHA1_RC2/ The site: http://people.apache.org/builds/commons/collections/4.0-alpha1/RC2/ Additional Notes: o the download page and api links to older releases only work on the published site and will be corrected after release. Please take a look at the commons-collections-4.0-alpha1 artifacts and vote! [X] +1 release it. [ ] +0 go ahead; I don't care. [ ] -0 there are a few minor glitches: ... [ ] -1 no, do not release it because ... Great to see collections moving forward!!! Vote will remain open for at least 72 hours. Thanks in advance, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT][VOTE][LAZY] Release Commons Parent 32 from RC1
The 72 hours having elapsed without any -1 votes having been cast, the vote duly passes. On 28 June 2013 13:18, sebb seb...@gmail.com wrote: This is a VOTE to release Commons Parent 31-RC2 This VOTE by LAZY-CONSENSUS is open for at least 72 hours It will finish no earlier than July 1 2013 at 14:00 GMT. The only change in this release is: - updated Javadoc plugin to 2.9.1 to fix Javadoc vulnerability (CVE-2013-1571, VU#225657) MJAVADOC-370 The files: https://repository.apache.org/content/repositories/orgapachecommons-087/ The tag: https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-32-RC1/ The site: None. No need to vote unless you think there is a problem, in which case please vote -1 and explaing what the issue is. TIA! - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
Hi. I just noticed your request to write the algorithm along the lines of the wikipedia article. The only major difference between my code and the article on Wikipedia is that I found it necessary to move the recursive stack in into a data structure to avoid a StackOverflowException when the non polynomial curvature is concentrated in a corner of the domain of integration. Notice that the Stack objects stores a Stack of limits of integration. There is a misunderstanding: I'm referring to the high-level description of the algorithm that is the separation of concerns between the quadrature method and the adaptive process. Your code mixes the two. Moreover, it does not reuse any of the quadrature schemes already implemented in CM, but implements a (new?) one without any reference or comments. [And this is even without delving into remarks concerning the code structure itself.] Additionally, your patch also mixes two concepts: Adaptive quadrature vs improper integral (which is also MATH-994); it is hard to follow what problem this issue is supposed to point to, and how the patch solves it. Indeed your unit tests shows a problem with improper integrals which the class IterativeGaussLegendreIntegrator is _not_ meant to handle.[1] To be clear, hopefully, you are demonstrating a problem that occurs when combining Commons Math code with code which you created. The first step is to create a unit test demonstrating whether an issue exists with IterativeGaussLegendreIntegrator code only (i.e. without relying on your InfiniteIntegral class).[1] If no independent issue exist, then MATH-995 should be replaced by an appropriate feature request. Also, it would certainly be helpful to pinpoint the reason why the combination of IterativeGaussLegendreIntegrator and InfiniteIntegral is not legitimate (if that's the case). Regards, Gilles [1] Cf. also my latest comment on the MATH-995 page. Cheers, Ajo. On Fri, Jun 28, 2013 at 11:07 AM, Ajo Fod ajo@gmail.com wrote: BTW, it is possible that I'm not using LGQ correctly. If so, please show how to pass the tests I've added. I'd much rather use something that is better tested than my personal code. -Ajo. On Fri, Jun 28, 2013 at 11:04 AM, Ajo Fod ajo@gmail.com wrote: I just posted a patch on this issue. Feel free to edit as necessary to match your standards. There is a clear issue with LGQ. Cheers, Ajo. On Fri, Jun 28, 2013 at 10:54 AM, Gilles gil...@harfang.homelinux.orgwrote: Ted, Did you read my other (rather more lengthy) post? Is that jumping? Yes. You jumped on him rather than helped him be productive. The general message is we have something in the works, don't bother us with your ideas. Then please read all the messages pertaining to those issues more carefully: I never wrote such a thing (neither now nor in the past). I pointed to a potential problem in the usage of the CM code. I pointed (several times and in details) to problems in candidate contributions, with arguments that go well beyond bad formatting. I pointed out how we could improve the functionality _together_ (i.e. by using what we have, instead of throwing it out without even trying to figure out how good or bad it is). IMHO, these were all valid suggestions to be productive in helping CM to become better, instead of merely larger. The former indeed requires more effort than the latter. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
If you wanted to use the Math 3 codebase in AdaptiveQuadrature, you'd compute the calculations of Q1 and Q2 with something else. I'm not entirely familiar with the apache Math codebase so my guess would be that you can replace the following line in AdaptiveQuadrature.proc(): double Q1 = delta / 6 * (va + 4 * vm + vb); with a modification adapted from IterativeLegendreGaussIntegrator.stage(n) line for integration as follows: Q1 = delta * FACTORY.legendreHighPrecision(numberOfPoints, a, b).integrate(fn); Q2 = delta * FACTORY.legendreHighPrecision(numberOfPoints+1, a, b).integrate(fn); ... or some slight modification of the above. Each of the tests in the patch is integrating a UnivariateFunction in [-1,1]. Infinity.wrap(fn) just provides that UnivariateFunction. [In the patches for MATH-995 the InfiniteIntegral was replaced by Infinity.wrap() ]. So, if you are saying that the intent of IterativeLegendreGaussIntegrator (refered to as LGQ) was not to integrate this kind of UnivariateFunction in [-1,1], ... what kind of univariate function would that be? If it is indeed supposed to do the integration, then AQ clearly does a better job. So, why does LGQ fail here? It is probably that the Adaptive division of the integration domain (as opposed to the uniform division with LGQ) gives AQ the critical edge. The test you have for LGQ so far are pretty well behaved. Summary: I'm demonstrating a clear bug/inefficiency with LGQ and providing you with an alternative that is more accurate. Cheers, Ajo. On Mon, Jul 1, 2013 at 8:22 AM, Gilles gil...@harfang.homelinux.org wrote: Hi. I just noticed your request to write the algorithm along the lines of the wikipedia article. The only major difference between my code and the article on Wikipedia is that I found it necessary to move the recursive stack in into a data structure to avoid a StackOverflowException when the non polynomial curvature is concentrated in a corner of the domain of integration. Notice that the Stack objects stores a Stack of limits of integration. There is a misunderstanding: I'm referring to the high-level description of the algorithm that is the separation of concerns between the quadrature method and the adaptive process. Your code mixes the two. Moreover, it does not reuse any of the quadrature schemes already implemented in CM, but implements a (new?) one without any reference or comments. [And this is even without delving into remarks concerning the code structure itself.] Additionally, your patch also mixes two concepts: Adaptive quadrature vs improper integral (which is also MATH-994); it is hard to follow what problem this issue is supposed to point to, and how the patch solves it. Indeed your unit tests shows a problem with improper integrals which the class **IterativeGaussLegendreIntegrat**or is _not_ meant to handle.[1] To be clear, hopefully, you are demonstrating a problem that occurs when combining Commons Math code with code which you created. The first step is to create a unit test demonstrating whether an issue exists with **IterativeGaussLegendreIntegrat**or code only (i.e. without relying on your InfiniteIntegral class).[1] If no independent issue exist, then MATH-995 should be replaced by an appropriate feature request. Also, it would certainly be helpful to pinpoint the reason why the combination of **IterativeGaussLegendreIntegrat**or and InfiniteIntegral is not legitimate (if that's the case). Regards, Gilles [1] Cf. also my latest comment on the MATH-995 page. Cheers, Ajo. On Fri, Jun 28, 2013 at 11:07 AM, Ajo Fod ajo@gmail.com wrote: BTW, it is possible that I'm not using LGQ correctly. If so, please show how to pass the tests I've added. I'd much rather use something that is better tested than my personal code. -Ajo. On Fri, Jun 28, 2013 at 11:04 AM, Ajo Fod ajo@gmail.com wrote: I just posted a patch on this issue. Feel free to edit as necessary to match your standards. There is a clear issue with LGQ. Cheers, Ajo. On Fri, Jun 28, 2013 at 10:54 AM, Gilles gil...@harfang.homelinux.org **wrote: Ted, Did you read my other (rather more lengthy) post? Is that jumping? Yes. You jumped on him rather than helped him be productive. The general message is we have something in the works, don't bother us with your ideas. Then please read all the messages pertaining to those issues more carefully: I never wrote such a thing (neither now nor in the past). I pointed to a potential problem in the usage of the CM code. I pointed (several times and in details) to problems in candidate contributions, with arguments that go well beyond bad formatting. I pointed out how we could improve the functionality _together_ (i.e. by using what we have, instead of throwing it out without even trying to figure out how good or bad it is). IMHO, these were all valid suggestions to be productive in helping CM to become better,
[collection] v4 CompliantBag
Hi All: I find the class name CompliantBag pretty confusing. Compliant with what? The Javadoc says Collection so, why not call it BagCollection? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Release of Commons Collections 4.0-alpha1 based on RC2
+1 Oliver Am 30.06.2013 23:57, schrieb Thomas Neidhart: Hi, I'd like to call a vote for releasing Commons Collections 4.0-alpha1 based on RC2. The following changes have been applied since RC1: * upgrade to maven-javadoc-plugin 2.9.1 (due to CVE-2013-1571) * fixed COLLECTIONS-474, thanks to sebb * fixed download page (contained wrong component id) * added html version of release notes for site The artifacts / site have been built with Oracle JDK 1.5 build 1.5.0_22-b03. The files: The artifacts are deployed to Nexus: https://repository.apache.org/content/repositories/orgapachecommons-092/org/apache/commons/commons-collections4/4.0-alpha1/ Distribution files: https://dist.apache.org/repos/dist/dev/commons/collections/ The tag: https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_ALPHA1_RC2/ The site: http://people.apache.org/builds/commons/collections/4.0-alpha1/RC2/ Additional Notes: o the download page and api links to older releases only work on the published site and will be corrected after release. Please take a look at the commons-collections-4.0-alpha1 artifacts and vote! [ ] +1 release it. [ ] +0 go ahead; I don't care. [ ] -0 there are a few minor glitches: ... [ ] -1 no, do not release it because ... Vote will remain open for at least 72 hours. Thanks in advance, 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: [VOTE] Release of Commons Collections 4.0-alpha1 based on RC2
Hello Thomas, first of all: many thanks for the great effort you put into collections. I think aside from math and lang, collections is probably one of the most used components. It's really cool to see this happening. So here is my vote: - Checksums and signatures are okay. - Site looks good, but: - PMD shows some errors that seem to be easy to fix (without having looked at the code). If I have spare time this week, I'll try to have a look. - Sources and tag have the same content - Builds fine from tag and from sources with: Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100) Maven home: /Applications/dev/maven/apache-maven-3.0.5 Java version: 1.7.0_25, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre Default locale: de_DE, platform encoding: UTF-8 OS name: mac os x, version: 10.8.4, arch: x86_64, family: mac One thing that could be improved is RELEASE-NOTES.txt. I think it would be good to make very clear what alpha means (have we agreed on this? I'm not sure). If BC breaking changes are possible but unlikely we should document this in the release notes. However no blocker. +1 Benedikt 2013/6/30 Thomas Neidhart thomas.neidh...@gmail.com Hi, I'd like to call a vote for releasing Commons Collections 4.0-alpha1 based on RC2. The following changes have been applied since RC1: * upgrade to maven-javadoc-plugin 2.9.1 (due to CVE-2013-1571) * fixed COLLECTIONS-474, thanks to sebb * fixed download page (contained wrong component id) * added html version of release notes for site The artifacts / site have been built with Oracle JDK 1.5 build 1.5.0_22-b03. The files: The artifacts are deployed to Nexus: https://repository.apache.org/content/repositories/orgapachecommons-092/org/apache/commons/commons-collections4/4.0-alpha1/ Distribution files: https://dist.apache.org/repos/dist/dev/commons/collections/ The tag: https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_ALPHA1_RC2/ The site: http://people.apache.org/builds/commons/collections/4.0-alpha1/RC2/ Additional Notes: o the download page and api links to older releases only work on the published site and will be corrected after release. Please take a look at the commons-collections-4.0-alpha1 artifacts and vote! [ ] +1 release it. [ ] +0 go ahead; I don't care. [ ] -0 there are a few minor glitches: ... [ ] -1 no, do not release it because ... Vote will remain open for at least 72 hours. Thanks in advance, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
Just a few thoughts.
It seems to me that this code suffers from redundant function evaluations. I am
not sure what to think about the movement from edges since it violates proper
behavior for well behaved functions in order to work for some special cases. In
case of infinite integrals it might be better to create the initial offset
there, rather than in the adaptive quadrature. In any case the check should be
moved out of the inside iteration.
A while back I wrote an adaptive quadrature to evaluation vector functions,
some code can easily be modified into this class. Hope it helps.
/**
* The Class SimpsonVectorQuad.
*/
public final class SimpsonVectorQuad implements UnivariateVectorIntegrator
{
/** The abs point tolerance. */
final double absPointTolerance;
/** The real tolerance. */
final double realTolerance;
/**
* Instantiates a new simpson vector quad.
*
* @param realTolerance
* the real tolerance
*/
public SimpsonVectorQuad(double realTolerance)
{
this(realTolerance,1.0e-8);
}
/**
* Instantiates a new simpson vector quad.
*
* @param realTolerance
* the real tolerance
* @param absPointTolerance
* the abs point tolerance
*/
public SimpsonVectorQuad(double realTolerance, double absPointTolerance)
{
this.realTolerance = realTolerance;
this.absPointTolerance = absPointTolerance;
}
/* (non-Javadoc)
* @see
edu.umd.umiacs.armor.math.integration.UnivariateVectorIntegrator#integrate(edu.umd.umiacs.armor.math.func.UnivariateVectorFunction,
double, double, int)
*/
@Override
public double[] integrate(UnivariateVectorFunction f, double a, double
b, int maxEvals)
{
IntegratorProperties property = new IntegratorProperties();
property.evalCount = 0;
double h = 0.13579*(b-a);
double[] x = {a, a+h, a+2.0*h, (a+b)*0.5, b-2.0*h, b-h, b};
double[][] y = new double[7][];
for (int iter=0; iterx.length; iter++)
{
y[iter] = f.value(x[iter]);
for (int nanLoop=0; nanLoopy[iter].length; nanLoop++)
if (Double.isNaN(y[iter][nanLoop]))
throw new MathRuntimeException(Function
evaluation return NaN.);
}
property.evalCount += 7;
double[] Q1 = new double[y[0].length];
double[] Q2 = new double[y[0].length];
double[] Q3 = new double[y[0].length];
int depth = 0;
quadstep(f,Q1,x[0],x[2],y[0],y[1],y[2],this.realTolerance/3.0,property,maxEvals,depth+1);
quadstep(f,Q2,x[2],x[4],y[2],y[3],y[4],this.realTolerance/3.0,property,maxEvals,depth+1);
quadstep(f,Q3,x[4],x[6],y[4],y[5],y[6],this.realTolerance/3.0,property,maxEvals,depth+1);
//sum up the results
for (int iter=0; iterQ1.length; iter++)
Q1[iter] = Q1[iter]+Q2[iter]+Q3[iter];
return Q1;
}
/**
* Quadstep.
*
* @param f
* the f
* @param Q
* the q
* @param a
* the a
* @param b
* the b
* @param fa
* the fa
* @param fc
* the fc
* @param fb
* the fb
* @param tol
* the tol
* @param property
* the property
* @param maxEvals
* the max evals
* @param depth
* the depth
*/
private void quadstep(UnivariateVectorFunction f, double[] Q, double a,
double b,
double[] fa, double[] fc, double[] fb,
double tol, IntegratorProperties property, double maxEvals, int
depth)
{
// Evaluate integrant twice in interior of subinterval [a,b].
double h = b - a;
double c = (a + b)*0.5;
double d = (a + c)*0.5;
double e = (c + b)*0.5;
double[] fd = f.value(d);
for (int nanLoop=0; nanLoopfd.length; nanLoop++)
if (Double.isNaN(fd[nanLoop]))
throw new ArithmeticException(Function
[ANNOUNCE] Commons Parent 32 released
Commons Parent 32 has been released. The only change is to update the Javadoc plugin to 2.9.1 to address the Javadoc script vulnerability. Components are recommended to upgrade before the next release as this release fixes the Javadoc issue. If the component cannot be upgraded immediately (not sure why that should be!), please ensure you at least upgrade the Javadoc plugin to 2.9.1 (or later). If upgrading causes any breaking changes, please report ASAP so a new release can be prepared. Reminder: please ensure you fix the properties: maven.compile.* = maven.compiler.* when updating to CP32 from CP30 or earlier - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
1 Could you provide an example of redundant function evaluations in my
code?
2 I made the adjustment in AQ because the size of the segment that was
excluded from the integration could be determined adaptively to keep the
error arbitrarily low. Note the size of the segment that is excluded (at
the edges of the integration domain) can be defined as a function of the
error tolerance. It is unlikely that that exclusion will cause problems for
proper integrals. But it does save the day for when infinities are present
... not a bad trade off if you think about it.
3 BTW, I think your code is a lot like mine ... except that it uses the
program stack ... so it will likely fail at the depth required for
integration of the PDF with sigma=1000.
Cheers,
-Ajo
On Mon, Jul 1, 2013 at 3:17 PM, Konstantin Berlin kber...@gmail.com wrote:
Just a few thoughts.
It seems to me that this code suffers from redundant function evaluations.
I am not sure what to think about the movement from edges since it violates
proper behavior for well behaved functions in order to work for some
special cases. In case of infinite integrals it might be better to create
the initial offset there, rather than in the adaptive quadrature. In any
case the check should be moved out of the inside iteration.
A while back I wrote an adaptive quadrature to evaluation vector
functions, some code can easily be modified into this class. Hope it helps.
/**
* The Class SimpsonVectorQuad.
*/
public final class SimpsonVectorQuad implements UnivariateVectorIntegrator
{
/** The abs point tolerance. */
final double absPointTolerance;
/** The real tolerance. */
final double realTolerance;
/**
* Instantiates a new simpson vector quad.
*
* @param realTolerance
* the real tolerance
*/
public SimpsonVectorQuad(double realTolerance)
{
this(realTolerance,1.0e-8);
}
/**
* Instantiates a new simpson vector quad.
*
* @param realTolerance
* the real tolerance
* @param absPointTolerance
* the abs point tolerance
*/
public SimpsonVectorQuad(double realTolerance, double
absPointTolerance)
{
this.realTolerance = realTolerance;
this.absPointTolerance = absPointTolerance;
}
/* (non-Javadoc)
* @see
edu.umd.umiacs.armor.math.integration.UnivariateVectorIntegrator#integrate(edu.umd.umiacs.armor.math.func.UnivariateVectorFunction,
double, double, int)
*/
@Override
public double[] integrate(UnivariateVectorFunction f, double a,
double b, int maxEvals)
{
IntegratorProperties property = new IntegratorProperties();
property.evalCount = 0;
double h = 0.13579*(b-a);
double[] x = {a, a+h, a+2.0*h, (a+b)*0.5, b-2.0*h, b-h, b};
double[][] y = new double[7][];
for (int iter=0; iterx.length; iter++)
{
y[iter] = f.value(x[iter]);
for (int nanLoop=0; nanLoopy[iter].length; nanLoop++)
if (Double.isNaN(y[iter][nanLoop]))
throw new MathRuntimeException(Function
evaluation return NaN.);
}
property.evalCount += 7;
double[] Q1 = new double[y[0].length];
double[] Q2 = new double[y[0].length];
double[] Q3 = new double[y[0].length];
int depth = 0;
quadstep(f,Q1,x[0],x[2],y[0],y[1],y[2],this.realTolerance/3.0,property,maxEvals,depth+1);
quadstep(f,Q2,x[2],x[4],y[2],y[3],y[4],this.realTolerance/3.0,property,maxEvals,depth+1);
quadstep(f,Q3,x[4],x[6],y[4],y[5],y[6],this.realTolerance/3.0,property,maxEvals,depth+1);
//sum up the results
for (int iter=0; iterQ1.length; iter++)
Q1[iter] = Q1[iter]+Q2[iter]+Q3[iter];
return Q1;
}
/**
* Quadstep.
*
* @param f
* the f
* @param Q
* the q
* @param a
* the a
* @param b
* the b
* @param fa
* the fa
* @param fc
* the fc
* @param fb
* the fb
* @param tol
* the tol
* @param property
* the property
* @param maxEvals
* the max evals
* @param depth
* the depth
*/
private void quadstep(UnivariateVectorFunction f, double[] Q,
double a, double b,
double[] fa, double[] fc, double[] fb,
Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
Hi. On Mon, 1 Jul 2013 10:50:19 -0700, Ajo Fod wrote: If you wanted to use the Math 3 codebase in AdaptiveQuadrature, you'd compute the calculations of Q1 and Q2 with something else. I'm not entirely familiar with the apache Math codebase [...] You could file a wish request as a Commons Math's user. Then, if and when some regular contributor finds some time, he will try to implement the functionality. However, when you provide a patch for inclusion in the codebase, it is necessary to be more informed about similar functionality that would already exist in Commons Math, so that the contribution can be merged gracefully (i.e. with minor changes which committers will happily perform for you). You are welcome to ask questions in order to be able to contribute. As I tried to explain in more than one way, modifying your code is far from being trivial. If the committer has to figure out how to change/adapt/comment a significant part of the contribution, it ends up being easier to implement the feature from scratch! Each of the tests in the patch is integrating a UnivariateFunction in [-1,1]. Infinity.wrap(fn) just provides that UnivariateFunction. [In the patches for MATH-995 the InfiniteIntegral was replaced by Infinity.wrap() ]. So, if you are saying that the intent of IterativeLegendreGaussIntegrator (refered to as LGQ) was not to integrate this kind of UnivariateFunction in [-1,1], ... what kind of univariate function would that be? Again, it is not just any UnivariateFunction, it is a function that maps the [-inf, +inf] interval into [-1, 1]. It seems that the Gauss-Legendre quadrature is not appropriate for this. This is probably because the sample integration points do not cover the _whole_ interval: for the 10-point rule, the first point is at -0.9739065285171717 and the last point is at 0.9994069665572084 The interval in the original variable is thus [-18.908, 842.872]. This is far from adequate for integrating a Gaussian function with sigma=1000. [And, as Phil pointed out from the outset, I suspect that the change of variable also introduces numerical errors since the result becomes worse when increasing the number of sample points. Increasing the requested precision leads to a prohibitive increase of the number of evaluations, without improvement of the accuracy. In itself it is not sufficient to indicate a bug of IterativeGaussLegendre; it could simply be a limitation inherent to the algorithm.] If it is indeed supposed to do the integration, then AQ clearly does a better job. Adaptive methods are certainly useful, but we need examples where its usage is appropriate. It is _not_ indicated for the improper integral of a Gaussian (even though it indeed performs better than Gauss-Legendre). So, why does LGQ fail here? It is probably that the Adaptive division of the integration domain (as opposed to the uniform division with LGQ) gives AQ the critical edge. The test you have for LGQ so far are pretty well behaved. Cf. above. AFAIU, the problem reported by MATH-995 is not a bug in IterativeLegendreIntegrator: it correctly integrates a Gaussian with a large sigma _if_ the integration interval is large enough (cf. unit test referred to in my comment to MATH-995). Unless someone can point to something I'm missing in MATH-995, I'll close that issue. Summary: I'm demonstrating a clear bug/inefficiency with LGQ I don't agree with that statement. IterativeGaussLegendre produces the correct answer (at 1e-6 accuracy) in less than 60 function evaluations. To achieve the same, your code needs 995 evaluations. and providing you with an alternative that is more accurate. Cf. above (and my previous post), about how to contribute to Commons Math. Please open a new feature request. Regards, Gilles On Mon, Jul 1, 2013 at 8:22 AM, Gilles gil...@harfang.homelinux.org wrote: Hi. I just noticed your request to write the algorithm along the lines of the wikipedia article. The only major difference between my code and the article on Wikipedia is that I found it necessary to move the recursive stack in into a data structure to avoid a StackOverflowException when the non polynomial curvature is concentrated in a corner of the domain of integration. Notice that the Stack objects stores a Stack of limits of integration. There is a misunderstanding: I'm referring to the high-level description of the algorithm that is the separation of concerns between the quadrature method and the adaptive process. Your code mixes the two. Moreover, it does not reuse any of the quadrature schemes already implemented in CM, but implements a (new?) one without any reference or comments. [And this is even without delving into remarks concerning the code structure itself.] Additionally, your patch also mixes two concepts: Adaptive quadrature vs improper integral (which is also MATH-994); it is hard to follow what problem this issue is supposed to point to, and how the patch
Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
private void proc(UnivariateFunction fn) {
+Calc calc = calcs.pop();// pop a calculation to be done.
+double a = calc.a;
+double b = calc.b;
+
+// back off slightly from the edges (function evaluations typically go
haywire)
+// scale for the edge approximation is set by the resolution.
+if (a == edgeA) {
+a += (b - a) * EPS;
+}
+if (b == edgeB) {
+b -= (b - a) * EPS;
+}
+
+double delta = b - a;
+double m = (a + b) / 2d;
+double ma = (a + m) / 2d;
+double mb = (b + m) / 2d;
+double va = fn.value(a);
+double vb = fn.value(b);
+double vm = fn.value(m);
+double Q1 = delta / 6 * (va + 4 * vm + vb);
+double Q2 = delta / 12 * (va + 4 * fn.value(ma) + 2 * vm + 4 *
fn.value(mb) + vb);
+if (Math.abs(Q2 - Q1) = EPS) {
+total += Q2 + (Q2 - Q1) / 15;
+} else {
+calcs.add(new Calc(a, m));
+calcs.add(new Calc(m, b));
+}
+}
1) You form a new object Calc(a,m) and Calc(m,b), the m point is the same, yet
you evaluate it again when you compute vb and va, respectively, one iteration
down. I think it also repeats for a bunch of other points middle points.
2) I am of the opinion you shouldn't include special behavior unless you have
problem. If you want you can capture if eval returned a NaN and then move the
evaluation point.
3) I am not claiming you shouldn't replace what I wrote with a stack. For my
personal use it didn't matter.
On Jul 1, 2013, at 6:43 PM, Ajo Fod ajo@gmail.com wrote:
1 Could you provide an example of redundant function evaluations in my
code?
2 I made the adjustment in AQ because the size of the segment that was
excluded from the integration could be determined adaptively to keep the
error arbitrarily low. Note the size of the segment that is excluded (at
the edges of the integration domain) can be defined as a function of the
error tolerance. It is unlikely that that exclusion will cause problems for
proper integrals. But it does save the day for when infinities are present
... not a bad trade off if you think about it.
3 BTW, I think your code is a lot like mine ... except that it uses the
program stack ... so it will likely fail at the depth required for
integration of the PDF with sigma=1000.
Cheers,
-Ajo
On Mon, Jul 1, 2013 at 3:17 PM, Konstantin Berlin kber...@gmail.com wrote:
Just a few thoughts.
It seems to me that this code suffers from redundant function evaluations.
I am not sure what to think about the movement from edges since it violates
proper behavior for well behaved functions in order to work for some
special cases. In case of infinite integrals it might be better to create
the initial offset there, rather than in the adaptive quadrature. In any
case the check should be moved out of the inside iteration.
A while back I wrote an adaptive quadrature to evaluation vector
functions, some code can easily be modified into this class. Hope it helps.
/**
* The Class SimpsonVectorQuad.
*/
public final class SimpsonVectorQuad implements UnivariateVectorIntegrator
{
/** The abs point tolerance. */
final double absPointTolerance;
/** The real tolerance. */
final double realTolerance;
/**
* Instantiates a new simpson vector quad.
*
* @param realTolerance
* the real tolerance
*/
public SimpsonVectorQuad(double realTolerance)
{
this(realTolerance,1.0e-8);
}
/**
* Instantiates a new simpson vector quad.
*
* @param realTolerance
* the real tolerance
* @param absPointTolerance
* the abs point tolerance
*/
public SimpsonVectorQuad(double realTolerance, double
absPointTolerance)
{
this.realTolerance = realTolerance;
this.absPointTolerance = absPointTolerance;
}
/* (non-Javadoc)
* @see
edu.umd.umiacs.armor.math.integration.UnivariateVectorIntegrator#integrate(edu.umd.umiacs.armor.math.func.UnivariateVectorFunction,
double, double, int)
*/
@Override
public double[] integrate(UnivariateVectorFunction f, double a,
double b, int maxEvals)
{
IntegratorProperties property = new IntegratorProperties();
property.evalCount = 0;
double h = 0.13579*(b-a);
double[] x = {a, a+h, a+2.0*h, (a+b)*0.5, b-2.0*h, b-h, b};
double[][] y = new double[7][];
for (int iter=0; iterx.length; iter++)
{
y[iter] = f.value(x[iter]);
for (int nanLoop=0; nanLoopy[iter].length; nanLoop++)
if
Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
Hi Gilles, Your accuracy concern made me wonder. So, I dropped the AdaptiveQuadrature.EPS to 1e-2 from 1e-9 in the code and ran the test in the patch. I computed the log of the error per evaluation ...i.e a measure of the efficiency of the algorithm. And wait for it ... AQ beats LGQ by about 5% for the particular formulation of the problem. Your request to use the Math classes falls under coding style IMHO. If it doesn't satisfy your standards, feel free to modify. I'm happy with it. Although as far as accuracy and convergence goes, I'd use AQ always. Got to compare apples to apples Gilles ! Cheers, -Ajo On Mon, Jul 1, 2013 at 4:16 PM, Gilles gil...@harfang.homelinux.org wrote: Hi. On Mon, 1 Jul 2013 10:50:19 -0700, Ajo Fod wrote: If you wanted to use the Math 3 codebase in AdaptiveQuadrature, you'd compute the calculations of Q1 and Q2 with something else. I'm not entirely familiar with the apache Math codebase [...] You could file a wish request as a Commons Math's user. Then, if and when some regular contributor finds some time, he will try to implement the functionality. However, when you provide a patch for inclusion in the codebase, it is necessary to be more informed about similar functionality that would already exist in Commons Math, so that the contribution can be merged gracefully (i.e. with minor changes which committers will happily perform for you). You are welcome to ask questions in order to be able to contribute. As I tried to explain in more than one way, modifying your code is far from being trivial. If the committer has to figure out how to change/adapt/comment a significant part of the contribution, it ends up being easier to implement the feature from scratch! Each of the tests in the patch is integrating a UnivariateFunction in [-1,1]. Infinity.wrap(fn) just provides that UnivariateFunction. [In the patches for MATH-995 the InfiniteIntegral was replaced by Infinity.wrap() ]. So, if you are saying that the intent of IterativeLegendreGaussIntegrat**or (refered to as LGQ) was not to integrate this kind of UnivariateFunction in [-1,1], ... what kind of univariate function would that be? Again, it is not just any UnivariateFunction, it is a function that maps the [-inf, +inf] interval into [-1, 1]. It seems that the Gauss-Legendre quadrature is not appropriate for this. This is probably because the sample integration points do not cover the _whole_ interval: for the 10-point rule, the first point is at -0.9739065285171717 and the last point is at 0.9994069665572084 The interval in the original variable is thus [-18.908, 842.872]. This is far from adequate for integrating a Gaussian function with sigma=1000. [And, as Phil pointed out from the outset, I suspect that the change of variable also introduces numerical errors since the result becomes worse when increasing the number of sample points. Increasing the requested precision leads to a prohibitive increase of the number of evaluations, without improvement of the accuracy. In itself it is not sufficient to indicate a bug of IterativeGaussLegendre; it could simply be a limitation inherent to the algorithm.] If it is indeed supposed to do the integration, then AQ clearly does a better job. Adaptive methods are certainly useful, but we need examples where its usage is appropriate. It is _not_ indicated for the improper integral of a Gaussian (even though it indeed performs better than Gauss-Legendre). So, why does LGQ fail here? It is probably that the Adaptive division of the integration domain (as opposed to the uniform division with LGQ) gives AQ the critical edge. The test you have for LGQ so far are pretty well behaved. Cf. above. AFAIU, the problem reported by MATH-995 is not a bug in IterativeLegendreIntegrator: it correctly integrates a Gaussian with a large sigma _if_ the integration interval is large enough (cf. unit test referred to in my comment to MATH-995). Unless someone can point to something I'm missing in MATH-995, I'll close that issue. Summary: I'm demonstrating a clear bug/inefficiency with LGQ I don't agree with that statement. IterativeGaussLegendre produces the correct answer (at 1e-6 accuracy) in less than 60 function evaluations. To achieve the same, your code needs 995 evaluations. and providing you with an alternative that is more accurate. Cf. above (and my previous post), about how to contribute to Commons Math. Please open a new feature request. Regards, Gilles On Mon, Jul 1, 2013 at 8:22 AM, Gilles gil...@harfang.homelinux.org wrote: Hi. I just noticed your request to write the algorithm along the lines of the wikipedia article. The only major difference between my code and the article on Wikipedia is that I found it necessary to move the recursive stack in into a data structure to avoid a StackOverflowException when the non polynomial curvature is concentrated in a
Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
I am not understanding the discussion here. Adaptive integration is designed for functions that have different behavior in different regions. Some regions are smoother, some have higher frequeniesy. How you integrate a divided region, Simpson rule or whatever is a separate question. Adaptive integration saves of function evaluations by avoiding large series approximation in smooth regions. Nothing to do with how you compute the subdivided regions. On Jul 1, 2013, at 8:45 PM, Fod ajo@gmail.com wrote: Hi Gilles, Your accuracy concern made me wonder. So, I dropped the AdaptiveQuadrature.EPS to 1e-2 from 1e-9 in the code and ran the test in the patch. I computed the log of the error per evaluation ...i.e a measure of the efficiency of the algorithm. And wait for it ... AQ beats LGQ by about 5% for the particular formulation of the problem. Your request to use the Math classes falls under coding style IMHO. If it doesn't satisfy your standards, feel free to modify. I'm happy with it. Although as far as accuracy and convergence goes, I'd use AQ always. Got to compare apples to apples Gilles ! Cheers, -Ajo On Mon, Jul 1, 2013 at 4:16 PM, Gilles gil...@harfang.homelinux.org wrote: Hi. On Mon, 1 Jul 2013 10:50:19 -0700, Ajo Fod wrote: If you wanted to use the Math 3 codebase in AdaptiveQuadrature, you'd compute the calculations of Q1 and Q2 with something else. I'm not entirely familiar with the apache Math codebase [...] You could file a wish request as a Commons Math's user. Then, if and when some regular contributor finds some time, he will try to implement the functionality. However, when you provide a patch for inclusion in the codebase, it is necessary to be more informed about similar functionality that would already exist in Commons Math, so that the contribution can be merged gracefully (i.e. with minor changes which committers will happily perform for you). You are welcome to ask questions in order to be able to contribute. As I tried to explain in more than one way, modifying your code is far from being trivial. If the committer has to figure out how to change/adapt/comment a significant part of the contribution, it ends up being easier to implement the feature from scratch! Each of the tests in the patch is integrating a UnivariateFunction in [-1,1]. Infinity.wrap(fn) just provides that UnivariateFunction. [In the patches for MATH-995 the InfiniteIntegral was replaced by Infinity.wrap() ]. So, if you are saying that the intent of IterativeLegendreGaussIntegrat**or (refered to as LGQ) was not to integrate this kind of UnivariateFunction in [-1,1], ... what kind of univariate function would that be? Again, it is not just any UnivariateFunction, it is a function that maps the [-inf, +inf] interval into [-1, 1]. It seems that the Gauss-Legendre quadrature is not appropriate for this. This is probably because the sample integration points do not cover the _whole_ interval: for the 10-point rule, the first point is at -0.9739065285171717 and the last point is at 0.9994069665572084 The interval in the original variable is thus [-18.908, 842.872]. This is far from adequate for integrating a Gaussian function with sigma=1000. [And, as Phil pointed out from the outset, I suspect that the change of variable also introduces numerical errors since the result becomes worse when increasing the number of sample points. Increasing the requested precision leads to a prohibitive increase of the number of evaluations, without improvement of the accuracy. In itself it is not sufficient to indicate a bug of IterativeGaussLegendre; it could simply be a limitation inherent to the algorithm.] If it is indeed supposed to do the integration, then AQ clearly does a better job. Adaptive methods are certainly useful, but we need examples where its usage is appropriate. It is _not_ indicated for the improper integral of a Gaussian (even though it indeed performs better than Gauss-Legendre). So, why does LGQ fail here? It is probably that the Adaptive division of the integration domain (as opposed to the uniform division with LGQ) gives AQ the critical edge. The test you have for LGQ so far are pretty well behaved. Cf. above. AFAIU, the problem reported by MATH-995 is not a bug in IterativeLegendreIntegrator: it correctly integrates a Gaussian with a large sigma _if_ the integration interval is large enough (cf. unit test referred to in my comment to MATH-995). Unless someone can point to something I'm missing in MATH-995, I'll close that issue. Summary: I'm demonstrating a clear bug/inefficiency with LGQ I don't agree with that statement. IterativeGaussLegendre produces the correct answer (at 1e-6 accuracy) in less than 60 function evaluations. To achieve the same, your code needs 995 evaluations. and providing you with an alternative that is more accurate. Cf. above (and my previous post), about how to
Re: [VOTE] Release of Commons Collections 4.0-alpha1 based on RC2
Do we have 2 way hashmap in collections? If not i think we shuld have it On Tue, Jul 2, 2013 at 1:24 AM, Oliver Heger oliver.he...@oliver-heger.dewrote: +1 Oliver Am 30.06.2013 23:57, schrieb Thomas Neidhart: Hi, I'd like to call a vote for releasing Commons Collections 4.0-alpha1 based on RC2. The following changes have been applied since RC1: * upgrade to maven-javadoc-plugin 2.9.1 (due to CVE-2013-1571) * fixed COLLECTIONS-474, thanks to sebb * fixed download page (contained wrong component id) * added html version of release notes for site The artifacts / site have been built with Oracle JDK 1.5 build 1.5.0_22-b03. The files: The artifacts are deployed to Nexus: https://repository.apache.org/**content/repositories/** orgapachecommons-092/org/**apache/commons/commons-** collections4/4.0-alpha1/https://repository.apache.org/content/repositories/orgapachecommons-092/org/apache/commons/commons-collections4/4.0-alpha1/ Distribution files: https://dist.apache.org/repos/**dist/dev/commons/collections/https://dist.apache.org/repos/dist/dev/commons/collections/ The tag: https://svn.apache.org/repos/**asf/commons/proper/** collections/tags/COLLECTIONS_**4_0_ALPHA1_RC2/https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_ALPHA1_RC2/ The site: http://people.apache.org/**builds/commons/collections/4.**0-alpha1/RC2/http://people.apache.org/builds/commons/collections/4.0-alpha1/RC2/ Additional Notes: o the download page and api links to older releases only work on the published site and will be corrected after release. Please take a look at the commons-collections-4.0-alpha1 artifacts and vote! --**-- [ ] +1 release it. [ ] +0 go ahead; I don't care. [ ] -0 there are a few minor glitches: ... [ ] -1 no, do not release it because ... --**-- Vote will remain open for at least 72 hours. Thanks in advance, Thomas --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Anshul Zunke
Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
Hi Konstantin, Thanks for pointing out the inefficiency in AQ. I just improved the efficiency of AQ to 1.41x that of LGQ (up from 1.05x) - measured in digits of accuracy per evaluation for integral of normal with sigma 1000 in range [-5000, 5000] Please let me know if this doesn't answer your question about the discussion: In essence Gilles thinks there is no problem with LGQ because it integrates the low frequency functions in his unit tests accurately. He thinks that the problem is with the function I provided because it has numerical instabilities while I think it is the high frequency nature of the function that LGQ can't handle because it divides intervals indiscriminately. So, it is not clear to me how Gilles explains why AQ converges to the right answer in the presence of these numerical instabilities ... after all, LGQ and AQ are being passed the same function and identical limits. This problem should appear with any function that has sufficiently high frequency components. It would be better if LGQ threw an exception when it encounters a high frequency function. Instead, it converges confidently to the wrong answer. I personally think that AQ will fail at some point at a high enough frequency ... but that will be well beyond the point at which LGQ fails. I've avoided the complex method of fetching weights used in the current schemes because the improvement in efficiency arises from the adaptive nature of the AQ method. You may notice that I'm using the weights that you use in your code. I think Gilles requires that I use the weight generation scheme he has worked with in the codebase in order to consider the code usable in Apache MATH. In summary, I feel the accuracy and versatility of AQ are being ignored in favor of the familiarity of LGQ in the apache codebase. If there are tests that AQ fails, I'll update my opinion. Cheers, Ajo On Mon, Jul 1, 2013 at 6:49 PM, Konstantin Berlin kber...@gmail.com wrote: I am not understanding the discussion here. Adaptive integration is designed for functions that have different behavior in different regions. Some regions are smoother, some have higher frequeniesy. How you integrate a divided region, Simpson rule or whatever is a separate question. Adaptive integration saves of function evaluations by avoiding large series approximation in smooth regions. Nothing to do with how you compute the subdivided regions. On Jul 1, 2013, at 8:45 PM, Fod ajo@gmail.com wrote: Hi Gilles, Your accuracy concern made me wonder. So, I dropped the AdaptiveQuadrature.EPS to 1e-2 from 1e-9 in the code and ran the test in the patch. I computed the log of the error per evaluation ...i.e a measure of the efficiency of the algorithm. And wait for it ... AQ beats LGQ by about 5% for the particular formulation of the problem. Your request to use the Math classes falls under coding style IMHO. If it doesn't satisfy your standards, feel free to modify. I'm happy with it. Although as far as accuracy and convergence goes, I'd use AQ always. Got to compare apples to apples Gilles ! Cheers, -Ajo On Mon, Jul 1, 2013 at 4:16 PM, Gilles gil...@harfang.homelinux.org wrote: Hi. On Mon, 1 Jul 2013 10:50:19 -0700, Ajo Fod wrote: If you wanted to use the Math 3 codebase in AdaptiveQuadrature, you'd compute the calculations of Q1 and Q2 with something else. I'm not entirely familiar with the apache Math codebase [...] You could file a wish request as a Commons Math's user. Then, if and when some regular contributor finds some time, he will try to implement the functionality. However, when you provide a patch for inclusion in the codebase, it is necessary to be more informed about similar functionality that would already exist in Commons Math, so that the contribution can be merged gracefully (i.e. with minor changes which committers will happily perform for you). You are welcome to ask questions in order to be able to contribute. As I tried to explain in more than one way, modifying your code is far from being trivial. If the committer has to figure out how to change/adapt/comment a significant part of the contribution, it ends up being easier to implement the feature from scratch! Each of the tests in the patch is integrating a UnivariateFunction in [-1,1]. Infinity.wrap(fn) just provides that UnivariateFunction. [In the patches for MATH-995 the InfiniteIntegral was replaced by Infinity.wrap() ]. So, if you are saying that the intent of IterativeLegendreGaussIntegrat**or (refered to as LGQ) was not to integrate this kind of UnivariateFunction in [-1,1], ... what kind of univariate function would that be? Again, it is not just any UnivariateFunction, it is a function that maps the [-inf, +inf] interval into [-1, 1]. It seems that the Gauss-Legendre quadrature is not appropriate for this. This is probably because the sample integration
Re: [VOTE] Release of Commons Collections 4.0-alpha1 based on RC2
+1 Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500) Maven home: C:\Java\apache-maven-3.0.5\bin\.. Java version: 1.7.0_25, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_25\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Gary On Sun, Jun 30, 2013 at 5:57 PM, Thomas Neidhart thomas.neidh...@gmail.comwrote: Hi, I'd like to call a vote for releasing Commons Collections 4.0-alpha1 based on RC2. The following changes have been applied since RC1: * upgrade to maven-javadoc-plugin 2.9.1 (due to CVE-2013-1571) * fixed COLLECTIONS-474, thanks to sebb * fixed download page (contained wrong component id) * added html version of release notes for site The artifacts / site have been built with Oracle JDK 1.5 build 1.5.0_22-b03. The files: The artifacts are deployed to Nexus: https://repository.apache.org/content/repositories/orgapachecommons-092/org/apache/commons/commons-collections4/4.0-alpha1/ Distribution files: https://dist.apache.org/repos/dist/dev/commons/collections/ The tag: https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_ALPHA1_RC2/ The site: http://people.apache.org/builds/commons/collections/4.0-alpha1/RC2/ Additional Notes: o the download page and api links to older releases only work on the published site and will be corrected after release. Please take a look at the commons-collections-4.0-alpha1 artifacts and vote! [ ] +1 release it. [ ] +0 go ahead; I don't care. [ ] -0 there are a few minor glitches: ... [ ] -1 no, do not release it because ... Vote will remain open for at least 72 hours. Thanks in advance, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
