Return lower order results

[fredrikekre]

Fix #92 perhaps

This returns the value of the function by default. How can we do this for hessian? If we do it the way we do it now that would mean we load the tensor twice, and extract the result twice...

TODO:

• Update tests
• Update docs
• Run benchmarks

[KristofferC]

This is pretty much exactly what I had planned to do. Nice :). I don't think loading and unloading the second order tensor twice will be a problem compared to having to do it for the Hessian.

For Hessian I thought something like this could work?

function hessian{F}(f::F, v::Union{SecondOrderTensor, Vec})
      s = zero(eltype(v))
      gradf = y -> begin
         s, fv1 = gradient(f, y)
         return s, fv1
      end
      fv, ∇fv = gradient(gradf, v)
      return s, fv, ∇fv 
end

This might give bad performance because julia sometimes have problems when you modify a variable in a closure.

[fredrikekre]

Didnt see your solution until I pushed mine...

The problem with yours is that gradf returns 2 things, and that doesn't work with gradient.

[fredrikekre]

But I guess your gradf can be modified to just return fv1, but will s still be 0 then?

[KristofferC]

return fv, ∇fv?

[fredrikekre]

no? this is not gradient, its _gradient, I use this only in hessian since we need a version of gradient that returns only the gradient and not the value.

[KristofferC]

Oh, sorry.

[fredrikekre]

But might not be the best solution though

[fredrikekre]

Tests should pass now, but maybe we should think a bit more on the hessian. Will do some other stuff now.

[fredrikekre]

Maybe we should reverse the order as well? You would expect that a function called gradient should first and foremost return the gradient, and then perhaps some other stuff.

OTH with the order we have now the value is always the first output, regardless if it is gradient or hessian, and the gradient is always output 2 for both gradient and hessian as well.

Thoughts?

[KristofferC]

kappa

[fredrikekre]

Thats already fixed 👍

[fredrikekre]

Oh, right... forgot to update the doctests :) Will do it later.

[fredrikekre]

Seems like it is about two times slower for both hessian and gradient, but it is a bit unfair to compare since the new functions calculate the values too I guess.

[fredrikekre]

Will make some better benchmarks later.

[KristofferC]

You can run only the AD benchmarks with run_benchmarks("ad_bench", @tagged "ad")

[fredrikekre]

@inferred tests fails on nightly :/

[KristofferC]

Minimized to:

julia> using StaticArrays

julia> s = rand(SVector{3})
3-element StaticArrays.SVector{3,Float64}:
 0.710116 
 0.382896 
 0.0640471

julia> s * 0.0
3-element StaticArrays.SVector{3,Float64}:
 0.0
 0.0
 0.0

julia> @code_warntype s * 0.0

[fredrikekre]

same with just rand too:

@code_warntype rand(SVector{3})

[KristofferC]

Maybe JuliaLang/julia#19421

[KristofferC]

Only the rand looks good to me.

[KristofferC]

The docs (not docstrings) should perhaps say something about the :all.

[fredrikekre]

Sure, btw, is it too verbose with the examples in the docstrings? Maybe we can skip examples for the :all version?

[KristofferC]

The hessian is a bit verbose, yeah. Could maybe just assign them to variables and not print the result, f, ∇f, ∇²f = hessian(f, S, :all)?

[KristofferC]

Perhaps make this into a header not that the section is becoming quite long. ## Examples

[KristofferC]

Anything left to do here?

[fredrikekre]

No, not necessary to run benchmarks, since we now left the original functions untouched.

[KristofferC]

Wasnt docstrings supposed to be inserted here https://kristofferc.github.io/ContMechTensors.jl/latest/man/automatic_differentiation.html ?

[fredrikekre]

Yes, https://github.com/KristofferC/ContMechTensors.jl/pull/94/files#diff-3457962e803ef1880a1bf358cb6c0402R24
It happens locally at least

[KristofferC]

Docs run on nightly which are failing? Change docs to run on v0.5?