Re: [sage-devel] Re: issues with pushout construction?
On Sat, Aug 30, 2014 at 4:42 AM, Jonas Jermann wrote: > Hi Robert > > > On 30.08.2014 07:48, Robert Bradshaw wrote: I'm not sure (as mentioned the pushout construction is complex and there are many cases). But yes, that might work: Do a/several coercion check(s) _during_ pushout (during the while loop starting at line 3210) if needed instead of only at the end. So "coercion_reversed=False" (default) would mean that we assume that the current base coerces into construction(base) and "coercion_reversed=False" would mean that a coercion check should be done. If yes: Maybe something like "force_coercion_check" fits better? >>> >>> >>> That's an interesting suggestion. I'll try thinking about it a bit more >>> to see if this is an improvement over coercion_reversed. >> >> >> I think that coercion_reversed is the essential property here, as >> dropping this construction is essentially applying the reverse >> coercion, but checking for coercion allows one to see whether this >> reverse coercion must be applied to find a common parent. > > > Ok, that explanation makes sense! > > It still forces one to "decompose" functorial constructions > into coercion-compatible ones, meaning that there exists a coercion > from the base to functor(base), resp. coercion-reversed ones > (in the other direction). True. I almost wish we hadn't chosen categorical terminology for this, as it's primary application is coercion finding. > Also: What if later functors rely on the result of the previous one? > If a coercion was reversed the next functor might fail... > So we will probably have one further assumption. Namely that > coercion reversed functors must appear only once and as the last > one (in any construction (tower) of a space). I don't think this restriction is needed--if the next functor fails we simply bail out, but there's no need to not try. I pushed a new example, pushoud(QQ[x^2]^2, RR^2) -> RR[x^2]^2 vs. pushout(QQ[x^2] ^2, RR[x]^2) -> RR[x]^2. > Example: > Let CF = CuspForms, MF = ModularForms. > If CFRing(ZZ) = CFRingFunctor_coercion_reversed o MFRingFunctor (ZZ), > then pushout(RR, CFRing(ZZ)) would give MFRingFunctor(RR) (ok). > > The above example might make sense, but what if you have > a whole bunch of spaces with complex relations (e.g. cuspidal, > holomorphic, weak, meromorphic, quasi/non-quasi, sub/non-sub). > > I fear that in some situations it might be impossible/not practical > to find a simple construction mechanism. E.g. think about > pushout(QuasiCuspForms(ZZ), ModularForms(RR)). Yeah. > See e.g. also sage.modular.modform_hecketriangle.functors. > I used a different approach by replacing the base ring > with BaseFacade(base ring) to distinguish the "base ring" > from "other rings". There is only one FormsRingFunctor > with a parameter for the analytic type. The complexity is > moved to the merge function. The advantage is that (during > the pushout construction) the merge function has almost-complete > information of the situation and can decide accordingly. Yep. > In any case the suggested changes are still positive. As in positive review :-)? - Robert -- 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.
Re: [sage-devel] Re: issues with pushout construction?
Hi Robert On 30.08.2014 07:48, Robert Bradshaw wrote: I'm not sure (as mentioned the pushout construction is complex and there are many cases). But yes, that might work: Do a/several coercion check(s) _during_ pushout (during the while loop starting at line 3210) if needed instead of only at the end. So "coercion_reversed=False" (default) would mean that we assume that the current base coerces into construction(base) and "coercion_reversed=False" would mean that a coercion check should be done. If yes: Maybe something like "force_coercion_check" fits better? That's an interesting suggestion. I'll try thinking about it a bit more to see if this is an improvement over coercion_reversed. I think that coercion_reversed is the essential property here, as dropping this construction is essentially applying the reverse coercion, but checking for coercion allows one to see whether this reverse coercion must be applied to find a common parent. Ok, that explanation makes sense! It still forces one to "decompose" functorial constructions into coercion-compatible ones, meaning that there exists a coercion from the base to functor(base), resp. coercion-reversed ones (in the other direction). Also: What if later functors rely on the result of the previous one? If a coercion was reversed the next functor might fail... So we will probably have one further assumption. Namely that coercion reversed functors must appear only once and as the last one (in any construction (tower) of a space). Example: Let CF = CuspForms, MF = ModularForms. If CFRing(ZZ) = CFRingFunctor_coercion_reversed o MFRingFunctor (ZZ), then pushout(RR, CFRing(ZZ)) would give MFRingFunctor(RR) (ok). The above example might make sense, but what if you have a whole bunch of spaces with complex relations (e.g. cuspidal, holomorphic, weak, meromorphic, quasi/non-quasi, sub/non-sub). I fear that in some situations it might be impossible/not practical to find a simple construction mechanism. E.g. think about pushout(QuasiCuspForms(ZZ), ModularForms(RR)). See e.g. also sage.modular.modform_hecketriangle.functors. I used a different approach by replacing the base ring with BaseFacade(base ring) to distinguish the "base ring" from "other rings". There is only one FormsRingFunctor with a parameter for the analytic type. The complexity is moved to the merge function. The advantage is that (during the pushout construction) the merge function has almost-complete information of the situation and can decide accordingly. In any case the suggested changes are still positive. Best Jonas -- 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.
Re: [sage-devel] Re: issues with pushout construction?
On Wed, Aug 27, 2014 at 8:36 AM, Peter Bruin wrote: > Hi Jonas, > I just realized that my example was maybe a bad one. But imagine the same example for a space where the base ring _does_ coerce into the space. A base-changed base ring would then not coerce, so the pushout construction would be used and it would return the wrong space, resp. my arguments would make more sense there, no? >>> >>> Do you mean something like the following? Assume you have a >>> construction EvenSubspace() that applies to spaces of polynomials and >>> returns the subspace of all polynomials that only have even powers of >>> x. This of course includes constants. Suppose you have a ring >>> homomorphism A -> B and you want to do >>> >>> pushout(B, EvenSubspace(PolynomialRing(A, 'x'))) Very interesting example. >> Yes. I call this (implicit) "base change" where I mean "base" in the >> sense of "base of construction" (which in many cases starts as a >> ring). This assumes that the base object coerces into the constructed >> object. > > The fact that you need this last assumption may be a sign that pushout() > is not the right tool to do such a base change. An alternative would be > to implement the base_extend() method (for the objects you are > interested in) in such a way as to repeat the construction of that > object with the new base ring. > >>> I guess my approach would indeed eliminate the application of >>> EvenSubspace() because it doesn't know that B still coerces into >>> EvenSubspace(PolynomialRing(B, 'x')). >> >> "1.1 + x^2" would e.g. fail resp. not lie in EvenSubSpace. > > Yes, exactly. > >>> If this is the case, the criterion for eliminating a >>> "coercion-reversed" construction step F probably needs to be made >>> more strict: if both of the original objects still coerce into the >>> result of applying F, then we do want to apply F. Does that sound >>> reasonable? >> >> I'm not sure. I was hoping for a simple system where it is clear what >> happens. But since this would probably involve a partial redesign of >> the pushout construction all-together and since so many things depend >> on the old system I don't see this happening any time soon. :( > > Ideally (in my opinion), doing pushout(X, Y) would look for the most > specific common category C in which X and Y are objects, and ask that > category C to return the categorical push-out of X and Y in C (as an > object Z with maps X -> Z and Y -> Z, which would then be used as > coercion maps). But this is tricky: if X = ZZ[[x]] and Y = FF_p[x], > then you first want to deduce that C is the category of commutative > ZZ[x]-algebras, and to know that the push-out is the tensor product. > Then you have to implement this tensor product in a sufficiently > concrete way that it returns F_p[[x]] and not some abstract tensor > product object. This is definitely not doable yet. That would be cool. We're not there yet... >> Regarding your suggestion/fix: >> I'm not sure (as mentioned the pushout construction is complex and >> there are many cases). But yes, that might work: >> Do a/several coercion check(s) _during_ pushout (during the while loop >> starting at line 3210) if needed instead of only at the end. >> >> So "coercion_reversed=False" (default) would mean that we assume that >> the current base coerces into construction(base) and >> "coercion_reversed=False" would mean that a coercion check should be >> done. >> >> If yes: Maybe something like "force_coercion_check" fits better? > > That's an interesting suggestion. I'll try thinking about it a bit more > to see if this is an improvement over coercion_reversed. I think that coercion_reversed is the essential property here, as dropping this construction is essentially applying the reverse coercion, but checking for coercion allows one to see whether this reverse coercion must be applied to find a common parent. - Robert -- 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.
Re: [sage-devel] Re: issues with pushout construction?
On 27.08.2014 15:06, Peter Bruin wrote: Hi Jonas, I just realized that my example was maybe a bad one. But imagine the same example for a space where the base ring _does_ coerce into the space. A base-changed base ring would then not coerce, so the pushout construction would be used and it would return the wrong space, resp. my arguments would make more sense there, no? Do you mean something like the following? Assume you have a construction EvenSubspace() that applies to spaces of polynomials and returns the subspace of all polynomials that only have even powers of x. This of course includes constants. Suppose you have a ring homomorphism A -> B and you want to do pushout(B, EvenSubspace(PolynomialRing(A, 'x'))) Yes. I call this (implicit) "base change" where I mean "base" in the sense of "base of construction" (which in many cases starts as a ring). This assumes that the base object coerces into the constructed object. I guess my approach would indeed eliminate the application of EvenSubspace() because it doesn't know that B still coerces into EvenSubspace(PolynomialRing(B, 'x')). "1.1 + x^2" would e.g. fail resp. not lie in EvenSubSpace. If this is the case, the criterion for eliminating a "coercion-reversed" construction step F probably needs to be made more strict: if both of the original objects still coerce into the result of applying F, then we do want to apply F. Does that sound reasonable? I'm not sure. I was hoping for a simple system where it is clear what happens. But since this would probably involve a partial redesign of the pushout construction all-together and since so many things depend on the old system I don't see this happening any time soon. :( Regarding your suggestion/fix: I'm not sure (as mentioned the pushout construction is complex and there are many cases). But yes, that might work: Do a/several coercion check(s) _during_ pushout (during the while loop starting at line 3210) if needed instead of only at the end. So "coercion_reversed=False" (default) would mean that we assume that the current base coerces into construction(base) and "coercion_reversed=False" would mean that a coercion check should be done. If yes: Maybe something like "force_coercion_check" fits better? Note: That would actually work in general (always doing a coercion check) but for performance reasons it's nice to only do it when forced... Best Jonas -- 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.
Re: [sage-devel] Re: issues with pushout construction?
Hi Simon On 27.08.2014 14:46, Simon King wrote: On 2014-08-27, Jonas Jermann 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. Ok, you confirm what I thought: When using constructions it seems to be a prerequisite that the construction argument coerces into the constructed object. How would you then define the construction of modular/cusp forms rings/spaces over some base ring if not by a functor with argument base ring? But as I mentioned I made everything work in my case, I e.g. based the construction on a Facade of the base ring to distinguish the two but I don't consider this an elegant solution. :( 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. It does if you add the elements. Example adding a modular form and a cusp form (lets say over a different base ring so pushout is really called). Or modular forms of weight k inside the ring of modular forms, etc. Those are "sub" and not "quotient" and we want to be able to add them. 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. Yes, that makes sense. 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. Ok, good we agree on that then. It is what happens currently for some parents, namely those that violate the above mentioned prerequisite... 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() "RR(1) + some element of a space whose construction is based on ZZ" ^- This calls pushout(RR, constr(ZZ)) which should return constr(RR) which is in essence an implicit base change. The code of pushout/etc seems to indicate that this is intended and I think it is used for some/many(?) spaces. 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. I needed to generalize it, otherwise some very basic operations just fail. :-( Also sage forces one to define constructions, otherwise common parents won't be found. In any case, I have solved those issues for my implementation. I just wanted to raise my concern about the complex/seemingly contradictory behavior of pushout+constructions. But if everything is as it should be then that's fine by me (I have a "working" implementation). Best Jonas -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving
Re: [sage-devel] Re: issues with pushout construction?
Hi again I just realized that my example was maybe a bad one. But imagine the same example for a space where the base ring _does_ coerce into the space. A base-changed base ring would then not coerce, so the pushout construction would be used and it would return the wrong space, resp. my arguments would make more sense there, no? Best Jonas On 27.08.2014 14:27, Jonas Jermann wrote: On 27.08.2014 14:01, Peter Bruin wrote: What if there is no coercion in either direction? E.g. (base_ring, cusp forms ring) Maybe #16507 would make this work too if the CuspForms construction were implemented as a composition: ModularForms followed by CuspidalSubspace, where CuspidalSubspace would be a special case of SubspaceFunctor (i.e. with coercion_reversed=True in the terminology of #16507)? Then pushout() would remove the application of CuspidalSubspace when merging the two constructions. I still don't see how you would distinguish the base ring from a "normal" ring. Also, how would a base change work with your modification? pushout(RR, CuspidalSubSpace(ModularForms(ZZ))) resp. pushout(Base(RR), CuspidalSubSpace(ModularForms(Base(ZZ or If I understood it would do: ZZ -> ... -> RR -> ModularForms(RR) (and stop) resp. Base(ZZ) -> ... -> Base(RR) -> ModularForms(Base(RR)) (and stop) But instead it should return CuspidalSubSpace(ModularForms(RR)). What I mean is that in some cases the pushout construction should do "almost" the same as the construction itself but with coercion reversion the behavior would be completely different (since the "construction process" stops early). But maybe I missunderstood or this can still be solved in some smart way... I should also mention that in my case I have a whole bunch of "subspace constructions": cuspidal, holomorphic, weakly holomorphic, meromorphic Additional in each case modular or quasi modular and additional subspaces of the ambient spaces... In my case I used the above analytic properties as a parameter of the functor and let "merge" decide how to merge the analytic properties... Best Jonas -- 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.
Re: [sage-devel] Re: issues with pushout construction?
Hi Peter, On 27.08.2014 14:01, Peter Bruin wrote: Hi Jonas, What if there is no coercion in either direction? E.g. (base_ring, cusp forms ring) Maybe #16507 would make this work too if the CuspForms construction were implemented as a composition: ModularForms followed by CuspidalSubspace, where CuspidalSubspace would be a special case of SubspaceFunctor (i.e. with coercion_reversed=True in the terminology of #16507)? Then pushout() would remove the application of CuspidalSubspace when merging the two constructions. I still don't see how you would distinguish the base ring from a "normal" ring. Also, how would a base change work with your modification? pushout(RR, CuspidalSubSpace(ModularForms(ZZ))) resp. pushout(Base(RR), CuspidalSubSpace(ModularForms(Base(ZZ or If I understood it would do: ZZ -> ... -> RR -> ModularForms(RR) (and stop) resp. Base(ZZ) -> ... -> Base(RR) -> ModularForms(Base(RR)) (and stop) But instead it should return CuspidalSubSpace(ModularForms(RR)). What I mean is that in some cases the pushout construction should do "almost" the same as the construction itself but with coercion reversion the behavior would be completely different (since the "construction process" stops early). But maybe I missunderstood or this can still be solved in some smart way... I should also mention that in my case I have a whole bunch of "subspace constructions": cuspidal, holomorphic, weakly holomorphic, meromorphic Additional in each case modular or quasi modular and additional subspaces of the ambient spaces... In my case I used the above analytic properties as a parameter of the functor and let "merge" decide how to merge the analytic properties... Best Jonas -- 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.
Re: [sage-devel] Re: issues with pushout construction?
Hi Peter On 27.08.2014 13:03, Peter Bruin wrote: Hi Jonas, When I implemented Modular forms rings/spaces for Hecke triangle groups I ran into some issues with pushout / functors / constructions (correct me if I missunderstood something): Apparently the pushout construction implicitely assumes that there exists a coercion from the "construction argument" to the "construct": Ticket #16507 should solve this (at least to some extent) in situations where there is a coercion B -> A instead of A -> B. (Here B is the object resulting from a functorial construction applied to A; this can be used if B is a submodule of A, for example.) This won't address things like (base ring, cusp forms) -> (modular forms), though. Nice! I missed this ticket. This exactly addresses one of the issues I mentioned. I hope it can handle all possible complications (e.g. base changes, embeddings, etc). What if there is no coercion in either direction? E.g. (base_ring, cusp forms ring) My solution was to use a Facade of the base ring instead of the base ring itself and let it have an embedding into the base ring. Because embeddings are checked at the very beginning of the pushout construction (and only thanks to this) everything worked out. The important part above was that the facade is _not_ constructed from the base ring (otherwise we have again the same problem). All in all the pushout construction is rather complicated (there are many cases/situations) and when implementing new spaces one probably (unfortunately) has to look at the source / specific implementation of pushout in detail to ensure everything works appropriately in all cases. :-( Best Jonas -- 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.
Re: [sage-devel] Re: issues with pushout construction?
Hi On 27.08.2014 13:21, Simon King wrote: Hi Jonas, On 2014-08-27, Jonas Jermann wrote: There is supposed to be a coercion from A and B to C=pushout(A,B). But if e.g. B is constructed from A without having a coercion from A then the pushout will fail this (also see line 3217 of pushout.py). So either one severely restricts (functorial) constructions to "coercion"-compatible ones or the pushout construction fails even though there might be a very obvious candidate for pushout(A,B). Indeed, the pushout construction and the construction functors in sage.categories.pushout are an important tool to find coercion candidates. However, they are not supposed to be used for other "categorial" pushout constructions. I was talking/thinking about the implicit call of pushout when e.g. adding two elements from different parents... To avoid some misconceptions: Some examples that come to my mind: - All kinds of "projection" / non-injective constructions 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. - A = some graded ring, B = some homogeneous component of A Adding elements of A and B should give an element of A Here you have a coercion from B to A, and thus no construction functor or pushout construction is involved. 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. E.g. imagine an additional base change is involved, I think then pushout construction will be involved and the issue arises. Or are you sure that a situation "in spirit like above" never occurs/arises? - A = some base ring, B = the ring of cusp forms over A Adding elements of A and B should give an element of the ring of modular forms over A, however if B is constructed by A, then the pushout construction will always return B to which A does not coerce. 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? Best Jonas -- 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.
