Optim fails on v0.6


#1

… and I’m not really sure why.

To keep things simple, we’ve simply used two macros to repeat some fields which are in all Optimizers. The approach is the following (with gradient descent as an example):

type GradientDescentState{T}
    @add_generic_fields
    x_previous::Array{T}
    g::Array{T}
    f_x_previous::T
    s::Array{T}
    @add_linesearch_fields
end

macro add_generic_fields()
    quote
        method_string::String
        n::Int64
        x::Array{T}
        f_x::T
        f_calls::Int64
        g_calls::Int64
        h_calls::Int64
    end
end

macro add_linesearch_fields()
    quote
        x_ls::Array{T}
        g_ls::Array{T}
        alpha::T
        mayterminate::Bool
        lsr::LineSearches.LineSearchResults
    end
end

On v0.4 and v0.5 this works fine, but on v0.6 this fails. See https://travis-ci.org/JuliaStats/KernelDensity.jl/jobs/182979846 and http://pkg.julialang.org/logs/DiffEqParamEstim_0.6.log for packages whose tests fail on master due to Optim failing to be precompiled. We don’t support v0.6 at all yet, but I’d rather fix it now than later.

I can simply go back to repeating the field names in all Optimizer definitions, but I’m not really sure what the problem is or why it is prepending the Optim. in the Optim.method_string in the error. Any ideas?


#2

Maybe the variables have to be escaped?


#3

It’s a Optim bug due to missing esc.


#4

Thank you both, now it works. I wonder why it worked on v0.4-v0.5

(edit: well, almost… but I think it will work)
(edit^2: it works… :))


#5

Bugfix for macro hygiene was recently merged.


#6

So now we can’t rely on bugs for functionality any more? :slight_smile:

Thanks.


Accessing matrix (2x2) at [3] throws an error on master