commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [Math] About MATH-798
Date Sat, 02 Jun 2012 09:37:30 GMT
Hi Gilles,

2012/6/2 Luc Maisonobe <Luc.Maisonobe@free.fr>:
> Le 02/06/2012 01:55, Gilles Sadowski a écrit :
>> Hello.
>
> Hi Gilles,
>
>>
>> Do you know the rationale behind the (very) small values for
>>  DEFAULT_RELATIVE_THRESHOLD (set to 100 * Precision.EPSILON)
>>  DEFAULT_ABSOLUTE_THRESHOLD (set to 100 * Precision.SAFE_MIN)
>> in "AbstractConvergenceChecker"?
>> [I created this class as part of a refactoring, but the values were carried
>> over from whatever class contained that functionality before.]
>>
>> With those values, the "GaussNewtonOptimizer" fails to find the solution but
>> if one changes the threshold to either
>>  1e3 * Precision.EPSILON (for the relative threshold)
>> or
>>  1e281 * Precision.SAFE_MIN (for the absolute threshold)
>> the solution is found in 4 evaluations!
>>
>> As I wrote on the user ML, the thresholds were too stringent.
>> Are the current values really suitable as defaults (in other part of the
>> library, similar defaults are much larger)?
>> [I even think that there shouldn't be any defaults, so that users are
>> actually aware that the thresholds are problem-dependent and sometimes even
>> optimizer-dependent. My preference would thus be to deprecate the default
>> constructor in all the checker classes.]
>
> I think I wrote the initial classes, and I picked the values from a
> domain-specific case. So from a general point of view, these values are
> probably worthless.
>
> OK for deprecating in 3.1 and suppressing the values in 4.0.
>
I'm also +1 for this change.
Sébastien


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


Mime
View raw message