#12892: Toric fibration morphisms
--------------------------------------+-------------------------------------
Reporter: vbraun | Owner: AlexGhitza
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.1
Component: algebraic geometry | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers: Andrey Novoseltsev
Authors: Volker Braun | Merged in:
Dependencies: #12361 | Stopgaps:
--------------------------------------+-------------------------------------
Comment (by novoselt):
I find the first patch a bit difficult to understand due to mixing several
things defining the embedding: a cone and two dictionaries of rays. Also
`defining_cone` argument is not documented in the constructor of the orbit
morphism.
Orbits are in 1:1 correspondence with cones of the original fan, so it
makes perfect sense to pass this information and store it (as it is
currently done in the patch).
Mathematically, this is all that is needed, but since we have so far
issues with supporting quotient lattices and instead the fan of the orbit
lives in a "regular lattice", we need to keep the correspondence somehow.
As it is done by some matrix, perhaps that's what we need to pass to the
constructor and store.
Instead, the current version constructs a codomain_ray->domain_ray
dictionary, it is passed to the constructor and constructor reverses it
into domain_ray->codomain_index dictionary. Note that the map does not
have to be one-to-one for non-simplicial fans, so this dictionary just
picks some random representative for a domain ray. The choice may affect
the decision on whether embedding can be realized as a polynomial map or
not.
I also think it is confusing to store non-primitive generators for rays
and treat a ray as not found if a non-primitive generator is found. We do
represent rays throughout the code just by their generators, but it is
always assumed that they are normalized.
As a feature request it would be nice to have support for maps given by
homogeneous polynomials in the other direction, i.e. a map from the 12
orbit of P112 to P1 can be given as (0:z1:z2) -> (z1^2:z2) and this will
work for all orbits with powers corresponding to that "non-primitivity of
generators". Or is it already implemented and I am missing something?
Anyway, concretely: how about passing and storing `defining_cone` and
`projection_matrix` as base pieces of data and relying on them for
consecutive computations?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12892#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.
