Opened 11 years ago

Closed 11 years ago

#10325 closed defect (fixed)

Cohomology Ring of toric varieties not unique

Reported by: vbraun Owned by: AlexGhitza
Priority: major Milestone: sage-4.6.2
Component: algebraic geometry Keywords:
Cc: novoselt Merged in: sage-4.6.2.alpha0
Authors: Volker Braun Reviewers: Andrey Novoseltsev
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description

The ToricVariety.cohomology_ring() is not unique, which eventually causes problems with isomorphic but not identical toric varieties:

sage: cone1 = Cone([(1,0)]);  cone2 = Cone([(1,0)])
sage: cone1 is cone2
False
sage: fan1 = Fan([cone1]);  fan2 = Fan([cone2])
sage: fan1 is fan2
False
sage: X1 = ToricVariety(fan1);  X2 = ToricVariety(fan2)
sage: X1 is X2
False
sage: X1.cohomology_ring() is X2.cohomology_ring()
False
sage: TDiv = X1.toric_divisor_group()
sage: X1.toric_divisor_group() is TDiv
True
sage: X2.toric_divisor_group() is TDiv
True
sage: TDiv.scheme() is X1   # as you expect
False
sage: TDiv.scheme() is X2   # perhaps less obvious, but toric_divisor_group is unique!
False
sage: TDiv.scheme() == X2   # isomorphic, but not necessarily identical
True
sage: TDiv.scheme().cohomology_ring() is X2.cohomology_ring()  # this is where it gets tricky
False
sage: TDiv.gen(0).Chern_character() * X2.cohomology_ring().one()
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)

/home/vbraun/opt/sage-4.6/devel/sage-main/<ipython console> in <module>()

/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/structure/element.so in sage.structure.element.RingElement.__mul__ (sage/structure/element.c:11399)()

/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/structure/coerce.so in sage.structure.coerce.CoercionModel_cache_maps.bin_op (sage/structure/coerce.c:6138)()

/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/structure/coerce.so in sage.structure.coerce.CoercionModel_cache_maps.canonical_coercion (sage/structure/coerce.c:7586)()

/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/structure/coerce.so in sage.structure.coerce.CoercionModel_cache_maps._coercion_error (sage/structure/coerce.c:13134)()

RuntimeError: There is a bug in the coercion code in Sage.
Both x (=[1]) and y (=[1]) are supposed to have identical parents but they don't.
In fact, x has parent 'Rational cohomology ring of a 2-d affine toric variety'
whereas y has parent 'Rational cohomology ring of a 2-d affine toric variety'
Original elements [1] (parent Rational cohomology ring of a 2-d affine toric variety) and [1] (parent Rational cohomology ring of a 2-d affine toric variety) and maps
<type 'NoneType'> None
<type 'sage.structure.coerce_maps.DefaultConvertMap_unique'> Conversion map:
  From: Rational cohomology ring of a 2-d affine toric variety
  To:   Rational cohomology ring of a 2-d affine toric variety

Attachments (1)

trac_10325_make_toric_CohomologyRing_unique.patch (2.6 KB) - added by vbraun 11 years ago.
Initial patch

Download all attachments as: .zip

Change History (4)

Changed 11 years ago by vbraun

Initial patch

comment:1 Changed 11 years ago by vbraun

  • Cc novoselt added
  • Status changed from new to needs_review

comment:2 Changed 11 years ago by novoselt

  • Reviewers set to Andrey Novoseltsev
  • Status changed from needs_review to positive_review

I really really don't like this:

sage: X2.toric_divisor_group().scheme() is X2
False

It seems to me that either schemes must be unique as well, or their divisor groups should be separate. I think that the second option makes more sense since schemes are "the main ones" and divisor groups automatically will be unique if their schemes decide to be uniqie.

However this is not the problem of toric varieties only, other schemes are also non-unique while divisor groups are. In the long run it should be taken care of, but for now the attached patch offers a partial solution and I don't think that it creates any new problems. So positive review, I'll open a new ticket for the bigger problem.

As I concluded from some discussions on sage-combinat, FormalSum which is used as a base for divisor groups should eventually be deprecated as CombinatorialFreeModule is the new way to go. Perhaps sometime we can do the switch and free derived objects from uniqueness decisions.

comment:3 Changed 11 years ago by jdemeyer

  • Merged in set to sage-4.6.2.alpha0
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.