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 Sat, 01 Aug 2009 19:44:55 GMT
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 ?

thanks
Luc

> 
> Hope this helps,
> 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