#9326: Add cohomology of toric varieties
----------------------------------+-----------------------------------------
Reporter: vbraun | Owner: AlexGhitza
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.5.1
Component: algebraic geometry | Keywords:
Author: Volker Braun | Upstream: N/A
Reviewer: Andrey Novoseltsev | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Changes (by novoselt):
* status: needs_review => needs_work
Comment:
1. General documentation comment: I would appreciate precise definitions
and/or links (Wikipedia?) to detailed description of Chern/Todd classes
etc. I think that others would appreciate it too.
1. `primitive_collections` - I don't like the statement that it returns
generators of Stanley-Reisner ideal. I'd prefer to have the combinatorial
description (which is already present there) and a note that they
*correspond* to generators of this ideal.
1. `Stanley_Reisner_ideal` and `linear_equivalence_ideal` - do they
really belong to the fan class? The fact that it is necessary to pass a
ring to them suggests that maybe not. (Also, it is not clear what is the
point to cache the result for a potentially new ring next time.) How about
moving them to toric variety class, removing the ring argument, and making
them return an ideal in `QQ[coordinate names of the variety]`? Note that
such a ring is unique in Sage, so if you "construct" it twice in two
different functions, it actually will be the same one. So your code
{{{
R = PolynomialRing(QQ, variety.variable_names())
self._polynomial_ring = R
I = variety._fan.linear_equivalence_ideal(R) +
variety._fan.Stanley_Reisner_ideal(R)
super(CohomologyRing, self).__init__(R, I, names=variety.variable_names())
}}}
will be replaced with
{{{
R = PolynomialRing(QQ, variety.variable_names())
self._polynomial_ring = R
I = variety.linear_equivalence_ideal() + variety.Stanley_Reisner_ideal()
super(CohomologyRing, self).__init__(R, I, names=variety.variable_names())
}}}
It may be good actually to give some name to this ring `R` and make it
accessible from the toric variety as well. (Does it have some standard
name? It suppose it should, since it is the ambient ring of the Stanley-
Reisner ideal.)
1. Regarding names of divisors and divisor classes. I personally think
that it is just fine to have them the same, but maybe they should be
different from coordinate names. The reason is that I would like to inject
both coordinates and divisors into the global name space and work with
them. I think that I would prefer coordinates `x, y, z2, z3, z4` to be
translated into `D_x, D_y, D2, D3, D4`. This may be a bit hard to
implement, since it requires tracking which variables were given explicit
names and which were created automatically, maybe `D_x, D_y, D_z2, D_z3,
D_z4` or just `D0, D1, D2, D3, D4` would be better. In any way there
should be a way for the user to provide custom names. I think there should
be one more optional argument to the toric variety constructor and if it
was not given, then the first call to `cohomology_ring` can specify these
names. (I don't mind having a separate follow-up ticket for this and can
provide a patch on top of this one.)
1. `cohomology_ring` - can we remove "... as a quotient of a polynomial
ring." from the first line of documentation? It is no longer quite true
since there are special classes for cohomology now.
1. `CohomologyRing` constructor - input is not described in the
documentation and from the code it is clear that not any toric variety
will work. The second exception is a bit misleading since it says that
`CC` is required as the base field, but actually it checks only
characteristics (we already had some discussion about it). How about the
following: the constructor should check if the base field is exactly
complex (by which I mean any complex field in Sage independent of
precision, maybe function fields over complex one are also OK?) if not, it
should raise an exception. However there should be a function like
`X.treat_base_field_as_CC()` and if it was called, then all cohomology
computations proceed without checks of the base field. That way we
preserve mathematical correctness yet allow users to use any
representation they want at their own risk. (To avoid potential
complications with cached and created objects, this function should not be
reversible, i.e. it is not OK to turn off `CC`-check and later turn it
back on for the same variety.)
1. `truncate_to_degree` - the name does not match what the function
actually does. I would expect it to drop all terms higher than the given
degree, but it also "truncates" lower terms. Can we change it to something
like `part_of_degree`?
1. `exp` - would be nice to mention in the documentation that there
should be no constant part and explain why. Its output description is also
not quite clear, I think it would be better to write that it returns a
cohomology class.
1. `cohomology_basis` - in the first output case you meant `H^d`, not
`H^\bullet`.
1. `cohomology_class` - can we add some message to `NotImplementedError`?
Note also that #9470 should allow implementing `cone.cohomology_class()`
as you wanted.
1. `volume_form` - I think documentation should explain the normalization
of this form. What assumptions on the variety does this function make?
Simplicial? Complete? Generated by maximal-dimensional cones? It would be
nice to check for those that are not checked by cohomology ring
construction.
1. `integrate` - would be nice if the documentation explained that
integration is done with respect to `volume_form`, i.e. that normalization
is the same.
1. `Todd_class` - can we add a message to `NotImplementedError`?
1. `Euler` - in the spirit of `Chern_class` etc., I think it would be
more consistent to call it `Euler_number` and add a standard notation
alias `X.chi()`. Out of curiosity - why is there a special case for
complete varieties? Should it be faster?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9326#comment:12>
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.
