[Rd] optim: why is REPORT not used in SANN?

[Thomas Petzoldt]

Thomas Petzoldt schrieb:
> Martin Maechler wrote:
>>>>>>> "TP" == Thomas Petzoldt <Thomas.Petzoldt at tu-dresden.de>
>>>>>>>     on Sun, 16 Mar 2008 13:50:55 +0100 writes:
>>     TP> Hello, I wonder why the control parameter REPORT is not
>>     TP> supported by method SANN. Looking into optim.c I found
>>     TP> an internal constant:
>>
>>     TP> #define STEPS 100
>>
>>     TP> ... and decreasing this to 10 helped me fine-tuning the
>>     TP> annealing parameters in an actual problem.
>>
>>     TP> Is there any reason why not passing nREPORT to samin and
>>     TP> setting something like:
>>
>>     TP> STEPS = nREPORT / tmax
>>
>> Sorry to reply late (but then, rather than never ..).
>>
>> You ask for reasons... I see/guess :
>>
>> - the  SANN  method also was contributed from "outside" 
>>   (as ?optim mentions); and the original authors may not have
>>   seen a use for such more flexible monitoring.
>>
>> - the R core members are probably not using 'samin' very often
>>
>> - If there is a need you can write the function you are
>>   optimizing in a way that it prints info.
>>
>> - Nobody has contributed a well-tested patch against R-devel to
>>   both code and documentation
>>   which would implement your proposal ___ BACK COMPATIBLY __
>>   (i.e. the default for SANN should remain to print every 100th;
>>    and this differs from the default for BFGS where the default
>>   'REPORT' leads to output every 10th eval).
>>
>> Regards,
>> Martin
> 
> Well, I see. The reasons are obviously more or less historical and not 
> fundamental. I can, of course, contribute an idea for a modifications of 
> samin and do_optim in optim.c. However, to convert my personal hack into 
> a "well-tested patch" a few additional considerations have to be 
> undertaken, especially about back-compatibility:
> 
> 1) the patch requires to pass the additional argument nREPORT to 
> function "samin".
> 
> - Is this still back-compatible? Is it likely that other functions (e.g. 
> in packages call samin directly?
> 
> - if yes (i.e. direct call is likely), what is the preferred way to 
> ensure compatibility? Rename samin to samin2 and add a new 
> "compatibility function" function samin that calls samin2?
> 
> - the reporting interval of samin is STEPS * tmax where
>    - tmax is as documented "number of function evaluations at each 
> temperature" (10) and
>    - STEPS is a hard-coded constant: #define STEPS 10
>    - this means that reporting is every 10 per temperature.
> 
> 2) if one starts patching SANN, then one migth also think about
> "Nelder-Mead" and "CG" with totally different reporting, but smaller 
> (!) reporting schedule.
> 
> In contrast to this, SANN that is used for difficult systems *and* that 
> (see optim.Rd) "depends critically on the settings of the control 
> parameters" has a rather long reporting interval.
> 
> Thomas P.
> 

o.k. here is it. The patch works by re-using trace for SANN -- as 
suggested by Martin Maechler off-list after my first suggestion. The new 
patch avoids an extended parameter list of samin and therefore the 
necessity to modify the API.

The patched files and a few test examples are also on

http://hhbio.wasser.tu-dresden.de/projects/temp/optim/

Thank you for consideration

Thomas P.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: optim.diff
Url: https://stat.ethz.ch/pipermail/r-devel/attachments/20080407/fe303e92/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: optim.Rd.diff
Url: https://stat.ethz.ch/pipermail/r-devel/attachments/20080407/fe303e92/attachment-0001.pl