#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 SimonKing):
Replying to [comment:9 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.
Since the patch doesn't touch the way how things are cached, it doesn't
affect the patch. But it does affect what I try to do next, so, let's
discuss it.
> 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).
> ...
>
> 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.
They ''are'' an issue, if the equality-by-id paradigma is used in some
parts and isn't used in other parts of the coercion framework. They are
not an issue, if the coercion framework consistently uses equality-by-id
even on non-unique parents, as I am now explaining.
I am fine with parents P1, P2 that evaluate equal but are non-identical.
But then, I think it makes sense that Hom(P1,X) and Hom(P2,X) are non-
identical, too. The question is whether they should evaluate equal, and
here I actually have no very strong opinion, except that I like fast hash
and fast equality test...
Let f be a coercion map from P1 to X. Now, we consider an element p of P2.
In elder versions of Sage, it used to be the case that f was stored in a
usual dictionary as an attribute of X. "Usual dictionary" means: If you
have P2 and inspect the cache for a coercion to X, you'll find f. But
f.domain() is not the same as P2.
Being "not the same as" P2 means: We can't simply coerce p via f---we must
first coerce p into P1 and then apply f. Namely, if P1==P2, we certainly
expect that there is a coercion from P2 to P1. But it could be that, for
example, a non-trivial base change is involved in this coercion.
This is why now the coercion maps are stored in a `MonoDict`, whose keys
are compared by identity: Looking for a coercion from P2 to X, you will
correctly find that it has not been found yet, and so you have the chance
to detect the coercion from P2 to X via P1 with a non-trivial base change.
I think this is a sane approach '''and''' it works fine with non-unique
parents.
This is why I think that non-unique parents are not an issue in the
coercion framework---but it is essential to be consistent, i.e.,
''inside'' of the coercion framework one should consistently use
comparison by identity even for non-unique parents (as in the P1-versus-P2
example above).
> 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 "==".
I think it is enough to convince the coercion model...
> Of course such `EqualityById` but non-`CachedRepresentative` parents are
useless as dictionary keys
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).
But couldn't we make Homset have the `ClasscallMetaclass`, inherit from
`EqualityById` ''and'' use the current cache logic from Hom in its
`__classcall__` method? The advantage would be that in some parts of Sage
Homsets are created without calling the Hom function. Putting the Hom-
logic into a `__classcall__`, we would have Homsets cached in this case,
too!
> 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`.
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.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14214#comment:10>
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.
