StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Using <code>mpfr</code> can be useful to avoid computationally <code>NaN</code> in a function (and also halt in optimization algorithm). But <code>mpfr</code> output is an 'mpfr' class and some R functions (such as <code>optim</code> and <code>det</code>) may not work with this kind of class. As usual <code>as.numeric</code> can be applied to convert 'mpfr' class to a 'numeric' one.</p> <pre><code>exp(9000) [1] Inf require(Rmpfr) number <- as.numeric(exp(mpfr(9000, prec = 54))) class(number) [1] "numeric" round(number) [1] 1.797693e+308 number * 1.797692e-308 [1] 3.231699 number * 1.797693e-307 [1] 32.317 number * (1/number) [1] 1 number * .2 [1] 3.595386e+307 number * .9 [1] 1.617924e+308 number * 1.1 [1] Inf number * 2 [1] Inf number / 2 [1] 8.988466e+307 number + 2 [1] 1.797693e+308 number + 2 * 10 ^ 291 [1] 1.797693e+308 number + 2 * 10 ^ 292 [1] Inf number - 2 [1] 1.797693e+308 number - 2 * 10 ^ 307 [1] 1.597693e+308 number - 2 * 10 ^ 308 [1] -Inf </code></pre> <p>Now consider the following matrix function:</p> <pre><code>mat <- function(x){ x1 <- x[1] x2 <- x[2] d = matrix(c(exp(5 * x1+ 4 * x2), exp(9 * x1), exp(2 * x2 + 4 * x1), exp(3 * x1)), 2, 2) return(d) } </code></pre> <p>elements of this matrix is highly potential to produce <code>Inf</code>: </p> <pre><code>mat(c(300, 1)) [,1] [,2] [1,] Inf Inf [2,] Inf Inf </code></pre> <p>So if <code>det</code> was returned in function environment, instead of a numeric result we got <code>NaN</code> and the <code>optim</code> function would definitely be terminated. To solve this problem the determinant of this function is written by <code>mpfr</code>:</p> <pre><code>func <- function (x){ x1 <- mpfr(x[1], prec = precision) x2 <- mpfr(x[2], prec = precision) mat <- new("mpfrMatrix",c(exp(5 * x1+ 4 * x2), exp(9 * x1), exp(2 * x2 + 4 * x1), exp(3 * x1)), Dim = c(2L,2L)) d <- mat[1, 1] * mat[2, 2] - mat[2, 1] * mat[1, 2] return(as.numeric(-d)) } </code></pre> <p>then for x1 = 3 and x2 = 1 we have:</p> <pre><code>func(c(3,1)) [1] 6.39842e+17 optim(c(3, 1),func) $par [1] 0.4500 1.4125 $value [1] -4549.866 $counts function gradient 13 NA $convergence [1] 0 $message NULL </code></pre> <p>and for x1 = 300 and x2 = 1:</p> <pre><code>func(c(300,1)) [1] 1.797693e+308 optim(c(300, 1),func) $par [1] 300 1 $value [1] 1.797693e+308 $counts function gradient 3 NA $convergence [1] 0 $message NULL </code></pre> <p>As can bee seen, there is no halt and even <code>optim</code> claimes a convergence in the optimization process. However, it seems that there are no iterations and <code>optim</code> just returned the initial values as local minimums (definitely, 1.797693e+308 is not a local minimum of this function!!). In such these situations, applying <code>mpfr</code> can just prevent termination of optimization process, but if we really expect optimization algorithm to start from such this points which their values are <code>Inf</code> by R double-precision and continue the iteration to reach the local minimums, besides defining a function with 'mpfr' class, the optimization function also should have this ability to work with 'mpfr' class.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload