[doc] explicit definition of arguments about nlsolversbase.jl HOT 8 CLOSED

Yes, and no. May I ask why you're using these types directly? I should not be necessary to do so in order to use Optim/NLsolve/LsqFit.

Much of this functionality is going to be obsolete shortly after the summer, so I'm sort of reluctant to spend too much time polishing it off, but I'll happily help you out with specific issues. It will be obsolete because i'm currently (whenever I can find some spare minutes) rewriting all of the code in NLSolversBase/Optim/NLsolve/LsqFit in a much better/simpler/more generic way.

from nlsolversbase.jl.

from nlsolversbase.jl.

I'll have to track it down, but I was imitating the example of maximum likelihood fitting in, I think, the Optim documentation.

Ah, okay. Yes. I've been trying to get rid of all user-facing explicit references to NDifferentiable. It's not that you're not allowed to use them, but you only need them for that last bit of performance that few users will need, because typically it's the call to f and g that is the limiting factor, not whether something is updated optimally in-place. In some cases this is not true, but often it is.

from nlsolversbase.jl.

I see it now. It's here https://julianlsolvers.github.io/Optim.jl/stable/#examples/generated/maxlikenlm/ . It's because the hessian needs to be explicitly calculated at the end to do inference. In that case, constructing the objective type might be beneficial.

from nlsolversbase.jl.

When I try to imitate the example with

# defined in a module
# uses some other functions from the module
using StatsModels
using Optim, NLSolversBase

function mysolve(formula, df)
    xprep = prep(formula, df)
    myll(β) = -myllike(β, xprep)
    f = TwiceDifferentiable(myll)
    r = optimize(f, zeros(size(xprep.x, 2)), BFGS())
    p = Optim.minimizer(r)
    num_hess = hessian!(f, p)
    vcv = inv(num_hess)
    return (β=p, sd = sqrt.(diag(vcv)), r=r, nms=xprep.names, vcv=vcv)
end

# next line evaluated in a workspace with access to module's namespace
b = @time mysolve(f, df)

The result is

MethodError: no method matching NLSolversBase.TwiceDifferentiable(::getfield(Main.MyFirst, Symbol("#myll#12")){NamedTuple{(:x, :allcombo, :names),Tuple{Array{Float64,2},Array{Float64,2},Array{String,1}}}})
Closest candidates are:
  NLSolversBase.TwiceDifferentiable(::Any, !Matched::AbstractArray{T,1} where T) at C:\Users\rdboylan\.julia\packages\NLSolversBase\KG9Ie\src\objective_types\twicedifferentiable.jl:103
  NLSolversBase.TwiceDifferentiable(::Any, !Matched::Any, !Matched::AbstractArray{T,1}) where T at C:\Users\rdboylan\.julia\packages\NLSolversBase\KG9Ie\src\objective_types\twicedifferentiable.jl:50
  NLSolversBase.TwiceDifferentiable(::Any, !Matched::AbstractArray{T,1} where T, !Matched::Real; autodiff, inplace) at C:\Users\rdboylan\.julia\packages\NLSolversBase\KG9Ie\src\objective_types\twicedifferentiable.jl:103
  ...
in top-level scope at base\util.jl:156
in mysolve at KBD2\MyFirst\src\MyFirst.jl:37
# line 37 is the invocation of TwiceDifferentiable

from nlsolversbase.jl.

You're missing the "typical input"

    f = TwiceDifferentiable(myll, zeros(size(xprep.x, 2)))

not

    f = TwiceDifferentiable(myll)

from nlsolversbase.jl.

That runs--well I get an error later, but I think it's unrelated.
What does the "typical input" represent?

Though it's not related the documentation, I'm curious how the TwiceDifferentiable call I made got hooked up to a particular function. The definitions in twicedifferentiable.jl all seemed to require far more info than I supplied, while the ones in incomplete.jl required somethink like an InplaceObjective, and my understanding is that julia doesn't do type conversions behind the scenes. Oh, maybe it's this one:
function TwiceDifferentiable(f, x::AbstractVector, F::Real = real(zero(eltype(x))); autodiff = :finite, inplace = true)?

from nlsolversbase.jl.

yup :)

from nlsolversbase.jl.