[doc] explicit definition of arguments

[RossBoylan]

Although I can often sort of guess, could you please provide an explicit definition of the function arguments for the functions defined here, both the type and substantive meaning?

Some examples I've seen suggest that some of the arguments can be omitted, perhaps to be filled in by automatic differentiation. Explicit discussion of that would be useful too.

Some of the source code (twicedifferentiable.jl, incomplete.jl) is similarly uncommented.

[pkofod]

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.

[RossBoylan]

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

---

From: Patrick Kofod Mogensen notifications@github.com Sent: Tuesday, June 18, 2019 12:53:48 AM To: JuliaNLSolvers/NLSolversBase.jl Cc: Boylan, Ross; Author Subject: Re: [JuliaNLSolvers/NLSolversBase.jl] [doc] explicit definition of arguments (#104)

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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JuliaNLSolvers_NLSolversBase.jl_issues_104-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DAATGAMXWQYBH6DN7QHAJQ2DP3CIAZA5CNFSM4HY3IR62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX5QRLQ-23issuecomment-2D502991022&d=DwMCaQ&c=iORugZls2LlYyCAZRB3XLg&r=nh70E5-mX2XsDe5lrDDMt_ZRqqGMcdTmTrRLvNmttYA&m=cDpwwTiEriQC6ezKSz5bXcyDDFTy3h5PAXKLSU75Z-o&s=J9PXgIIErOV35Mkj3fmB8q42O57zfrKg-FZ8x6U9V4Y&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AATGAMRNC6KRC4KLQRRNKV3P3CIAZANCNFSM4HY3IR6Q&d=DwMCaQ&c=iORugZls2LlYyCAZRB3XLg&r=nh70E5-mX2XsDe5lrDDMt_ZRqqGMcdTmTrRLvNmttYA&m=cDpwwTiEriQC6ezKSz5bXcyDDFTy3h5PAXKLSU75Z-o&s=RDblxNg2aTdWI_CvXV6-w6R7j4oKr_ityGbSBsegd20&e=.

[pkofod]

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.

[pkofod]

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.

[RossBoylan]

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

[pkofod]

You're missing the "typical input"

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

not

    f = TwiceDifferentiable(myll)

[RossBoylan]

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)?

[pkofod]

yup :)