commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [VOTE] Release Math 2.0
Date Tue, 04 Aug 2009 08:19:55 GMT

----- "Jörg Schaible" <joerg.schaible@gmx.de> a écrit :

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

This means the test should succeed if the costAccuracy is set to a value greater than 2.09e-8
then. So if it fails at 1.0e-6, the failure is probably elsewhere.

I don't know jrockit, is it possible to install it freely as a standalone JVM without oracle
on a Linux host ?

Luc

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message