#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:5 SimonKing]:
> ... those parts of Sage that still work with non-unique parents.
What follows is a bit of a rant that probably doesn't immediately affect
your patch here. However, it's something I've seen crop up around the
coercion/category framework in the last couple of weeks a little and I
think has some relevance for work in this direction in general:
One design consideration I haven't seen mentioned much is that some parent
constructors have very good reasons to return a fresh copy every time one
is requested (i.e., don't do the `cached_function` metaclass thing that
`UniqueRepresentation` does). The reason is that some parents are
complicated structures (they tend to model complicated mathematical
objects) that have too many aspects about them for them to be implemented
as immutable. An example is `EllipticCurve`, where a Mordell-Weil basis is
definitely not part of the construction data, but the basis choice (if
found at all!) can be important and dealing with that unexpectedly
changing is just too painful.
One could design these things differently, e.g., don't make the Mordell-
Weil basis part of the elliptic curve itself, but the reality is that
design choice hasn't been made in sage and changing that design now will
be very difficult.
The problem arises elsewhere too: Sometimes you DO want multiple
isomorphic-but-not-identical copies of objects. It's convenient to have
multiple bivariate polynomial rings over QQ, for instance. We have that in
sage by making generator names part of the definition of polynomial rings.
For other objects, for instance elliptic curves, there are no convenient
generator names to distinguish multiple copies (the fundamental
constructor being `EllipticCurve([a1,a2,a3,a4,a6])`), but there is still a
reasonable need for having multiple nonidentical copies (never mind the
practical mutability properties).
It terms of the coercion framework I have hopes these are not too much of
an issue. I think elliptic curves are sufficiently high up the chain of
complexity that people are happy to apply explicit homomorphisms to move
things around, and hopefully this is true for most objects (the elephants
in the room here are number fields: they are expected to behave nicely wrt
coercion and yet are sufficiently complex that they have data hanging off
them that makes it hard to consider them immutable. A lot of the problems
may be hidden because it's relatively hard to run into exactly the same
representation of the field twice)
The consistent thing for such non-unique-by-necessity parents is to make
"==" indeed just "is", so that uniqueness is simply forced. This means
{{{
EllipticCurve([1,2,3,4,5]) != EllipticCurve([1,2,3,4,5])
}}}
which is fine with me, since they are isomorphic but not uniquely so.
However, I'm not sure how easy it will be to convince other people of such
a strict interpretation of "==".
Of course such `EqualityById` but non-`CachedRepresentative` parents are
useless as dictionary keys in most situations in the sense that `D[p]=a`
can always be written as `p.D=a` (the only way of getting `a` is by having
a hold of `p` itself anyway and there is no way to regain a hold of `p`
once you've lost it), but that might not be too much of an issue.
Anyway, please keep in mind: It's very unlikely (and probably even
undesirable) that all parents will ever be essentially
`CachedRepresentative` (or equivalent) and convenience requirements will
likely prevent us from making all of them `EqualityById`. I suspect this
puts bounds on how far you can push the coercion framework and various
homomorphism caching strategies.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14214#comment:9>
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.
