You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2009/07/31 01:55:35 UTC
[VOTE] Release Math 2.0
The release distributions are here:
http://people.apache.org/~psteitz/commons-math-2.0-RC3/
The tag is here:
http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
Thanks!
Phil
---------------------------------------------------------------------
[ ] +1
[ ] +0
[ ] -0
[ ] -1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
luc.maisonobe@free.fr wrote:
>
> ----- "Jörg Schaible" <jo...@gmx.de> a écrit :
[snip]
>> > Could you try again to add the print and play with the costAccuracy
>> > setting ? This setting is a multiplicative factor for the printed
>> > threshold and this threshold is checked against the printed delta
>> which
>> > should not change when you change the setting.
>>
>> With 2.08e-8 for the costAccuracy I get the sysout, with 2.09e-8 no
>> longer.
>
> This means the test should succeed if the costAccuracy is set to a value
> greater than 2.09e-8 then. So if it fails at 1.0e-6, the failure is
> probably elsewhere.
>
> I don't know jrockit, is it possible to install it freely as a standalone
> JVM without oracle on a Linux host ?
All links are meanwhile dead to download it separately. Maybe we're beating
here a dead horse with this version. Oracle has newer JRockit versions for
JDK 1.4.2, 1.5 and 1.6, but only included in some big bundles :-/
Somehow I get the impression that they are no longer very interested in
compatibility checks with their software ... I wait for the day when the
Sun JDK is also only available as bundle with Glassfish and NetBeans.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by sebb <se...@gmail.com>.
Just tried "mvn clean test" with
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
BEA JRockit(R) (build
R27.6.3-40_o-112056-1.6.0_11-20090318-2104-windows-ia32, compiled
mode)
No errors reported.
On 04/08/2009, sebb <se...@gmail.com> wrote:
> http://www.oracle.com/technology/products/jrockit/index.html
>
>
>
> On 04/08/2009, Dimitri Pourbaix <po...@astro.ulb.ac.be> wrote:
> > Luc,
> >
> >
> > > I don't know jrockit, is it possible to install it freely as a
> > > standalone JVM without oracle on a Linux host ?
> > >
> >
> > In the past (about 2 years ago), it was freely available as a standa-
> > lone JVM on Linux platform (faster than Sun for number crunching applica-
> > tions). I looked again one month ago and could not quickly find it so I
> > do not its present status.
> >
> > Regards,
> > Dim.
> > ----------------------------------------------------------------------------
> > Dimitri Pourbaix *
> > Institut d'Astronomie et d'Astrophysique * Don't worry, be happy
> > CP 226, office 2.N4.211, building NO * and CARPE DIEM.
> > Universite Libre de Bruxelles *
> > Boulevard du Triomphe * Tel : +32-2-650.35.71
> > B-1050 Bruxelles * Fax : +32-2-650.42.26
> > http://sb9.astro.ulb.ac.be/~pourbaix *
> > mailto:pourbaix@astro.ulb.ac.be
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by sebb <se...@gmail.com>.
http://www.oracle.com/technology/products/jrockit/index.html
On 04/08/2009, Dimitri Pourbaix <po...@astro.ulb.ac.be> wrote:
> Luc,
>
>
> > I don't know jrockit, is it possible to install it freely as a
> > standalone JVM without oracle on a Linux host ?
> >
>
> In the past (about 2 years ago), it was freely available as a standa-
> lone JVM on Linux platform (faster than Sun for number crunching applica-
> tions). I looked again one month ago and could not quickly find it so I
> do not its present status.
>
> Regards,
> Dim.
> ----------------------------------------------------------------------------
> Dimitri Pourbaix *
> Institut d'Astronomie et d'Astrophysique * Don't worry, be happy
> CP 226, office 2.N4.211, building NO * and CARPE DIEM.
> Universite Libre de Bruxelles *
> Boulevard du Triomphe * Tel : +32-2-650.35.71
> B-1050 Bruxelles * Fax : +32-2-650.42.26
> http://sb9.astro.ulb.ac.be/~pourbaix *
> mailto:pourbaix@astro.ulb.ac.be
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Dimitri Pourbaix <po...@astro.ulb.ac.be>.
Luc,
> I don't know jrockit, is it possible to install it freely as a
> standalone JVM without oracle on a Linux host ?
In the past (about 2 years ago), it was freely available as a standa-
lone JVM on Linux platform (faster than Sun for number crunching applica-
tions). I looked again one month ago and could not quickly find it so I
do not its present status.
Regards,
Dim.
----------------------------------------------------------------------------
Dimitri Pourbaix *
Institut d'Astronomie et d'Astrophysique * Don't worry, be happy
CP 226, office 2.N4.211, building NO * and CARPE DIEM.
Universite Libre de Bruxelles *
Boulevard du Triomphe * Tel : +32-2-650.35.71
B-1050 Bruxelles * Fax : +32-2-650.42.26
http://sb9.astro.ulb.ac.be/~pourbaix * mailto:pourbaix@astro.ulb.ac.be
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by lu...@free.fr.
----- "Jörg Schaible" <jo...@gmx.de> a écrit :
> Luc Maisonobe wrote:
>
> > Jörg Schaible a écrit :
> >> Hi Luc,
> >>
> >> Luc Maisonobe wrote:
> >>
> >>> Jörg Schaible a écrit :
> >>>> Hi Luc,
> >>>>
> >>>> Luc Maisonobe wrote:
> >>>>
> >>>>> Jörg Schaible a écrit :
> >>>>>> Hi Luc,
> >>>>>>
> >>>> [snip]
> >>>>
> >>>>>> we're definitely on the right track. After changing the loop
> in
> >>>>>> TestProblem3 the tests run through. However, now I have two
> failing
> >>>>>> tests:
> >>>>> The two tests are in fact the same test repeated. The first
> occurrence
> >>>>> is in the deprecated package estimation which will be removed at
> some
> >>>>> point in the future and the second test is in the new
> >>>>> optimization.general package.
> >>>>>
> >>>>> Could you change in the MinPackTest.java from either package
> the
> >>>>> checkTheoreticalMinCost method to add a print statement as in
> the
> >>>>> example below and send the result you get when running
> MinPackTest ?
> >>>>>
> >>>>>
> >>>>> public boolean checkTheoreticalMinCost(double rms) {
> >>>>> double threshold = costAccuracy * (1.0 + theoreticalMinCost);
> >>>>> if (Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) >
> threshold) {
> >>>>> System.out.println("rms = " + rms +
> >>>>> ", m = " + m +
> >>>>> ", sqrt(m)*rms = " +
> >>>>> Math.abs(Math.sqrt(m) * rms) +
> >>>>> ", threshold = " + threshold +
> >>>>> ", delta = " +
> >>>>> Math.abs(Math.sqrt(m) * rms -
> >>>>> theoreticalMinCost));
> >>>>> }
> >>>>> return Math.abs(Math.sqrt(m) * rms - theoreticalMinCost)
> <=
> >>>>> threshold;
> >>>>> }
> >>>>>
> >>>>> I guess I simply put too tight thresholds in the tests and that
> >>>>> numerical instability or different optimizations in JVMs may
> change
> >>>>> the result and break the test. The previous print statement
> would
> >>>>> allow me to compare the numerical values with what I get here
> and
> >>>>> decide if the results are acceptable and the test threshold must
> be
> >>>>> enlarged or if there is a real problem here.
> >>>> rms = 65.50657291427613,
> >>>> m = 20,
> >>>> sqrt(m)*rms = 292.9543000187359,
> >>>> threshold = 2.93954306151134E-6,
> >>>> delta = 6.132398084446322E-6
> >>> These results are good. The default threshold for cost accuracy is
> set
> >>> to 1.0e-8, which is too tight for this case. I have checked in a
> >>> modification in the constructor of the BrownDennisFunction
> internal
> >>> class in both MinPackTest (just added setCostAccuracy(2.5e-8)).
> Could
> >>> you either look if the current code in subversion trunk works for
> you or
> >>> add the call to setCostAccuracy in both constructors ?
> >>
> >> I've checked out the trunk now, but no cigar yet:
> >>
> >> ========= %< =============
> >> junit.framework.AssertionFailedError: null
> >> at junit.framework.Assert.fail(Assert.java:47)
> >> at junit.framework.Assert.assertTrue(Assert.java:20)
> >> at junit.framework.Assert.assertTrue(Assert.java:27)
> >> at
> >>
> org.apache.commons.math.optimization.general.MinpackTest.minpackTest(MinpackTest.java:505)
> >> at
> >>
> org.apache.commons.math.optimization.general.MinpackTest.testMinpackBrownDennis(MinpackTest.java:349)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> >> at
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >> at
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >> at java.lang.reflect.Method.invoke(Method.java:585)
> >> at junit.framework.TestCase.runTest(TestCase.java:168)
> >> at junit.framework.TestCase.runBare(TestCase.java:134)
> >> at
> junit.framework.TestResult$1.protect(TestResult.java:110)
> >> at
> junit.framework.TestResult.runProtected(TestResult.java:128)
> >> at junit.framework.TestResult.run(TestResult.java:113)
> >> at junit.framework.TestCase.run(TestCase.java:124)
> >> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> >> at junit.framework.TestSuite.run(TestSuite.java:227)
> >> at
> >>
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
> >> at
> >>
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
> >> at
> >>
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> >> at
> >>
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> >> at
> >>
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> >> at
> >>
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> >> at
> >>
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> >> ========= %< =============
> >>
> >> I tried meanwhile with 1.0e-6, but it fails still. So it seems
> there's
> >> something else not working with JRockit :-/
> >
> > Do you have only the case in optimization.general that fails or the
> one
> > in estimation fails also ? They really should behave the same since
> they
> > really do almost exactly the same computations ?
>
> They fail both in the same way, I simply did not repeat the stack
> trace.
>
> > Could you try again to add the print and play with the costAccuracy
> > setting ? This setting is a multiplicative factor for the printed
> > threshold and this threshold is checked against the printed delta
> which
> > should not change when you change the setting.
>
> With 2.08e-8 for the costAccuracy I get the sysout, with 2.09e-8 no
> longer.
This means the test should succeed if the costAccuracy is set to a value greater than 2.09e-8 then. So if it fails at 1.0e-6, the failure is probably elsewhere.
I don't know jrockit, is it possible to install it freely as a standalone JVM without oracle on a Linux host ?
Luc
>
> 2.08e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms =
> 292.9543000187359,
> threshold = 6.114249567943588E-6, delta = 6.132398084446322E-6
> 2.05e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms =
> 292.9543000187359,
> threshold = 6.026063276098247E-6, delta = 6.132398084446322E-6
> 2.00e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms =
> 292.9543000187359,
> threshold = 5.87908612302268E-6, delta = 6.132398084446322E-6
> 1.50e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms =
> 292.9543000187359,
> threshold = 4.40931459226701E-6, delta = 6.132398084446322E-6
> 1.00e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms =
> 292.9543000187359,
> threshold = 2.93954306151134E-6, delta = 6.132398084446322E-6
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Luc Maisonobe wrote:
> Jörg Schaible a écrit :
>> Hi Luc,
>>
>> Luc Maisonobe wrote:
>>
>>> Jörg Schaible a écrit :
>>>> Hi Luc,
>>>>
>>>> Luc Maisonobe wrote:
>>>>
>>>>> Jörg Schaible a écrit :
>>>>>> Hi Luc,
>>>>>>
>>>> [snip]
>>>>
>>>>>> we're definitely on the right track. After changing the loop in
>>>>>> TestProblem3 the tests run through. However, now I have two failing
>>>>>> tests:
>>>>> The two tests are in fact the same test repeated. The first occurrence
>>>>> is in the deprecated package estimation which will be removed at some
>>>>> point in the future and the second test is in the new
>>>>> optimization.general package.
>>>>>
>>>>> Could you change in the MinPackTest.java from either package the
>>>>> checkTheoreticalMinCost method to add a print statement as in the
>>>>> example below and send the result you get when running MinPackTest ?
>>>>>
>>>>>
>>>>> public boolean checkTheoreticalMinCost(double rms) {
>>>>> double threshold = costAccuracy * (1.0 + theoreticalMinCost);
>>>>> if (Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) > threshold) {
>>>>> System.out.println("rms = " + rms +
>>>>> ", m = " + m +
>>>>> ", sqrt(m)*rms = " +
>>>>> Math.abs(Math.sqrt(m) * rms) +
>>>>> ", threshold = " + threshold +
>>>>> ", delta = " +
>>>>> Math.abs(Math.sqrt(m) * rms -
>>>>> theoreticalMinCost));
>>>>> }
>>>>> return Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) <=
>>>>> threshold;
>>>>> }
>>>>>
>>>>> I guess I simply put too tight thresholds in the tests and that
>>>>> numerical instability or different optimizations in JVMs may change
>>>>> the result and break the test. The previous print statement would
>>>>> allow me to compare the numerical values with what I get here and
>>>>> decide if the results are acceptable and the test threshold must be
>>>>> enlarged or if there is a real problem here.
>>>> rms = 65.50657291427613,
>>>> m = 20,
>>>> sqrt(m)*rms = 292.9543000187359,
>>>> threshold = 2.93954306151134E-6,
>>>> delta = 6.132398084446322E-6
>>> These results are good. The default threshold for cost accuracy is set
>>> to 1.0e-8, which is too tight for this case. I have checked in a
>>> modification in the constructor of the BrownDennisFunction internal
>>> class in both MinPackTest (just added setCostAccuracy(2.5e-8)). Could
>>> you either look if the current code in subversion trunk works for you or
>>> add the call to setCostAccuracy in both constructors ?
>>
>> I've checked out the trunk now, but no cigar yet:
>>
>> ========= %< =============
>> junit.framework.AssertionFailedError: null
>> at junit.framework.Assert.fail(Assert.java:47)
>> at junit.framework.Assert.assertTrue(Assert.java:20)
>> at junit.framework.Assert.assertTrue(Assert.java:27)
>> at
>>
org.apache.commons.math.optimization.general.MinpackTest.minpackTest(MinpackTest.java:505)
>> at
>>
org.apache.commons.math.optimization.general.MinpackTest.testMinpackBrownDennis(MinpackTest.java:349)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at junit.framework.TestCase.runTest(TestCase.java:168)
>> at junit.framework.TestCase.runBare(TestCase.java:134)
>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>> at junit.framework.TestResult.runProtected(TestResult.java:128)
>> at junit.framework.TestResult.run(TestResult.java:113)
>> at junit.framework.TestCase.run(TestCase.java:124)
>> at junit.framework.TestSuite.runTest(TestSuite.java:232)
>> at junit.framework.TestSuite.run(TestSuite.java:227)
>> at
>>
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
>> at
>>
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
>> at
>>
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>> at
>>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>> at
>>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>> at
>>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>> at
>>
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>> ========= %< =============
>>
>> I tried meanwhile with 1.0e-6, but it fails still. So it seems there's
>> something else not working with JRockit :-/
>
> Do you have only the case in optimization.general that fails or the one
> in estimation fails also ? They really should behave the same since they
> really do almost exactly the same computations ?
They fail both in the same way, I simply did not repeat the stack trace.
> Could you try again to add the print and play with the costAccuracy
> setting ? This setting is a multiplicative factor for the printed
> threshold and this threshold is checked against the printed delta which
> should not change when you change the setting.
With 2.08e-8 for the costAccuracy I get the sysout, with 2.09e-8 no longer.
2.08e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms = 292.9543000187359,
threshold = 6.114249567943588E-6, delta = 6.132398084446322E-6
2.05e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms = 292.9543000187359,
threshold = 6.026063276098247E-6, delta = 6.132398084446322E-6
2.00e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms = 292.9543000187359,
threshold = 5.87908612302268E-6, delta = 6.132398084446322E-6
1.50e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms = 292.9543000187359,
threshold = 4.40931459226701E-6, delta = 6.132398084446322E-6
1.00e-8: rms = 65.50657291427613, m = 20, sqrt(m)*rms = 292.9543000187359,
threshold = 2.93954306151134E-6, delta = 6.132398084446322E-6
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Luc Maisonobe <Lu...@free.fr>.
Jörg Schaible a écrit :
> Hi Luc,
>
> Luc Maisonobe wrote:
>
>> Jörg Schaible a écrit :
>>> Hi Luc,
>>>
>>> Luc Maisonobe wrote:
>>>
>>>> Jörg Schaible a écrit :
>>>>> Hi Luc,
>>>>>
>>> [snip]
>>>
>>>>> we're definitely on the right track. After changing the loop in
>>>>> TestProblem3 the tests run through. However, now I have two failing
>>>>> tests:
>>>> The two tests are in fact the same test repeated. The first occurrence
>>>> is in the deprecated package estimation which will be removed at some
>>>> point in the future and the second test is in the new
>>>> optimization.general package.
>>>>
>>>> Could you change in the MinPackTest.java from either package the
>>>> checkTheoreticalMinCost method to add a print statement as in the
>>>> example below and send the result you get when running MinPackTest ?
>>>>
>>>>
>>>> public boolean checkTheoreticalMinCost(double rms) {
>>>> double threshold = costAccuracy * (1.0 + theoreticalMinCost);
>>>> if (Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) > threshold) {
>>>> System.out.println("rms = " + rms +
>>>> ", m = " + m +
>>>> ", sqrt(m)*rms = " +
>>>> Math.abs(Math.sqrt(m) * rms) +
>>>> ", threshold = " + threshold +
>>>> ", delta = " +
>>>> Math.abs(Math.sqrt(m) * rms -
>>>> theoreticalMinCost));
>>>> }
>>>> return Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) <=
>>>> threshold;
>>>> }
>>>>
>>>> I guess I simply put too tight thresholds in the tests and that
>>>> numerical instability or different optimizations in JVMs may change the
>>>> result and break the test. The previous print statement would allow me
>>>> to compare the numerical values with what I get here and decide if the
>>>> results are acceptable and the test threshold must be enlarged or if
>>>> there is a real problem here.
>>> rms = 65.50657291427613,
>>> m = 20,
>>> sqrt(m)*rms = 292.9543000187359,
>>> threshold = 2.93954306151134E-6,
>>> delta = 6.132398084446322E-6
>> These results are good. The default threshold for cost accuracy is set
>> to 1.0e-8, which is too tight for this case. I have checked in a
>> modification in the constructor of the BrownDennisFunction internal
>> class in both MinPackTest (just added setCostAccuracy(2.5e-8)). Could
>> you either look if the current code in subversion trunk works for you or
>> add the call to setCostAccuracy in both constructors ?
>
> I've checked out the trunk now, but no cigar yet:
>
> ========= %< =============
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at junit.framework.Assert.assertTrue(Assert.java:27)
> at
> org.apache.commons.math.optimization.general.MinpackTest.minpackTest(MinpackTest.java:505)
> at
> org.apache.commons.math.optimization.general.MinpackTest.testMinpackBrownDennis(MinpackTest.java:349)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> ========= %< =============
>
> I tried meanwhile with 1.0e-6, but it fails still. So it seems there's
> something else not working with JRockit :-/
Do you have only the case in optimization.general that fails or the one
in estimation fails also ? They really should behave the same since they
really do almost exactly the same computations ?
Could you try again to add the print and play with the costAccuracy
setting ? This setting is a multiplicative factor for the printed
threshold and this threshold is checked against the printed delta which
should not change when you change the setting.
Luc
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Luc,
Luc Maisonobe wrote:
> Jörg Schaible a écrit :
>> Hi Luc,
>>
>> Luc Maisonobe wrote:
>>
>>> Jörg Schaible a écrit :
>>>> Hi Luc,
>>>>
>> [snip]
>>
>>>> we're definitely on the right track. After changing the loop in
>>>> TestProblem3 the tests run through. However, now I have two failing
>>>> tests:
>>> The two tests are in fact the same test repeated. The first occurrence
>>> is in the deprecated package estimation which will be removed at some
>>> point in the future and the second test is in the new
>>> optimization.general package.
>>>
>>> Could you change in the MinPackTest.java from either package the
>>> checkTheoreticalMinCost method to add a print statement as in the
>>> example below and send the result you get when running MinPackTest ?
>>>
>>>
>>> public boolean checkTheoreticalMinCost(double rms) {
>>> double threshold = costAccuracy * (1.0 + theoreticalMinCost);
>>> if (Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) > threshold) {
>>> System.out.println("rms = " + rms +
>>> ", m = " + m +
>>> ", sqrt(m)*rms = " +
>>> Math.abs(Math.sqrt(m) * rms) +
>>> ", threshold = " + threshold +
>>> ", delta = " +
>>> Math.abs(Math.sqrt(m) * rms -
>>> theoreticalMinCost));
>>> }
>>> return Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) <=
>>> threshold;
>>> }
>>>
>>> I guess I simply put too tight thresholds in the tests and that
>>> numerical instability or different optimizations in JVMs may change the
>>> result and break the test. The previous print statement would allow me
>>> to compare the numerical values with what I get here and decide if the
>>> results are acceptable and the test threshold must be enlarged or if
>>> there is a real problem here.
>>
>> rms = 65.50657291427613,
>> m = 20,
>> sqrt(m)*rms = 292.9543000187359,
>> threshold = 2.93954306151134E-6,
>> delta = 6.132398084446322E-6
>
> These results are good. The default threshold for cost accuracy is set
> to 1.0e-8, which is too tight for this case. I have checked in a
> modification in the constructor of the BrownDennisFunction internal
> class in both MinPackTest (just added setCostAccuracy(2.5e-8)). Could
> you either look if the current code in subversion trunk works for you or
> add the call to setCostAccuracy in both constructors ?
I've checked out the trunk now, but no cigar yet:
========= %< =============
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
org.apache.commons.math.optimization.general.MinpackTest.minpackTest(MinpackTest.java:505)
at
org.apache.commons.math.optimization.general.MinpackTest.testMinpackBrownDennis(MinpackTest.java:349)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
========= %< =============
I tried meanwhile with 1.0e-6, but it fails still. So it seems there's
something else not working with JRockit :-/
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Luc Maisonobe <Lu...@free.fr>.
Jörg Schaible a écrit :
> Hi Luc,
>
> Luc Maisonobe wrote:
>
>> Jörg Schaible a écrit :
>>> Hi Luc,
>>>
> [snip]
>
>>> we're definitely on the right track. After changing the loop in
>>> TestProblem3 the tests run through. However, now I have two failing
>>> tests:
>> The two tests are in fact the same test repeated. The first occurrence
>> is in the deprecated package estimation which will be removed at some
>> point in the future and the second test is in the new
>> optimization.general package.
>>
>> Could you change in the MinPackTest.java from either package the
>> checkTheoreticalMinCost method to add a print statement as in the
>> example below and send the result you get when running MinPackTest ?
>>
>>
>> public boolean checkTheoreticalMinCost(double rms) {
>> double threshold = costAccuracy * (1.0 + theoreticalMinCost);
>> if (Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) > threshold) {
>> System.out.println("rms = " + rms +
>> ", m = " + m +
>> ", sqrt(m)*rms = " +
>> Math.abs(Math.sqrt(m) * rms) +
>> ", threshold = " + threshold +
>> ", delta = " +
>> Math.abs(Math.sqrt(m) * rms -
>> theoreticalMinCost));
>> }
>> return Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) <=
>> threshold;
>> }
>>
>> I guess I simply put too tight thresholds in the tests and that
>> numerical instability or different optimizations in JVMs may change the
>> result and break the test. The previous print statement would allow me
>> to compare the numerical values with what I get here and decide if the
>> results are acceptable and the test threshold must be enlarged or if
>> there is a real problem here.
>
> rms = 65.50657291427613,
> m = 20,
> sqrt(m)*rms = 292.9543000187359,
> threshold = 2.93954306151134E-6,
> delta = 6.132398084446322E-6
These results are good. The default threshold for cost accuracy is set
to 1.0e-8, which is too tight for this case. I have checked in a
modification in the constructor of the BrownDennisFunction internal
class in both MinPackTest (just added setCostAccuracy(2.5e-8)). Could
you either look if the current code in subversion trunk works for you or
add the call to setCostAccuracy in both constructors ?
thanks
Luc
>
> Hope this helps,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Luc,
Luc Maisonobe wrote:
> Jörg Schaible a écrit :
>> Hi Luc,
>>
[snip]
>> we're definitely on the right track. After changing the loop in
>> TestProblem3 the tests run through. However, now I have two failing
>> tests:
>
> The two tests are in fact the same test repeated. The first occurrence
> is in the deprecated package estimation which will be removed at some
> point in the future and the second test is in the new
> optimization.general package.
>
> Could you change in the MinPackTest.java from either package the
> checkTheoreticalMinCost method to add a print statement as in the
> example below and send the result you get when running MinPackTest ?
>
>
> public boolean checkTheoreticalMinCost(double rms) {
> double threshold = costAccuracy * (1.0 + theoreticalMinCost);
> if (Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) > threshold) {
> System.out.println("rms = " + rms +
> ", m = " + m +
> ", sqrt(m)*rms = " +
> Math.abs(Math.sqrt(m) * rms) +
> ", threshold = " + threshold +
> ", delta = " +
> Math.abs(Math.sqrt(m) * rms -
> theoreticalMinCost));
> }
> return Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) <=
> threshold;
> }
>
> I guess I simply put too tight thresholds in the tests and that
> numerical instability or different optimizations in JVMs may change the
> result and break the test. The previous print statement would allow me
> to compare the numerical values with what I get here and decide if the
> results are acceptable and the test threshold must be enlarged or if
> there is a real problem here.
rms = 65.50657291427613,
m = 20,
sqrt(m)*rms = 292.9543000187359,
threshold = 2.93954306151134E-6,
delta = 6.132398084446322E-6
Hope this helps,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Luc Maisonobe <Lu...@free.fr>.
Jörg Schaible a écrit :
> Hi Luc,
>
> Luc Maisonobe wrote:
>
>> Luc Maisonobe a écrit :
>>> Jörg Schaible a écrit :
>>>> Hi Phil,
>>>>
>>>> tried the source package with my compiler zoo. Sun JDKs and icedtea6
>>>> take roughly 1 min to compile, test and build the jar. IBM JDK 1.6 takes
>>>> about 3 mins ... are math operations so bad with this JVM? However, with
>>>> JRockit 1.5 the test hangs forever in
>>>> org.apache.commons.math.ode.nonstiff.GraggBulirschStoerIntegratorTest
>>>> and I have to kill it after several minutes (verified twice). Can
>>>> someone else confirm?
>>> Could you tell which test fails in the Gragg Bulirsch Stoer set (there
>>> are 10 tests for it) ?
>>>
>>> could you try to add this statement to the failing test, sometimes
>>> before the call to integrate ?
>>>
>>> integ.setMaxEvaluations(100000);
>>>
>>> This could prevent a possible infinite loop but will lead the test to
>>> fail with an exception when the maximal number of evaluations is reached.
>> Maybe it is the same problem that was encountered while releasing 1.2
>> <http://markmail.org/message/bbodv6uhv4a5e4ky> ? Could you try the fix I
>> proposed in the referenced message ?
>
> we're definitely on the right track. After changing the loop in TestProblem3
> the tests run through. However, now I have two failing tests:
The two tests are in fact the same test repeated. The first occurrence
is in the deprecated package estimation which will be removed at some
point in the future and the second test is in the new
optimization.general package.
Could you change in the MinPackTest.java from either package the
checkTheoreticalMinCost method to add a print statement as in the
example below and send the result you get when running MinPackTest ?
public boolean checkTheoreticalMinCost(double rms) {
double threshold = costAccuracy * (1.0 + theoreticalMinCost);
if (Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) > threshold) {
System.out.println("rms = " + rms +
", m = " + m +
", sqrt(m)*rms = " +
Math.abs(Math.sqrt(m) * rms) +
", threshold = " + threshold +
", delta = " +
Math.abs(Math.sqrt(m) * rms -
theoreticalMinCost));
}
return Math.abs(Math.sqrt(m) * rms - theoreticalMinCost) <=
threshold;
}
I guess I simply put too tight thresholds in the tests and that
numerical instability or different optimizations in JVMs may change the
result and break the test. The previous print statement would allow me
to compare the numerical values with what I get here and decide if the
results are acceptable and the test threshold must be enlarged or if
there is a real problem here.
Thanks,
Luc
>
> ================ %< ===============
> Failed tests:
> testMinpackBrownDennis(org.apache.commons.math.estimation.MinpackTest)
>
> testMinpackBrownDennis(org.apache.commons.math.optimization.general.MinpackTest)
> ================ %< ===============
> -------------------------------------------------------------------------------
> Test set: org.apache.commons.math.estimation.MinpackTest
> -------------------------------------------------------------------------------
> Tests run: 18, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.468 sec
> <<< FAILURE!
> testMinpackBrownDennis(org.apache.commons.math.estimation.MinpackTest) Time
> elapsed: 0.411 sec <<< FAILURE!
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at junit.framework.Assert.assertTrue(Assert.java:27)
> at
> org.apache.commons.math.estimation.MinpackTest.minpackTest(MinpackTest.java:503)
> at
> org.apache.commons.math.estimation.MinpackTest.testMinpackBrownDennis(MinpackTest.java:348)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> ================ %< ===============
> -------------------------------------------------------------------------------
> Test set: org.apache.commons.math.optimization.general.MinpackTest
> -------------------------------------------------------------------------------
> Tests run: 18, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.218 sec
> <<< FAILURE!
> testMinpackBrownDennis(org.apache.commons.math.optimization.general.MinpackTest)
> Time elapsed: 0.036 sec <<< FAILURE!
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at junit.framework.Assert.assertTrue(Assert.java:27)
> at
> org.apache.commons.math.optimization.general.MinpackTest.minpackTest(MinpackTest.java:504)
> at
> org.apache.commons.math.optimization.general.MinpackTest.testMinpackBrownDennis(MinpackTest.java:349)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> ================ %< ===============
>
> The JDK I use is one of the last JRockit versions available as separate
> download from former BEA:
>
> ================ %< ===============
> $ java -version
> java version "1.5.0_14"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
> BEA JRockit(R) (build
> R27.5.0-110_CR366951-97327-1.5.0_14-20080408-1711-linux-ia32, compiled
> mode)
> ================ %< ===============
>
> Since IBM JDK 1.5 does not run with Maven, I tried that one with Ant and it
> worked fine.
>
> Regards,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Luc,
Luc Maisonobe wrote:
> Luc Maisonobe a écrit :
>> Jörg Schaible a écrit :
>>> Hi Phil,
>>>
>>> tried the source package with my compiler zoo. Sun JDKs and icedtea6
>>> take roughly 1 min to compile, test and build the jar. IBM JDK 1.6 takes
>>> about 3 mins ... are math operations so bad with this JVM? However, with
>>> JRockit 1.5 the test hangs forever in
>>> org.apache.commons.math.ode.nonstiff.GraggBulirschStoerIntegratorTest
>>> and I have to kill it after several minutes (verified twice). Can
>>> someone else confirm?
>>
>> Could you tell which test fails in the Gragg Bulirsch Stoer set (there
>> are 10 tests for it) ?
>>
>> could you try to add this statement to the failing test, sometimes
>> before the call to integrate ?
>>
>> integ.setMaxEvaluations(100000);
>>
>> This could prevent a possible infinite loop but will lead the test to
>> fail with an exception when the maximal number of evaluations is reached.
>
> Maybe it is the same problem that was encountered while releasing 1.2
> <http://markmail.org/message/bbodv6uhv4a5e4ky> ? Could you try the fix I
> proposed in the referenced message ?
we're definitely on the right track. After changing the loop in TestProblem3
the tests run through. However, now I have two failing tests:
================ %< ===============
Failed tests:
testMinpackBrownDennis(org.apache.commons.math.estimation.MinpackTest)
testMinpackBrownDennis(org.apache.commons.math.optimization.general.MinpackTest)
================ %< ===============
-------------------------------------------------------------------------------
Test set: org.apache.commons.math.estimation.MinpackTest
-------------------------------------------------------------------------------
Tests run: 18, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.468 sec
<<< FAILURE!
testMinpackBrownDennis(org.apache.commons.math.estimation.MinpackTest) Time
elapsed: 0.411 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
org.apache.commons.math.estimation.MinpackTest.minpackTest(MinpackTest.java:503)
at
org.apache.commons.math.estimation.MinpackTest.testMinpackBrownDennis(MinpackTest.java:348)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
================ %< ===============
-------------------------------------------------------------------------------
Test set: org.apache.commons.math.optimization.general.MinpackTest
-------------------------------------------------------------------------------
Tests run: 18, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.218 sec
<<< FAILURE!
testMinpackBrownDennis(org.apache.commons.math.optimization.general.MinpackTest)
Time elapsed: 0.036 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
org.apache.commons.math.optimization.general.MinpackTest.minpackTest(MinpackTest.java:504)
at
org.apache.commons.math.optimization.general.MinpackTest.testMinpackBrownDennis(MinpackTest.java:349)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
================ %< ===============
The JDK I use is one of the last JRockit versions available as separate
download from former BEA:
================ %< ===============
$ java -version
java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
BEA JRockit(R) (build
R27.5.0-110_CR366951-97327-1.5.0_14-20080408-1711-linux-ia32, compiled
mode)
================ %< ===============
Since IBM JDK 1.5 does not run with Maven, I tried that one with Ant and it
worked fine.
Regards,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Luc Maisonobe <Lu...@free.fr>.
Luc Maisonobe a écrit :
> Jörg Schaible a écrit :
>> Hi Phil,
>>
>> tried the source package with my compiler zoo. Sun JDKs and icedtea6 take
>> roughly 1 min to compile, test and build the jar. IBM JDK 1.6 takes about 3
>> mins ... are math operations so bad with this JVM? However, with JRockit
>> 1.5 the test hangs forever in
>> org.apache.commons.math.ode.nonstiff.GraggBulirschStoerIntegratorTest and I
>> have to kill it after several minutes (verified twice). Can someone else
>> confirm?
>
> Could you tell which test fails in the Gragg Bulirsch Stoer set (there
> are 10 tests for it) ?
>
> could you try to add this statement to the failing test, sometimes
> before the call to integrate ?
>
> integ.setMaxEvaluations(100000);
>
> This could prevent a possible infinite loop but will lead the test to
> fail with an exception when the maximal number of evaluations is reached.
Maybe it is the same problem that was encountered while releasing 1.2
<http://markmail.org/message/bbodv6uhv4a5e4ky> ? Could you try the fix I
proposed in the referenced message ?
Luc
>
> Luc
>
>> - Jörg
>>
>> Phil Steitz wrote:
>>
>>> The release distributions are here:
>>> http://people.apache.org/~psteitz/commons-math-2.0-RC3/
>>>
>>> The tag is here:
>>> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
>>>
>>> Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
>>>
>>> Thanks!
>>>
>>> Phil
>>> ---------------------------------------------------------------------
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -0
>>> [ ] -1
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Luc Maisonobe <Lu...@free.fr>.
Jörg Schaible a écrit :
> Hi Phil,
>
> tried the source package with my compiler zoo. Sun JDKs and icedtea6 take
> roughly 1 min to compile, test and build the jar. IBM JDK 1.6 takes about 3
> mins ... are math operations so bad with this JVM? However, with JRockit
> 1.5 the test hangs forever in
> org.apache.commons.math.ode.nonstiff.GraggBulirschStoerIntegratorTest and I
> have to kill it after several minutes (verified twice). Can someone else
> confirm?
Could you tell which test fails in the Gragg Bulirsch Stoer set (there
are 10 tests for it) ?
could you try to add this statement to the failing test, sometimes
before the call to integrate ?
integ.setMaxEvaluations(100000);
This could prevent a possible infinite loop but will lead the test to
fail with an exception when the maximal number of evaluations is reached.
Luc
>
> - Jörg
>
> Phil Steitz wrote:
>
>> The release distributions are here:
>> http://people.apache.org/~psteitz/commons-math-2.0-RC3/
>>
>> The tag is here:
>> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
>>
>> Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
>>
>> Thanks!
>>
>> Phil
>> ---------------------------------------------------------------------
>>
>> [ ] +1
>> [ ] +0
>> [ ] -0
>> [ ] -1
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Phil,
tried the source package with my compiler zoo. Sun JDKs and icedtea6 take
roughly 1 min to compile, test and build the jar. IBM JDK 1.6 takes about 3
mins ... are math operations so bad with this JVM? However, with JRockit
1.5 the test hangs forever in
org.apache.commons.math.ode.nonstiff.GraggBulirschStoerIntegratorTest and I
have to kill it after several minutes (verified twice). Can someone else
confirm?
- Jörg
Phil Steitz wrote:
> The release distributions are here:
> http://people.apache.org/~psteitz/commons-math-2.0-RC3/
>
> The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
>
> Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
>
> Thanks!
>
> Phil
> ---------------------------------------------------------------------
>
> [ ] +1
> [ ] +0
> [ ] -0
> [ ] -1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: CANCELLED: [VOTE] Release Math 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Phil Steitz wrote:
> Jörg Schaible wrote:
>> Hi Phil,
>>
>> Phil Steitz wrote:
>>
>>
>>> Luc Maisonobe wrote:
>>>
>>>> Jörg Schaible a écrit :
>>>>
>>>>
>>>>> Hi Phil,
[snip]
>>>>
>>> Fine by me, though it is annoying that we are forced to do this.
>>>
>>
>> Well, you do not have to follow the Maven setup, but it's the mixture
>> here. Actually this is one of the core issues of Maven, that all the
>> projects are uniform - know one, know all.
>>
>> When I saw the failing test I tried to open the files from command line
>> using tab completion. Finding "main" under "src" I was quite irritated
>> not to have "java" under "test".
>>
>> So either follow all the rules or not at all, but don't mix it - the
>> result is worse.
>>
> I agree with you on the awkwardness of the "mixed" setup. What annoys
> me is that we were forced to introduce "main" to get the changes plugin
> to load a resource that it should have been able to find.
OK, I was not aware of the reason for src/main/resource here. However, this
looks now even stranger, since files in this location are normally
resources of the resulting artifact :-/
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: CANCELLED: [VOTE] Release Math 2.0
Posted by Phil Steitz <ph...@gmail.com>.
Jörg Schaible wrote:
> Hi Phil,
>
> Phil Steitz wrote:
>
>
>> Luc Maisonobe wrote:
>>
>>> Jörg Schaible a écrit :
>>>
>>>
>>>> Hi Phil,
>>>>
>>>> one thing that also irritated me first was the directory layout. While
>>>> we do not necessarily follow the Maven conventions always (mainly
>>>> because of historical reasons) we have in case of math a mixture between
>>>> Maven conventions and history.
>>>>
>>>> Maven encourages you to separate main and test sources in src/main/java
>>>> and src/test/java. We have in commons src/java and scr/test. However,
>>>> the default for resources in Maven is src/main/resources and
>>>> src/test/resources and here math suddenly has the main resources in
>>>> src/main/resource. It's the mixture of the conventions that itch me.
>>>>
>>>>
>>> I strongly agree here.
>>> I everybody is OK, I'll do the change to maven standard in a few hours.
>>>
>>>
>> Fine by me, though it is annoying that we are forced to do this.
>>
>
> Well, you do not have to follow the Maven setup, but it's the mixture here.
> Actually this is one of the core issues of Maven, that all the projects are
> uniform - know one, know all.
>
> When I saw the failing test I tried to open the files from command line
> using tab completion. Finding "main" under "src" I was quite irritated not
> to have "java" under "test".
>
> So either follow all the rules or not at all, but don't mix it - the result
> is worse.
>
I agree with you on the awkwardness of the "mixed" setup. What annoys
me is that we were forced to introduce "main" to get the changes plugin
to load a resource that it should have been able to find.
Phil
> - Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: CANCELLED: [VOTE] Release Math 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Phil,
Phil Steitz wrote:
> Luc Maisonobe wrote:
>> Jörg Schaible a écrit :
>>
>>> Hi Phil,
>>>
>>> one thing that also irritated me first was the directory layout. While
>>> we do not necessarily follow the Maven conventions always (mainly
>>> because of historical reasons) we have in case of math a mixture between
>>> Maven conventions and history.
>>>
>>> Maven encourages you to separate main and test sources in src/main/java
>>> and src/test/java. We have in commons src/java and scr/test. However,
>>> the default for resources in Maven is src/main/resources and
>>> src/test/resources and here math suddenly has the main resources in
>>> src/main/resource. It's the mixture of the conventions that itch me.
>>>
>>
>> I strongly agree here.
>> I everybody is OK, I'll do the change to maven standard in a few hours.
>>
> Fine by me, though it is annoying that we are forced to do this.
Well, you do not have to follow the Maven setup, but it's the mixture here.
Actually this is one of the core issues of Maven, that all the projects are
uniform - know one, know all.
When I saw the failing test I tried to open the files from command line
using tab completion. Finding "main" under "src" I was quite irritated not
to have "java" under "test".
So either follow all the rules or not at all, but don't mix it - the result
is worse.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: CANCELLED: [VOTE] Release Math 2.0
Posted by Phil Steitz <ph...@gmail.com>.
Luc Maisonobe wrote:
> Jörg Schaible a écrit :
>
>> Hi Phil,
>>
>> one thing that also irritated me first was the directory layout. While we do
>> not necessarily follow the Maven conventions always (mainly because of
>> historical reasons) we have in case of math a mixture between Maven
>> conventions and history.
>>
>> Maven encourages you to separate main and test sources in src/main/java and
>> src/test/java. We have in commons src/java and scr/test. However, the
>> default for resources in Maven is src/main/resources and src/test/resources
>> and here math suddenly has the main resources in src/main/resource. It's
>> the mixture of the conventions that itch me.
>>
>
> I strongly agree here.
> I everybody is OK, I'll do the change to maven standard in a few hours.
>
Fine by me, though it is annoying that we are forced to do this.
Phil
> Luc
>
>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: CANCELLED: [VOTE] Release Math 2.0
Posted by Luc Maisonobe <Lu...@free.fr>.
Jörg Schaible a écrit :
> Hi Phil,
>
> one thing that also irritated me first was the directory layout. While we do
> not necessarily follow the Maven conventions always (mainly because of
> historical reasons) we have in case of math a mixture between Maven
> conventions and history.
>
> Maven encourages you to separate main and test sources in src/main/java and
> src/test/java. We have in commons src/java and scr/test. However, the
> default for resources in Maven is src/main/resources and src/test/resources
> and here math suddenly has the main resources in src/main/resource. It's
> the mixture of the conventions that itch me.
I strongly agree here.
I everybody is OK, I'll do the change to maven standard in a few hours.
Luc
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: CANCELLED: [VOTE] Release Math 2.0
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Phil,
one thing that also irritated me first was the directory layout. While we do
not necessarily follow the Maven conventions always (mainly because of
historical reasons) we have in case of math a mixture between Maven
conventions and history.
Maven encourages you to separate main and test sources in src/main/java and
src/test/java. We have in commons src/java and scr/test. However, the
default for resources in Maven is src/main/resources and src/test/resources
and here math suddenly has the main resources in src/main/resource. It's
the mixture of the conventions that itch me.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
CANCELLED: [VOTE] Release Math 2.0
Posted by Phil Steitz <ph...@gmail.com>.
Phil Steitz wrote:
> The release distributions are here:
> http://people.apache.org/~psteitz/commons-math-2.0-RC3/
>
> The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
>
> Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
>
> Thanks!
>
> Phil
> ---------------------------------------------------------------------
>
> [ ] +1
> [ ] +0
> [ ] -0
> [ ] -1
This vote is cancelled due to showstopper issues identified. Thanks to
all who tested the release.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by sebb <se...@gmail.com>.
On 31/07/2009, Oliver Heger <ol...@oliver-heger.de> wrote:
> The artifacts look good, I found no specific problems. The user guide is
> great work!
>
> The only thing I found a bit strange is the size of the binary
> distribution: 16M is unusual for a small commons component. However, the
> size is caused to the major part by the API documentation and it should not
> be a problem these days.
The binary jar contains two copies of the javadoc - once as plain
files, and once in the embedded javadoc jar.
Also, the embedded javadoc jar contains the source files as
line-numbered HTML files - they surely don't belong in the javadoc
jar? They are already in the binary archive.
Maybe the documentation could be released as a separate archive?
> Don't know whether the missing license headers require a new RC, so no
> vote.
>
> Oliver
>
> Phil Steitz schrieb:
>
>
> > The release distributions are here:
> > http://people.apache.org/~psteitz/commons-math-2.0-RC3/
> >
> > The tag is here:
> >
> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
> >
> > Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
> >
> > Thanks!
> >
> > Phil
> >
> ---------------------------------------------------------------------
> >
> > [ ] +1
> > [ ] +0
> > [ ] -0
> > [ ] -1
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Oliver Heger <ol...@oliver-heger.de>.
The artifacts look good, I found no specific problems. The user guide is
great work!
The only thing I found a bit strange is the size of the binary
distribution: 16M is unusual for a small commons component. However, the
size is caused to the major part by the API documentation and it should
not be a problem these days.
Don't know whether the missing license headers require a new RC, so no vote.
Oliver
Phil Steitz schrieb:
> The release distributions are here:
> http://people.apache.org/~psteitz/commons-math-2.0-RC3/
>
> The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
>
> Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
>
> Thanks!
>
> Phil
> ---------------------------------------------------------------------
>
> [ ] +1
> [ ] +0
> [ ] -0
> [ ] -1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by sebb <se...@gmail.com>.
On 31/07/2009, Luc Maisonobe <Lu...@free.fr> wrote:
> Phil Steitz a écrit :
>
> > The release distributions are here:
> > http://people.apache.org/~psteitz/commons-math-2.0-RC3/
SIgs and hashes OK; archives agree with each other and with SVN except
as noted below.
Builds and tests OK on Java 1.5/WinXP
> >
> > The tag is here:
> > http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
>
Quite a few missing SVN properties (and one additional one):
svn ps svn:eol-style native RELEASE-NOTES.txt
svn ps svn:eol-style native src/java/org/apache/commons/math/FieldElement.java
svn ps svn:eol-style native
src/java/org/apache/commons/math/analysis/MultivariateVectorialFunction.java
svn ps svn:eol-style native
src/java/org/apache/commons/math/optimization/SimpleRealPointChecker.java
svn ps svn:eol-style native
src/java/org/apache/commons/math/optimization/general/NonLinearConjugateGradientOptimizer.java
svn ps svn:eol-style native
src/java/org/apache/commons/math/optimization/linear/LinearOptimizer.java
svn ps svn:eol-style native
src/java/org/apache/commons/math/stat/clustering/Clusterable.java
svn ps svn:eol-style native
src/java/org/apache/commons/math/stat/correlation/SpearmansCorrelation.java
svn ps svn:eol-style native
src/java/org/apache/commons/math/util/OpenIntToFieldHashMap.java
svn ps svn:eol-style native src/site/xdoc/userguide/genetics.xml
svn ps svn:eol-style native
src/test/org/apache/commons/math/linear/EigenSolverTest.java
svn ps svn:eol-style native
src/test/org/apache/commons/math/linear/SparseFieldVectorTest.java
svn ps svn:eol-style native
src/test/org/apache/commons/math/stat/correlation/SpearmansRankCorrelationTest.java
Best if the original author fixes these to reduce difference noise.
svn pd svn:executable
src/test/org/apache/commons/math/linear/SingularValueDecompositionImplTest.java
The file "test-jar.xml" is missing from the source archives.
It would be useful to include it.
>
> It seems I forgot to put the Apache header in the unit tests for
> Mersenne twister.
AL header is also missing from:
doap_math.rdf
src/site/xdoc/userguide/xdoc.xsl
> I'll fix this immediately.
> I'm sorry
>
>
> Luc
>
>
> >
> > Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
> >
> > Thanks!
> >
> > Phil
> > ---------------------------------------------------------------------
> >
> > [ ] +1
> > [ ] +0
> > [ ] -0
> > [ ] -1
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Luc Maisonobe <Lu...@free.fr>.
Phil Steitz a écrit :
> The release distributions are here:
> http://people.apache.org/~psteitz/commons-math-2.0-RC3/
>
> The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
It seems I forgot to put the Apache header in the unit tests for
Mersenne twister.
I'll fix this immediately.
I'm sorry
Luc
>
> Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
>
> Thanks!
>
> Phil
> ---------------------------------------------------------------------
>
> [ ] +1
> [ ] +0
> [ ] -0
> [ ] -1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Math 2.0
Posted by Bill Barker <bi...@verizon.net>.
----- Original Message -----
From: "Phil Steitz" <ph...@gmail.com>
To: "Commons Developers List" <de...@commons.apache.org>
Sent: Thursday, July 30, 2009 4:55 PM
Subject: [VOTE] Release Math 2.0
> The release distributions are here:
> http://people.apache.org/~psteitz/commons-math-2.0-RC3/
>
> The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_0_RC3
>
> Votes, please. This vote will close in 72 hours (01:00 GMT 2-Aug-09)
>
> Thanks!
>
> Phil
> ---------------------------------------------------------------------
>
> [X] +1 (non-binding) The javadoc links in the index page of docs of the
> binary distro are completely broken (as are most of the links under
> "Commons"). But I believe that the src distro is what we release. [ ] +0
> [ ] -0 [ ] -1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org