Closed ArnoStrouwen closed 8 months ago
Attention: 47 lines
in your changes are missing coverage. Please review.
Comparison is base (
f87583e
) 66.50% compared to head (3099e72
) 65.44%.
Files | Patch % | Lines |
---|---|---|
src/factorization.jl | 12.24% | 43 Missing :warning: |
src/default.jl | 63.63% | 4 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Resolve the conflicts?
@avik-pal can you review this one?
When can issquare
be nothing
? If we can't resolve the dimensions can't we assume rectangular
Oh I see it is to disambiguate between no assumption provided from the user. This PR seems fine in that case
Fixes many of the method ambiguities in this package. Things I'm still unsure about:
First, for
defaultalg
there is dispatch forAbstractSciMLOperator
as well as dispatch forOperatorAssumptions{Nothing}
.AbstractSciMLOperator
dispatches based onA.A
.OperatorAssumptions{Nothing}
dispatches based onissquare(A)
. If both occur together, I don't know which order to apply them. Currently, it first gets rid of theNothing
, but this meansissquare
has to be defined forOperators
.Second, there are remaining ambiguities regarding:
e.g. with:
I'm not sure how to resolve these, I'm assuming we want as little
do_factorization
as possible?Third, for some special matrix types, such as diagonal, there is dispatch to always use the same method, no matter the algorithm. But there are also fallback methods for most algorithms to work for general
A
. This design choice leads to tons of additional function definitions to resolve ambiguities between the two.