[Insight-developers] Proper use of SetCostFunctionConvergenceFactor

[Luis Ibanez]

Yeap,
Stephen also pointed this out to me.


I was trying to give some tolerance...
because the numbers I saw for machine
tolerance in VNL are:

        2.22 e-16 for doubles
        1.19 e-07 for floats

but, I don't have any good argument for
supporting the 0.1 value, other than the
engineering intuition that the check
shouldn't be in the exact value.

----

I just committed that change.
The limit value is now 1.0.

BTW,
should we also enforce an upper limit ?

The comments recommend 1e+12 as a max value...


    Luis


----------------------
Bill Lorensen wrote:
> Luis,
> 
> The check should be for < 1.0. I think that .1 means 10 times better
> than machine precision which is too small.
> 
> Bill
> 
> On Tue, Apr 8, 2008 at 11:32 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> 
>> Hi Bill,
>>
>> That was a great catch !,
>>
>> Thanks for fixing the parameter values.
>>
>> A check has just been added to the itkLBFGSBOptimizer
>> in this method. Now and exception is thrown if the value
>> is less than 0.1.
>>
>> This has been committed to CVS.
>>
>>
>> Certainly, choosing proper parameters for the convergence
>> has been one of the main challenges when using this optimizer.
>>
>>
>>   Luis
>>
>>
>> ---------------------
>>
>>
>> Bill Lorensen wrote:
>>
>>
>>>Guys,
>>>
>>>I noticed that a couple of registration examples that use the lbfgsb
>>>optimizer were setting the cost function convergence factor as though
>>>it were an epsilon. Actually, it is a factor that is multiplied times
>>>the machine precision to compute. Hence, a number < 1 (some examples
>>>used 1.e-35) result in a tolerance below the precision of the machine.
>>>As stated in the comments of the optimizer:
>>>
>>>/** Set/Get the CostFunctionConvergenceFactor. Algorithm terminates
>>>  * when the reduction in cost function is less than factor * epsmcj
>>>  * where epsmch is the machine precision.
>>>  * Typical values for factor: 1e+12 for low accuracy;
>>>   * 1e+7 for moderate accuracy and 1e+1 for extremely high accuracy.
>>>   */
>>>
>>>I fixed two examples. They were occasionally failing on some
>>>platforms. On the Borland platform at least one was aborting on a
>>>divide by zero.
>>>
>>>
>>
>>http://public.kitware.com/cgi-bin/viewcvs.cgi/Examples/Registration/DeformableRegistration12.cxx?root=Insight&r1=1.9&r2=1.10
>>
>>http://public.kitware.com/cgi-bin/viewcvs.cgi/Examples/Registration/DeformableRegistration8.cxx?root=Insight&r1=1.22&r2=1.23
>>
>>>Maybe we should put a check in the Set method to prevent future misuse
>>>of this variable.
>>>
>>>Bill
>>>
>>>
>>
>