#13183: Implement index(cone) for fan morphisms
--------------------------------------+-------------------------------------
Reporter: novoselt | Owner: mhampton
Type: enhancement | Status: new
Priority: major | Milestone: sage-5.2
Component: geometry | Resolution:
Keywords: toric | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Andrey Novoseltsev | Merged in:
Dependencies: | Stopgaps:
--------------------------------------+-------------------------------------
Comment (by novoselt):
Well, we don't really have fibers yet here and since it is defined as
"index over cone" I thought index(cone) is the way to go.
The initial reason for dropping M splitting was that I couldn't figure out
how to make it work nicely with sublattices when I need to split an
already quotient lattice. Since my replacement is a straightforward
implementation in terms of the dual lattice of a sublattice, in retrospect
I also think that it would be better. Speedwise I didn't do precise
measurements, but I was keeping an eye on timings of doctests and so far
they don't seem to be affected.
The index is always finite in the case when the lattice morphism is
surjective (assumption on p. 463) and fans are complete (implicit
assumption of the paper). Take P2 and embed A1 over one of its rays. Then
3 fixed points and 2 lines are not covered at all, one line has only its
distinguished point covered, and the torus itself has a lower dimensional
torus in it. So my proposal is to return None for non-covered cones and
infinity for two others. I'll also include a details explanation of this
example into documentation.
On the level of toric morphisms, I think (component, count) would be the
best output, with (None, None) for the case of non-covered orbits. For
"partially covered" ones I am not sure yet. (component, -count) where
count is multiplicity over distinguish point is one option, but I don't
think I like it. Maybe (component, count, codimension)? Where codimension
is for the "covered points" relative to the whole orbit. So for surjective
case it is 0 and in the above example 1. In this case perhaps we should
always return a triple. Anyway, let me know what you think! (Although I'll
be off the grid for a few days.)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13183#comment:3>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
