Closed kellertuer closed 8 months ago
Ah, one thing that is a bit tricky here is that without the atol=
a lot of checks where quite fine with integer matrices, now they are not, maybe adopting the already sometimes used max_eps
makes that nicer to tolerate those again. Most tests failing currently is due to integer values.
Locally the tests run fine by now – here it seems on Julia 1.10 there is a problem with DiffEq (again?).
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
b2d83b3
) 99.57% compared to head (a63e8ae
) 99.57%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
BoundaryValueDiffEq.jl again :disappointed:
I've opened an issue: https://github.com/SciML/BoundaryValueDiffEq.jl/issues/148
With the last fix it really runs locally just fine (probably with an older version of BoundaryValueEq still), that is indeed a bit annoying.
@kellertuer could you check if there is anything else to adapt due to https://github.com/JuliaManifolds/ManifoldsBase.jl/pull/177 ?
At first glance there might be two further things (but I am on mobile)
default_approximation_method
is the new function and we have an old (deprecated) default_estimation_method
now hereExtrinsicEstimationMethod
got a little new feature to store the method using in the extrinsic space (since usually that was only implicitly mentioned in the docs that one uses gradient in the embedding or such) – so the constructor without parameter (defaulting to GradientDescentEstimation
I would think)
- the
ExtrinsicEstimationMethod
got a little new feature to store the method using in the extrinsic space (since usually that was only implicitly mentioned in the docs that one uses gradient in the embedding or such) – so the constructor without parameter (defaulting toGradientDescentEstimation
I would think)
The most common use case for extrinsic estimation is when the embedding in Euclidean and we use EfficientEstimator there.
Sure that also sounds like a very good default. I think I just saw the gradient one somewhere, but yours is indeed maybe the more common case.
The new approximation methods and their dispatch should now be fixed. I also circumvent the inconsistency from StatsBase for now, which mainly means we have a bit of code that can be considered duplication (if StatsBase would not be inconsistent).
As discussed therein, this fixes #630.
I carefully went through all
isapprox
and as soon as there was a comparison to zero, I adapted from existing cases a nonzeroatol
in the signature and passed that down.this still needs a bit of checks for failing tests, but should work otherwise I hope.