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

[Thomas Petzoldt]

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.