Fix type of initial_scale in reset_search_direction!

[odow]

x-ref https://discourse.julialang.org/t/error-loaderror-methoderror-no-method-matching-init-identity-matrix-componentvector-float32-vector-float32-tuple-axis-float64/112211

I don't really know the implications of this, but I assume this is the fix.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 85.26%. Comparing base (77501f4) to head (588d95b).
⚠️ Report is 82 commits behind head on master.

Files with missing lines	Patch %	Lines
src/utilities/perform_linesearch.jl	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1089   +/-   ##
=======================================
  Coverage   85.26%   85.26%           
=======================================
  Files          45       45           
  Lines        3502     3502           
=======================================
  Hits         2986     2986           
  Misses        516      516           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[devmotion]

I think it might be more consistent to apply the pattern in

Optim.jl/src/multivariate/solvers/first_order/bfgs.jl

Line 81 in 7cc8328

initial_scale = T(method.initial_stepnorm) * inv(norm(gradient(obj), Inf))

to

Optim.jl/src/utilities/perform_linesearch.jl

Line 18 in 7cc8328

initial_scale = method.initial_stepnorm * inv(norm(gradient(d), Inf))

.

Generally, isn't the error caused by an incorrectly typed initial_stepnorm provided by the user? If you deal with Float32 data, you can avoid the problem by specifying also initial_stepnorm as a Float32. That being said, I guess

Optim.jl/src/multivariate/solvers/first_order/bfgs.jl

Line 81 in 7cc8328

initial_scale = T(method.initial_stepnorm) * inv(norm(gradient(obj), Inf))

makes it a bit more convenient for users.

[pkofod]

I think it might be more consistent to apply the pattern in

I agree

[pkofod]

Generally, isn't the error caused by an incorrectly typed initial_stepnorm provided by the user? If you deal with Float32 data, you can avoid the problem by specifying also initial_stepnorm as a Float32. That being said, I guess

Sure, but usually I think it should be enough to supply x0 as the type you want even if there might be some cases where it's harder to prepare for that.. but I think we can apply the "correct" pattern here for the user..

[pkofod]

@odow would you like to update this PR? Or would you rather not do more here. I think @devmotion 's assessment is correct here.

[odow]

Updated. I don't have a test or a reproducible example; I was just following the stack trace from the discourse post.

[pkofod]

Updated. I don't have a test or a reproducible example; I was just following the stack trace from the discourse post.

okay, thanks. Yes it can be a bit hard here to have a user-facing example (from the top level call to optimize) because you need it to hit a reset... I will have a look again, maybe I can write a test than artificially calls internals as if it had iterated and had to reset