#16344: Virtual rays of fans in non-saturated lattices
-------------------------------------+-------------------------------------
       Reporter:  jkeitel            |        Owner:
           Type:  defect             |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.3
      Component:  algebraic          |   Resolution:
  geometry                           |    Merged in:
       Keywords:  toric              |    Reviewers:
        Authors:  Jan Keitel         |  Work issues:
Report Upstream:  N/A                |       Commit:
         Branch:                     |  f567a24c9c9a6137f7e6274f54a0713e706c8e48
  u/jkeitel/fan_comparison_sublattice|     Stopgaps:
   Dependencies:                     |
-------------------------------------+-------------------------------------

Old description:

> Fan comparison does not work if one fan lives in a non-saturated
> sublattice (I hope that's the right term):
>
> {{{
> sage: N = ToricLattice(1)
> sage: B = N.submodule([(2,)]).basis()
> sage: f = Fan([Cone([B[0]])])
> sage: B = N.submodule([(1,)]).basis()
> sage: f2 = Fan([Cone([B[0]])])
> sage: f == f2
> Traceback (most recent call last):
> ...
> ArithmeticError: cannot interpret [(1)] as a sublattice of Sublattice
> <N(2)>!
> }}}
>
> The reason is simply that
> {{{
> sage: f.virtual_rays()
> }}}
> throws this exception. I don't know enough about fans to understand
> whether they can be made to work in such lattices, too, but it is also
> required in other places that the lattices for toric varieties be
> saturated anyway. Therefore I'am attaching a branch that catches this
> exception and does not compare the virtual rays of fans in such lattices,
> which seems to fix the problem.
>
> Lastly, why should one even worry about this? Since
> {{{ToricDivisorGroup}}} inherits from {{{UniqueRepresentation}}}, it
> compares fans of newly created toric varieties with all fans in the
> cache. If one therefore has one malfunctioning fans, creating divisors in
> 'good' toric varieties will fail, too:
>
> {{{
> sage: N = ToricLattice(2)
> sage: B = N.submodule([(2,1), (1,2)]).basis()
> sage: f = Fan([Cone([B[0], B[1]]), Cone([B[1], -B[0]-B[1]]),
> Cone([-B[0]-B[1], B[0]])])
> sage: X = ToricVariety(f)
> sage: aK = -X.K()
>
> sage: B = N.submodule([(1,0), (1,1)]).basis()
> sage: B[0].parent() is B[0].parent().saturation()
> True
> sage: f2 = Fan([Cone([B[0], B[1]]), Cone([B[1], -B[0]-B[1]]),
> Cone([-B[0]-B[1], B[0]])])
> sage: X2 = ToricVariety(f2)
> sage: from sage.schemes.toric.divisor import ToricDivisorGroup
> sage: aK2 = -X2.K()
> ArithmeticError: cannot interpret [(1, 2), (-1, -3)] as a sublattice of
> Sublattice <N(1, 2), N(0, 3)>!
> }}}

New description:

 One can currently not compute the virtual rays of fans in non-saturated
 lattices:
 {{{
 sage: N = ToricLattice(1)
 sage: B = N.submodule([(2,)]).basis()
 sage: f = Fan([Cone([B[0]])])
 sage: f.virtual_rays()
 Traceback (most recent call last):
 ...
 ArithmeticError: cannot interpret [(1)] as a sublattice of Sublattice
 <N(2)>!
 }}}

 Lastly, why should one even worry about this? Since
 {{{ToricDivisorGroup}}} inherits from {{{UniqueRepresentation}}}, it
 compares fans of newly created toric varieties with all fans in the cache.
 If one therefore has one malfunctioning fans, creating divisors in 'good'
 toric varieties will fail, too:

 {{{
 sage: N = ToricLattice(2)
 sage: B = N.submodule([(2,1), (1,2)]).basis()
 sage: f = Fan([Cone([B[0], B[1]]), Cone([B[1], -B[0]-B[1]]),
 Cone([-B[0]-B[1], B[0]])])
 sage: X = ToricVariety(f)
 sage: aK = -X.K()

 sage: B = N.submodule([(1,0), (1,1)]).basis()
 sage: B[0].parent() is B[0].parent().saturation()
 True
 sage: f2 = Fan([Cone([B[0], B[1]]), Cone([B[1], -B[0]-B[1]]),
 Cone([-B[0]-B[1], B[0]])])
 sage: X2 = ToricVariety(f2)
 sage: from sage.schemes.toric.divisor import ToricDivisorGroup
 sage: aK2 = -X2.K()
 ArithmeticError: cannot interpret [(1, 2), (-1, -3)] as a sublattice of
 Sublattice <N(1, 2), N(0, 3)>!
 }}}

--

Comment (by jkeitel):

 I've taken the liberty to force push the new changes, since we cannot do
 much with the old ones and I suppose it's very unlikely that anybody will
 have based their branch on them. The new branch does exactly what written
 above and I've changed the description of the ticket accordingly.

 Thanks Andrey!

--
Ticket URL: <http://trac.sagemath.org/ticket/16344#comment:7>
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 unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to