Implement VectorInterface's scale!! and add! for InfinitePEPS

[pbrehmer]

We implement VectorInterface's scale and add functions for InfinitePEPS. Previously, this would spit out warnings since OptimKit had to use fallback functions.

Closes #225. Thanks @Yue-Zhengyuan for taking notice!

[codecov]

Codecov Report

Attention: Patch coverage is 51.72414% with 14 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/states/infinitepeps.jl	65.21%	8 Missing ⚠️
src/states/infinitepartitionfunction.jl	0.00%	3 Missing ⚠️
src/operators/infinitepepo.jl	0.00%	2 Missing ⚠️
src/states/infiniteweightpeps.jl	0.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/PEPSKit.jl	100.00% <ø> (ø)
src/environments/ctmrg_environments.jl	67.91% <ø> (ø)
src/states/infiniteweightpeps.jl	82.63% <0.00%> (ø)
src/operators/infinitepepo.jl	43.82% <0.00%> (+0.96%)	⬆️
src/states/infinitepartitionfunction.jl	21.31% <0.00%> (+0.34%)	⬆️
src/states/infinitepeps.jl	63.24% <65.21%> (-7.89%)	⬇️

🚀 New features to boost your workflow:

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

[Yue-Zhengyuan]

Shall we regenerate the docs to clear this warning message in them?

[pbrehmer]

Shall we regenerate the docs to clear this warning message in them?

I was about to do that. First though, I will fix the example caching mechanism such that it doesn't hash absolute paths (which means that everyone needs to rerun all the time) and insteads hashes relative paths.

[lkdvos]

Wait a second though, why is this hitting the VectorInterface functions and not our custom retraction implementation?

Keep in mind that this really is about vectors, and in principle the InfinitePEPS addition is not closed since it would require a larger bond dimension. We are (ab)using this in the context of the CTMRGEnv only in the rrule, as we are hijacking the same structure there for the cotangent, which is a linearized version so safe to add element wise like that, but in principle this doesn't apply to InfinitePEPS. Is this because we are doing the same for the peps gradients?

[pbrehmer]

I looked at the stacktrace again and apparently there are _scale! and _add! calls inside optimizer(..., ::LBFGS) that are used throughout the LBFGS algorithm (they cannot be caught inside the custom transport and retract function as far as I can tell). These _scale! and _add! functions default to scale!! and add!!.

I think in our case though, _scale! and _add! are only used to update the LBFGSInverseHessian.

[lkdvos]

Thanks for checking! Indeed, the "vectors" in H are gradients so these are linear, so I guess this should be fair :)
(I'm slightly uncomfortable about this entire thing, since it also looks easy to use this wrong, but I don't think it is worth it to go and add explicit tangent types either so 🤷 )

[pbrehmer]

Well actually you had a point: I forgot to add the scale!!(y, x, alpha) method, so that's in there now too :-)