Opened 10 years ago

Last modified 9 years ago

#11599 closed enhancement

Wrap fan moriphism in toric morphism — at Version 10

Reported by: vbraun Owned by: AlexGhitza
Priority: major Milestone: sage-5.0
Component: algebraic geometry Keywords:
Cc: davideklund, fschulze, mmarco Merged in:
Authors: Volker Braun Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by vbraun)

Since we have the very nice fan morphism class, we should use it to define toric morphisms of toric varieties.

A big part of the patch is porting the scheme morphisms / hom sets to new-style parents and coercion. Categories should be better, too. Fixes #7946 as a side effect.

The first two patches bring some sanity to the scheme morphisms. The 3rd patch changes names of methods/classes to something more reasonable and adds documentation. The 4th patch actually adds toric morphisms defined by polynomials or fan morphisms.

Apply:

Change History (11)

comment:1 Changed 10 years ago by novoselt

We should. I have been using the following code so far:

def toric_morphism_list(phi, X, Y):
    r"""
    Given a fan morphism phi from X.fan() -> Y.fan(), return the list representation of the corresponding toric morphism.
    """
    x = [SR.var(x_i, domain="positive") for x_i in X.coordinate_ring().variable_names()]
    result = [1] * Y.fan().nrays()
    for rho, x_rho in zip(X.fan(1), x):
        sigma_prime = phi.image_cone(rho)
        degrees = sigma_prime.ray_matrix() \ phi(rho.ray(0))
        for i, d in zip(sigma_prime.ambient_ray_indices(), degrees):
            result[i] *= x_rho^d
    return result

def toric_morphism_dictionary(phi, X, Y):
    r"""
    Given a fan morphism phi from X.fan() -> Y.fan(), return the dictionary representation of the corresponding toric morphism.
    """
    x = [SR.var(x_i, domain="positive") for x_i in X.coordinate_ring().variable_names()]
    y = [SR.var(y_i, domain="positive") for y_i in Y.coordinate_ring().variable_names()]
    result = dict((y_i, 1) for y_i in y)
    for rho, x_rho in zip(X.fan(1), x):
        sigma_prime = phi.image_cone(rho)
        degrees = sigma_prime.ray_matrix() \ phi(rho.ray(0))
        for i, d in zip(sigma_prime.ambient_ray_indices(), degrees):
            result[y[i]] *= x_rho^d
    return result

Using the dictionary representation it is quite easy to compute pullbacks, the problem here is that the underlying map of total coordinate rings is not a ring homomorphism, since it is likely to involve roots. The following paper may be useful for "correct and general" implementation: http://arxiv.org/abs/1004.4924

comment:2 Changed 10 years ago by novoselt

P.S. Ordered dictionaries seem very appropriate for this approach, but we need to upgrade Python for them.

comment:3 Changed 10 years ago by vbraun

Thanks for pointing out the reference. Its fairly obvious that one has to use roots to write the maps but still its good to see that somebody worked out all the details. Though from a quick browse it seems like they don't elaborate on the relation with fan morphisms. E.g. the embedding of the obit closure can be written as a polynomial map in homogeneous coordinates but is not a toric morphism (given by a fan morphism).

My plan is to implement maps by homogeneous coordinate polynomials and maps by fan morphisms separately, with conversion methods from one to the other if it exists.

Eventually we should also have maps involving roots. I'm not sure how we should implement them; Just using symbolic ring variables would be simple but not play nice with compositions. At one point it would be good to write our own "Homogeneous coordinate ring" class that knows about the homogeneous rescalings. This would then allow for fractional powers in some nicer way. But I'll leave it for another ticket ;)

comment:4 Changed 10 years ago by novoselt

They don't elaborate the relation with fan morphisms because they consider arbitrary maps of toric varieties as varieties, including those that don't care about toric structure at all. In particular it is applicable to equivariant morphisms and orbit inclusions. And even in these cases it is necessary to use roots if one of the varieties is not smooth. E.g. a resolution of a singular variety would correspond to the identity map of lattices, but would involve roots in homogeneous coordinates.

comment:5 Changed 10 years ago by vbraun

I know. But without roots you can still have homogeneous polynomial maps and toric morphisms. Neither of the two is contained in the other. So I'm planning on implementing toric (equivariant) morphism separately.

comment:6 Changed 10 years ago by vbraun

  • Description modified (diff)

Ok so far no new functionality. But I think now the groundwork is done and we can actually do some work on top of it. I'm sorry for the giant patch :-)

comment:7 Changed 10 years ago by vbraun

Pickling is broken for some complex object like EllipticCurveTorsionSubgroup that contain circular self-references. This is a bug in unpickling the category framework, and will be addressed elsewhere. I've marked the offending unpickling doctests with # optional - pickling so we can fix them later.

Changed 10 years ago by vbraun

Updated patch

comment:8 Changed 10 years ago by vbraun

  • Authors set to Volker Braun
  • Description modified (diff)
  • Status changed from new to needs_review

comment:9 Changed 10 years ago by novoselt

The first patch has wrong extension!

comment:10 Changed 10 years ago by vbraun

  • Description modified (diff)

Oops, I clearly never read past the first letter of the extension ;-)

Note: See TracTickets for help on using tickets.