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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
