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 23:09:56 GMT
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


Mime
View raw message