#14214: Cythoned homsets
----------------------------------------------+-----------------------------
Reporter: SimonKing | Owner: tbd
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.8
Component: performance | Resolution:
Keywords: Hom, cython, cached method | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Simon King | Merged in:
Dependencies: #14159, #12951 | Stopgaps:
----------------------------------------------+-----------------------------
Comment (by nbruin):
Replying to [comment:10 SimonKing]:
> I think it is enough to convince the coercion model...
Yes, I agree that the coercion model can work with "is" even if "=="
doesn't. It may surprise people every now and again, but the alternative
is almost certainly worse (besides being less efficient).
> In fact, this would be a problem. We can not simply use
`CachedRepresentation` here, because this uses comparison-by-== (and, as I
tried to explain, ''in the coercion model'' we want comparison-by-id even
for non-unique parents).
Good catch. However, the comparison-by-== happens on ''construction
parameters''. Hence, if someone implements some equal-but-not-identical
rings `R` and `S` then we'll have
{{{
sage: R=my_equal_but_not_identical_ring()
sage: S=my_equal_but_not_identical_ring()
sage: P1=PolynomialRing(R,'x')
sage: P2=PolynomialRing(S,'x') #this will look up P1
sage: P1 is P2
True
sage: P2.base_ring() is R
True
sage: S(1)+P2.1
Error: No coercion from S into P2.
}}}
That's a serious problem. If you're implementing something that can be
used in further (functorial) (cached) parent constructions that are
expected to have coercions they ''have'' to be `EqualityById`. Otherwise
you get the mess as above.
I doubt things like elliptic curves disappear into such cached parent
constructions, which was why I thought the problem might not be ''that''
bad.
> But couldn't we make Homset have the `ClasscallMetaclass`, inherit from
`EqualityById` ''and'' use the current cache logic from Hom in its
`__classcall__` method?
Homsets are important in coercion ''and'' have proper mathematical
meaning. If you make them consider their arguments by identity, you're
basically telling people "you can use `==` as an equivalence relation on
your class to some extent, but as far as maps are concerned, `id` is what
really matters". I'm fine with that, but you are restricting people's
ability to define and use `==` as they see fit.
> Inside of the coercion framework, I think ''nothing'' prevents us from
comparing non-unique parents by identity---except old code. In that way,
we have freedom to choose non-trivial coercions between non-identical
copies of a parent.
I think you're right on that in principle. There is a bit of an issue that
"coercions between equal-but-not identical" parents are fundamentally
between ""equivalent" objects, whereas the coercion framework seems to
work best when there's a hierarchy. It's an invitation to loops in the
coercion graph, inviting non-commuting paths. However, I think that's more
an issue of the mathematical problem that of how we're modelling it.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14214#comment:13>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
