stack overflow using Optim.jl with Double64

[protogeezer]

using current versions of Optim and DoubleFloats on v1.2.0-rc2
julia> using Optim

julia> using DoubleFloats

example from Optim web page

julia> f(x) = (1.0 - x[1])^2 + 100.0 * (x[2] - x[1]^2)^2
f (generic function with 1 method)

julia> optimize(f, [Double64(0.0), Double64(0.0)])

• Status: success

• Candidate solution
  Error showing value of type Optim.MultivariateOptimizationResults{NelderMead{Optim.AffineSimplexer,Optim.AdaptiveParameters},Float64,Array{DoubleFloat{Float64},1},DoubleFloat{Float64},DoubleFloat{Float64},Array{OptimizationState{DoubleFloat{Float64},NelderMead{Optim.AffineSimplexer,Optim.AdaptiveParameters}},1},Bool}:
  ERROR: StackOverflowError:
  Stacktrace:
  [1] ini_dec(::DoubleFloat{Float64}, ::Int64, ::Array{UInt8,1}) at ./printf.jl:1008 (repeats 80000 times)

same example with BigFloat

julia> optimize(f, [BigFloat(0.0), BigFloat(0.0)])

• Status: success

• Candidate solution
  Minimizer: [1.00e+00, 1.00e+00]
  Minimum: 3.525527e-09

• Found with
  Algorithm: Nelder-Mead
  Initial Point: [0.00e+00, 0.00e+00]

• Convergence measures
  √(Σ(yᵢ-ȳ)²)/n ≤ 1.0e-08

• Work counters
  Iterations: 60
  f(x) calls: 118

[JeffreySarnoff]

Thank you for bringing this to my attention. I have found the cause.
Julia uses a fast, accurate way to convert floating point values into strings.
Recently, the way that the conversion is prepared changed for nonstandard
floating point types. The change should not have been an issue -- and I'm sure
(in part thanks to you) it will get resolved soon both within DoubleFloats and
so Julia does not let the default handler fall through so deeply.

I am bringing this to their attention too, so you can have this work properly.

[quinnj]

The issue (stack overflow) is probably due to this line:

ini_dec(x::Real, n::Int, digits) = ini_dec(float(x),n,digits)

where ini_dec is expecting that float(::DoubleFloat) will return one of Float16, Float32, Float64, or BigFloat. I'm guess that it doesn't, so it just calls itself leading to the stack overflow. The potentially easy solution is to define float(x::DoubleFloat) = # nearest Float64/BigFloat value, but I'm also not familiar enough w/ the package to know if that's possible. Otherwise, you might have to implement Base.ini_dec for DoubleFloat yourself, but I have no idea what that function is supposed to do.

[JeffreySarnoff]

Who wrote it or who would know why the _dec functions are separated as they are and have fallbacks the way they do?

[quinnj]

@StefanKarpinski ^^

[JeffreySarnoff]

It was @StefanKarpinski in 2014!

[StefanKarpinski]

It was stefan in 2012, that's just when they got moved into stdlibs.

[JeffreySarnoff]

ahh do you recall why that function is there and how to cobble it?

[StefanKarpinski]

Not really but I can take a look.

[JeffreySarnoff]

It is not clear if that is the only one of ?the three? similar tied-together functions that end _dec which I would want to provide to be sure there is no opportunity to fall into reasonable assumptions that were not looking for varietal floating point types.

[JeffreySarnoff]

fixed in master, merge v0.9.5 pending

[protogeezer]

Thanks!

…

On Aug 11, 2019, at 12:28 AM, Jeffrey Sarnoff ***@***.***> wrote: fixed in master, merge v0.9.5 pending — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.