# Optim.jl can't optimize function which includes BigFloat variables

**URL:** <https://discourse.julialang.org/t/optim-jl-cant-optimize-function-which-includes-bigfloat-variables/65095>\
**Category:** General Usage\
**Tags:** question, package, optim, optimization\
**Created:** [July 22, 2021, 9:16am UTC](https://discourse.julialang.org/t/optim-jl-cant-optimize-function-which-includes-bigfloat-variables/65095 "2021-07-22T09:16:37Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [July 22, 2021, 12:34pm UTC](https://discourse.julialang.org/t/optim-jl-cant-optimize-function-which-includes-bigfloat-variables/65095/4 "2021-07-22T12:34:00Z")

</div>

> [@Strange\_Xue](#):
>
> ```julia
> function Log_Likelihood(X, Y, β, log_σ)
> σ = exp(big(log_σ))
> llike = -n/2*log(2π) - n/2* log(σ^2) - (sum((Y - X * β).^2) / (2σ^2))
> llike = -llike
> end
> 
> ```

There is no point in converting a single term like `σ` to `BigFloat` if the rest of the computations are done in double precision. e.g. `log(2π)` is computed in double precision, and that will generally limit your accuracy to double precision even if _parts_ of the computation are `BigFloat`.

(Aside: [don’t use global variables](https://docs.julialang.org/en/v1/manual/performance-tips/#Avoid-global-variables) like `n` in your functions if you can help it. In this case, you should get `n = length(Y)` from the arguments.)

In general, you should try to write code that works for any number type _based on the types of the arguments_. This can be a little tricky but the result is much more flexible code. For example:

```julia
function Log_Likelihood2(X, Y, β, log_σ)
    n = length(Y)
    σ = exp(log_σ)
    llike = n * log_σ + sum((Y .- X * β).^2) / 2σ^2
    return llike + n * log(2*oftype(llike, π)) / 2
end

```

Not that it uses `oftype(llike, π)` to compute `π` in the same precision as `llike`, and rearranges the calculation to avoid `n/2` (`Int`/`Int` uses double precision, though technically dividing integers by `2` can be done exactly it still changes the precision).

Now you can compute in whatever precision you want — but you should probably pass _all_ of the arguments in the same precision, as otherwise the accuracy will be limited by the least-precise argument.

This is also important for automatic differentiation, since that works by passing “just another number type” (`ForwardDiff.Dual`) that [keeps track of derivatives](https://arxiv.org/abs/1607.07892).

---

_[View the full topic](https://discourse.julialang.org/t/optim-jl-cant-optimize-function-which-includes-bigfloat-variables/65095)._