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: Changed 10 years ago by 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?

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.

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

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: Changed 10 years ago by vbraun

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 novoselt

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.