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.
