#10342: Divisor groups and cohomology rings should not make uniqueness decisions
----------------------------------+-----------------------------------------
Reporter: novoselt | Owner: AlexGhitza
Type: defect | Status: new
Priority: major | Milestone:
Component: algebraic geometry | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Comment(by novoselt):
Replying to [comment:1 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 ;-)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10342#comment:2>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
