Martin Maechler wrote: >>>>>> "TP" == Thomas Petzoldt <[EMAIL PROTECTED]> >>>>>> 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. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
