commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [VOTE] Release Math 2.0
Date Mon, 03 Aug 2009 22:06:36 GMT
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


Mime
View raw message