Opened 10 years ago

Last modified 10 years ago

## #10342 new defect

# Divisor groups and cohomology rings should not make uniqueness decisions

Reported by: | novoselt | Owned by: | AlexGhitza |
---|---|---|---|

Priority: | major | Milestone: | |

Component: | algebraic geometry | Keywords: | |

Cc: | vbraun | Merged in: | |

Authors: | Reviewers: | ||

Report Upstream: | N/A | Work issues: | |

Branch: | Commit: | ||

Dependencies: | Stopgaps: |

### Description

See the problem discussed in #10325.

### Change History (4)

### comment:1 follow-up: ↓ 2 Changed 10 years ago by

### comment:2 in reply to: ↑ 1 Changed 10 years ago by

Replying to vbraun:

I don't quite understand what you want here. Divisor groups and cohomology rings are parents for divisors and cohomology classes, respectively. Parents should be unique, right?

Right. So if you try to get the divisor of the same group twice, you should get exactly the same object (i.e. `is`

-comparison should return true).

But if you have two *different* scheme objects and they happened to represent the same mathematical scheme, I don't think that their divisor groups should be the same object in memory.

The only issue is that the

`Parent.scheme()`

method for the underlying scheme is misguided. You can only access an isomorphic scheme, and this should be documented. We could change the name to`isomorphic_scheme()`

or something like this, but I don't think that would be particularly helpful.

It won't, instead I think that `scheme()`

method should return what is reasonable to expect - the scheme for which this divisor group was constructed.

Perhaps in these cases there is no much difference between these isomorphic schemes, because they are not just isomorphic - they have the same internal representation taking into account ordering of rays, variables, etc. But I perceive it as a somewhat twisted logic that these almost the same schemes decided to be different (it does not matter if it was right or wrong) and then derived objects like cohomology rings and divisor groups decide to treat these schemes as exactly the same.

The situation would get really bad if we decided that fans should be `==`

-equal if they are mathematically equal, because divisors and classes use the ray ordering of underlying fans and assume that it does not change. (Eliminating this assumption means switching from lists and indices in them to dictionaries indexed by vectors and while I have not tried to do it, I would imagine a considerable slow down of basic operations, so I am against of even trying it.) Since the current implementation of `==`

means exactly the same representation, it is not a problem, but conceivably it can create similar problems sooner or later if not for toric varieties then for some other schemes.

Hope I am more clear now, although I don't plan to work on this ticket in the near future ;-)

### comment:3 follow-up: ↓ 4 Changed 10 years ago by

I think that, in this case, the `__cmp__`

of toric varieties should be strengthened so that `X1==X2`

if and only if `X1 is X2`

. Otherwise you have `X1==X2`

but you would be unable to add divisors and cohomology classes. Moreover, these operations would yield a confusing error message since `X1._repr_()==X2._repr_()`

.

### comment:4 in reply to: ↑ 3 Changed 10 years ago by

I though about changing `__cmp__`

, but the current behaviour is more uniform with cones and fans. Besides, I think that it is good to have some kind of total order on objects that does not change from session to session. In this case the only meaningful option for varieties with "everything the same" is to be equal.

Adding divisors and cohomology classes can be handled via coercion, I think, but making schemes and related classes work nicely with coercion may require a bit of effort. I definitely want to have it eventually even for not equal varieties: e.g. if I extended the base field of `X`

by adding some coefficients, I want to be able to mix divisors of "the original `X`

" and the new one. This should work for all schemes, not just toric varieties.

**Note:**See TracTickets for help on using tickets.

I don't quite understand what you want here. Divisor groups and cohomology rings are parents for divisors and cohomology classes, respectively. Parents should be unique, right?

The only issue is that the

`Parent.scheme()`

method for the underlying scheme is misguided. You can only access an isomorphic scheme, and this should be documented. We could change the name to`isomorphic_scheme()`

or something like this, but I don't think that would be particularly helpful.