commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [VOTE] Release Math 2.0
Date Mon, 03 Aug 2009 21:42:21 GMT
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


Mime
View raw message