Proof-of-concept: _implements trait #1957
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1957 +/- ##
==========================================
- Coverage 88.37% 88.30% -0.08%
==========================================
Files 126 126
Lines 31639 31667 +28
==========================================
Hits 27962 27962
- Misses 3677 3705 +28 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
src/fundamental_interface.jl
Outdated
| # TODO: deal with type parameters: if `T` is `FreeAssociativeAlgebraElem{ZZRingElem}` | ||
| # and `f` has a method for `FreeAssociativeAlgebraElem` then we should still consider | ||
| # this a match. |
There was a problem hiding this comment.
What about the case that there is some method for PolyRing and we have a QQPolyRing. Is this a match?
What about T = QQPolyRing and f(::PolyRing{QQFieldElem})?
I am not sure if there is a deterministic and consistent semantic of match that you want here
There was a problem hiding this comment.
No, a method for PolyRing should not "match" QQPolyRing within _implements_directly. The idea is that this function is meant for methods that match a "concrete" type: you are not going to define e.g. a factor(::QQPolyRing) just to also throw a NotImplementedError.
I do think this is well-defined: The type T is a concrete type here. What I can do (well, at least in theory) is to "remove parameters" from it, to e.g. turn Vector{Int} into Vector, and then compare to the methods in meth (possibly after removing parameters there, too).
There was a problem hiding this comment.
I guess using typename(T).wrapper might be one option...
|
I would be in favor of moving this to |
fingolfin
force-pushed
the
mh/implements
branch
from
e9c28d5 to
1d4ae96
Compare
|
Should I move this to |
fingolfin
added
the
release notes: not needed
... to allow fine control over which things to test in the conformance tests and which not.
Proof of concept of a "trait" that allows checking for some unary functions whether they are implemented for a given type. See also oscar-system/Oscar.jl#4394 for background.
So e.g. one can write
_implements(ZZRingElem, factor)to determine whetherfactoris implemented.This is different from
applicableandhasmethodin that it allows dealing with "generic" methods that delegate to other functionality. For example, we have an implementation ofis_nilpotentfor arbitrary polynomials, but it delegates tois_nilpotentfor the coefficient ring. So we can only consider it as "implemented" if it is implemented for the coefficient ring.Right now the way this is implemented it requires manual work to "model" these relations explicitly, and so in general it won't be reliable for "arbitrary" unary functions. Thus I named it
_implementsto mark it as "internal sharp tool, use with caution".My personal main use for this is in the conformance test suite. But I think it might also be useful for some algorithms which may be able to do something "better" if e.g.
factoris available. Though of course such algorithms could often work by wrapping thefactorcall(s) intotry/catchblocks. But this approach is not useful for the conformance tests: trying to put them inside a@testleads to ugliness like this. It also isn't sufficient to e.g. callfactor(zero(R))insidetry/catchto determine iffactoris available for elements of the ringRbecause there are some "generic methods" that work only on some arguments (e.g. zero...) and so this test may give misleading results.If we follow PR #1954 and turn the conformance tests into a package extension, this method could also be moved into the
ConformanceTestmodule if nobody is interested in this functionality beyond the conformance tests.