[R] temp seems ineffective in SANN (optim)

[Enrico Schumann]

On Wed, 27 Feb 2013, Ross Boylan <ross at biostat.ucsf.edu> writes:

> I am trying to control the behavior of the SANN method in optim (R
> 2.14.1) via control$temp.  In my toy tests it works; in my real use, it
> doesn't.
>
> As far as I can tell my code with different temp values is loaded; I
> even traced into the function that calls optim and verified temp had the
> value I had set.
>
> Could the fact that I have NaN's coming back from the objective function
> be a factor?  Here are the results I've gotten from 20 iterations with
> temp varying from 2 to 9.  The first column is the value of the
> objective function, and the rest are the parameter values (the objective
> function is augmented to leave a trace).  The rows represent SANN's
> different guesses, in sequence.
>> history9
>            [,1]      [,2]        [,3]        [,4]      [,5]        [,6]
>  [1,] -3507.346 -4.500000  1.00000000  1.00000000 1.0000000  0.69314718
>  [2,] -3828.071 -3.942424  0.03090623  0.30739233 1.7062554 -0.01814918
>  [3,] -4007.624 -3.126794  1.79592189  1.41855332 1.2060574  1.54479512
>  [4,]       NaN -4.064653 -0.25017279  1.30476170 0.2559306 -0.31140650
>  [5,] -4222.272 -3.058714 -0.93063613 -0.54296159 0.8287307  1.92103676
>  [6,]       NaN -3.833080  1.00721123  1.66564249 0.7923725 -0.04967723
>  [7,]       NaN -5.050322 -0.45545409  0.83209653 1.4976764 -0.47211795
>  [8,]       NaN -3.717588  0.62400594  0.73424007 0.1359730  1.62073131
>  [9,]       NaN -6.078701  0.10000219  0.36961894 0.2633589  0.67651053
> [10,]       NaN -3.404865  2.92992664  1.45204623 0.2020535  1.49936000
> [11,]       NaN -3.387337  2.17682158  0.06994319 1.1717615  0.68526889
> [12,]       NaN -4.534316  0.88676089  1.34499190 0.9148238  0.98417597
> [13,]       NaN -4.445174  1.06230896  1.51960345 0.4651780  1.14127715
> [14,] -3784.848 -4.007890  0.77866330  1.01243770 1.1957120  1.33305656
> [15,]       NaN -3.707500  1.30038651  1.30480610 0.6210218  0.81355299
> [16,] -3730.219 -4.155193  0.76779830  1.06686987 1.0546294  1.45601474
> [17,] -3524.462 -5.074722  1.21296408  0.59787431 0.9228195  1.07755859
> [18,] -3588.086 -5.146427  1.28721218  0.74634447 1.1107613  0.63009540
> [19,] -3715.411 -4.501889  0.72491408  0.75046935 0.8476556  1.64229603
> [20,] -3711.158 -4.813507  0.88125227  1.10291836 0.1452430  0.07181056
>              [,7]       [,8]      [,9]    [,10]
>  [1,]  0.00000000  0.5493061 -4.500000 4.000000
>  [2,] -1.33969887  2.6881171 -5.797714 4.712738
>  [3,]  1.10373337  1.5164159 -4.666298 4.551507
>  [4,]  0.36425367  0.5755519 -3.558595 3.811114
>  [5,] -0.77555882  0.4863321 -5.060481 4.987640
>  [6,] -1.14686363  0.5164433 -4.759286 3.650409
>  [7,] -0.43179263  1.1326352 -4.611431 3.920483
>  [8,]  1.67696259  0.8754158 -4.352415 3.095768
>  [9,]  1.10927659  0.5779504 -4.952128 4.649442
> [10,] -0.67478207  2.8174240 -4.704395 2.986569
> [11,]  0.45878472  0.6479467 -4.122482 2.934156
> [12,] -0.04871212  0.9457826 -4.617438 4.377056
> [13,] -0.01321339  0.3833625 -4.591240 4.729049
> [14,] -0.49075803  0.3322742 -3.971298 4.357731
> [15,]  0.16922427  0.4820518 -4.683029 3.875409
> [16,] -0.18047923 -0.4957090 -4.492014 4.317694
> [17,] -0.28481705  0.1923373 -4.288773 3.956130
> [18,]  0.12102775 -0.2332984 -4.981987 4.301450
> [19,]  0.15961575  1.1644561 -4.459003 3.777286
> [20,] -0.24130528  0.6126422 -4.075133 3.628426
>> sum(is.nan(history9[,1]))
> [1] 10
>> max(abs(history9-history5), na.rm=TRUE)
> [1] 9.094947e-13
> # historyN has a temp of N
>
> BTW the values of the objective function have their sign reversed to
> make it a maximization problem.
>
> Ross Boylan
>

Hi Ross,

please post a reproducible code example (as the posting guide asks you
to); otherwise I doubt you will get much help.

In any case, your objective function (OF) should not evaluate to
NaN. The algorithm decides whether one solution is better or worse than
another solution by looking at the OF value. NaN translates into "don't
know", which doesn't provide much guidance to the algorithm.


Regards,
Enrico

-- 
Enrico Schumann
Lucerne, Switzerland
http://enricoschumann.net