Hi Jonas, On 2014-08-27, Jonas Jermann <jjerma...@gmail.com> wrote: > I was talking/thinking about the implicit call of pushout when e.g. > adding two elements from different parents...
... which is exactly what coercion is about. Hence, if your functorial construction does not yield a coercion from the start object to the resulting object O, then don't use ConstructionFunctor to describe the construction, and most importantly do not let O.construction() return this non-coercing construction. Put clearly: If O.construction() returns something that is not suitable for sage.categories.pushout.pushout, then it is a bug. >> It is not assumed that coercions are injective. In fact, a projection >> (say, from a ring to a quotient ring) will usually become a coercion. > > So if we add an element of a subspace with an element of the ambient > space we get the projection of the sum? I would argue this is not the > desired behavior in many situations. If you just have a subspace, then why do you think that an arbitrary (non-canonical!) projection would suddenly come into play? Of course, if something is constructed as a sub-structure, then the inclusion map is the only candidate for a coercion. Note that a pushout does not occur in this situation. However, if you construct something as result of a particular projection (i.e., if you don't have a *sub* space but a *quotient* space), then it is desired to use this particular (and no other) projection as a coercion map. > Ok, it was a simplification. I just feel uncomfortable if a function > (pushout(A,B)) which is supposed to return a common parent of both > fails to do that. If pushout(A,B) returns a parent C so that not both A and B coerce into C, then it's a bug. > E.g. imagine an additional base change is involved, > I think then pushout construction will be involved A base change is not dealt with by a construction functor, but by setting the coercion explicitly. This occurs, for example, with the space of symmetric functions. Here, you have one space without a particular choice of basis, and then you have different realisations of the space, each with a particular choice of a basis, and mutual coercions. However, no functorial construction (hence, no pushout) is involved: sage: A = SymmetricFunctions(QQ); A Symmetric Functions over Rational Field sage: S = A.schur(); S Symmetric Functions over Rational Field in the Schur basis sage: W = A.witt(); W Symmetric Functions over Rational Field in the Witt basis sage: W.has_coerce_map_from(S) True sage: S.has_coerce_map_from(W) True sage: S.construction() sage: W.construction() sage: A.construction() >> That's not my field of expertise, but it sounds like one shouldn't use a >> sage.categories.pushout.ConstructionFunctor to describe the construction >> of B by A. The construction may be functorial, but there is no >> ConstructionFunctor... > > What do you mean? Quite simply: Do not over-generalise. The pushout construction is a quite interesting part of Sage's coercion system, but many (perhaps most) coercions in real-life computations do not involve pushouts. Cheers, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
