Fix _init_identity_matrix in bfgs.jl

[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

All modified and coverable lines are covered by tests ✅

Project coverage is 85.43%. Comparing base (7cc8328) to head (84ca7f0).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1089   +/-   ##
=======================================
  Coverage   85.43%   85.43%           
=======================================
  Files          45       45           
  Lines        3276     3276           
=======================================
  Hits         2799     2799           
  Misses        477      477           

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

[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..