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-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
