#9972: Add toric lattice morphisms
----------------------------------+-----------------------------------------
Reporter: novoselt | Owner: mhampton
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-4.6
Component: geometry | Keywords:
Author: Andrey Novoseltsev | Upstream: N/A
Reviewer: Volker Braun | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Changes (by novoselt):
* status: needs_review => needs_info
Comment:
I am now putting finishing touches on plotting, but then return back to
morphisms.
After actually working on morphisms a bit, I had second thoughts about
class organization. In particular, I didn't see how `FanMorphism` can fit
nicely into Sage and I didn't even understand what it is mathematically. A
fan is a collection of cones with certain restrictions, right? Then a fan
morphism should be a map between sets of cones, in our case finite. But
that's not what we want, we rather want a morphism between supports of
fans, which is given on points of the space by a linear map. Put it
another way, we want a `ToricLatticeMorphism` restricted to the support of
the domain. During construction of such a morphism we have to check that
everything is compatible, which can be quite expensive. During any
application of this morphism to a point, we should check that this point
is in the domain and this is also non-trivial (the only thing that will
work for general fans is checking this point against every generating
cone). So if we do have a special class for `FanMorphism`, how about this
definition: "it is a morphism between toric lattices with distinguished
fans in the domain and codomain which are compatible with this morphism."
I.e. the domain is still a whole toric lattice and there is no need for
complicated checks. One can write then
{{{
sage: phi = FanMorphism(lattice_morphism, F1, F2)
sage: phi.image_cone(cone_of_F1)
<some cone of F2>
sage: phi.preimage_cones(cone_of_F2)
<a tuple of cones of F1>
}}}
Going further, I don't think anymore that we should derive special fans
for domain/codomain of morphisms between toric varieties themselves, let's
call this class `ToricMorphism`. The problem I have is that a single
variety can be a (co)domain of different morphisms. (I definitely need
such functionality.) This can make it very inconvenient to work with
divisors and classes because they will get confused which parent do they
belong to, we will have to work with coercion, and the code may need to
look something like this:
{{{
sage: fan = ...
sage: X = ToricVariety(fan)
sage: fan = X.fan() # This is already a bit strange...
sage: phi = ToricMorphism(matrix(...), X, Y)
sage: psi = ToricMorphism(matrix(...), Z, X)
sage: X_fan_codomain = psi.codomain().fan() # These two lines are plain
confusing
sage: X_fan_domain = phi.domain().fan()
sage: phi.domain().rational_divisor_group() ==
psi.codomain().rational_divisor_group()
???
}}}
All four fans above are mathematically the same, the only difference is
what kind of extra functionality do they get. But they will be different
Python objects and associated toric varieties will be also different
objects for no apparent reason, i.e. how these reasons can be explained to
a user rather than a developer?
So I think that either morphisms derive their own fans for domain/codomain
and use them internally without actually changing the varieties they were
created for (i.e. `phi.domain().fan()` is the same as `X.fan()`, but
`phi.domain_fan()` can be something specialized), or they store this
information in some other way and return (pre)images taking cones of usual
fans as arguments.
I recall that we already had a similar argument in the beginning, whether
or not we need any kind of specialized cones, which provide clean access
to new features. I just checked how many new features got added:
* TWO methods for `Cone_of_fan`: `star_generators` and
`star_generator_indices`. (There were actually many new methods here
originally, but others migrated to plain cones.) Still, I think that this
class is justified, because these are very natural operations to perform
on cones that belong to a fan. Also, a cone cannot quite belong to several
fans in the sense that its internal data structures are severely tied to a
fan and it is very important performance-wise. (E.g. intersection of cones
of the same fan is incomparably easier/faster than for arbitrary ones, and
this will remain true even when polyhedra are made fast.)
* ONE method for `Cone_of_toric_variety`: `cohomology_class`. Here I feel
less convinced that it is necessary, `cone.cohomology_class()` does not
feel more natural to me than `X.cohomology_class(cone)`. However, I think
there are more methods added here by patches which are not applied in my
queue and something else may come up during later development. If not, we
should probably reconsider this class, because it would be nice to have
{{{
sage: ToricVariety(fan).fan() is fan
True
}}}
* Hypothetical cones of (co)domain would each add one more method, but
make it difficult/inconvenient to deal with multiple morphisms, while the
whole point of making new classes should be making life easier...
For this ticket I propose the following:
1. Rename `make_compatible_with` to `subdivide_domain`.
1. Add to `ToricLatticeMorphism` a method like `image_fan(domain_fan)` to
construct the "natural" fan in the codomain, as you have suggested.
1. Add `FanMorphism(ToricLatticeMorphism)` which mathematically is what I
have said above, will live in the same Hom-space as lattice morphisms, and
will behave in the same way (including `domain` and `codomain` returning
toric lattices), except that it also has `domain_fan` and `codomain_fan`
methods returning fans which are guaranteed to be compatible with the
morphism. It also has `image_cone` and `preimage_cones`, results are
cached (perhaps it is more efficient to compute them at once for all cones
or even do it during compatibility check).
1. Cones of fans also get `image_cone` and `preimage_cones` methods that
take as an argument a `FanMorphism` with appropriate fans.
A follow-up ticket will add `ToricMorphism` for arbitrary scheme morphisms
between toric varieties and `ToricEquivariantMorphism` for those coming
from `FanMorphisms`.
Let me know what you think!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9972#comment:5>
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.
