#9713: Add toric Chow group
----------------------------------+-----------------------------------------
Reporter: vbraun | Owner: AlexGhitza
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.6.1
Component: algebraic geometry | Keywords:
Author: Volker Braun | Upstream: N/A
Reviewer: Andrey Novoseltsev | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Comment(by vbraun):
A1. The discussed above fact that this patch implement the full Chow group
should be reflected in module level documentation.
OK
A2. Documentation from `ChowCycle.__init__` should be moved to the class
docstring, otherwise it is invisible.
I've added a note to the `ChowCycle` class documentation that you are
not supposed to manually construct them. The `__init__` docstring is
hidden on purpose.
A3. Behaviour of check=False is strange for it: usually such an option
omits validity checks assuming that user will take care of it. Here it
seems to allow a different form of input. Is it inherited from the base
class? If so, maybe it should be fixed there...
Yes, it is inherited from `FGP_Element`. I tried to fix it there, but
then I ended up trying to rewrite it for the new coercion model. And that
attempt was quite unsuccessful, all of sage.modules is interrelated and
you can't just change one class...
A4. Line 170 misses the second `":"` in the end.
OK
A5. The first words of some docstrings have extra `s`'es, like "Returns"
and "Intersects".
OK
A6. It would be nice if the documentation and example for `count_points`
were expanded/clarified a little bit more. The phrase `"integral over the
dual cohomology class"` does not make it clear what is the integrand and
to what the cohomology class is dual. Is it the Chow cycle in both cases?
The example starts with a divisor and then integrates the square of this
divisor and counts points on the intersection of the Chow cycle of this
divisor with the original divisor. How about starting with some Chow cycle
with non-zero point count and then showing how to get a corresponding
cohomology class and integrate it?
There is no easy way to get the Poincare dual (In fact, it exists only
if the variety is smooth). I've clarified the example a bit.
A7. For `intersect_with_divisor` it would be nice to give a reference to
the used algorithm (Fulton p.97?). I think also that
`intersection_with_divisor` would be a better name, since the function
returns the intersection rather than updates the original cycle. (I do
realize now that the same consideration should have been applied to some
methods that I have added...) By the way, this function has no
input/output description. And perhaps `i = _gamma.pop()` does the same
thing as `i = iter(I_gamma).next()` in a little cleaner fashion. (It does
alter the set, but it is not used anyway.) What exactly is tested by the
long test with many zeros in this function? This function says that
divisor must be Cartier, but it is not checked, is it intended? Am I
right that it actually makes sense to use it with Q-Cartier divisors if
the Chow group is also rational?
I renamed it to `intersection_with_divisor()` and expanded on the
documentation which should now answer your questions...
In principle you are right with the Q-Cartier divisors, but in
practice this will not work because multiplication QQ * QQ-Chow cycle is
broken. The problem is that the parent does not adhere to the new coercion
model. I could hack around it, but then this should really be fixed
elsewhere.
A8. `Chow_cycle` method of toric divisors does not have a doctest and
input/output description.
OK
A9. Line 394 misses closing quotes after True.
OK
B1. It is probably worth mentioning what is the point of A(Cone(cone))
after A(cone). I actually didn't even know that Cone(cone) works!
Fortunately, it works as expected ;-)
OK
B2. In `_rational_equivalence_relations` I find it very difficult to
understand the LaTeX expression, which does not get typeset in the
documentation (since it is a private method), especially since it does not
explain what is `"! over ="`, what is `n_{\rho, \sigma}`, and how d, k, n,
and p are related (I guess pairs of them are equal). I think that this
description should be moved to some visible place (module documentation
or relation_gens?) and there should be a reference to where it was taken
from.
I moved it to `relation_gens` and added more explanations.
B3. What is the purpose of the super call in `__eq__` for Chow groups? Do
we want anything but a Chow group equal to a Chow group?
Now it only returns `self is other`.
B4. I think that `_cone_to_V` would be more efficient if it was
implemented via a dictionary. I don't know how significant such a speed up
will be in real computations, but I think it is worthwhile to do this
change.
Its only constructing a unit vector. Surely the run time for
intersection computations is dominated by the matrix normal form
computations and not the construction of unit vectors?
B5. There is a note in degree method about smooth varieties: "Using the
cohomology ring instead of the Chow group will be much faster." I think
that this is a very important point and it should be also mentioned in the
module level documentation and in the Chow group method of toric
varieties. (Perhaps with explanations of why this is the case.) Examples
of this method are very nice! I'd remove the sentence "The resulting fan
is not the fan over a convex cube."
OK
B6. I think it would be more natural if gens without parameters returned
the union of all gens of specified degree. Is it possible to implement?
(I.e. is it possible to force the quotient module to use these generators?
I definitely don't suggest "just" returning union of degree generators.)
I tried it but couldn't get it to work. The base `FGP_Module` has no
provision to explicitly set the generators, and bad things happen if they
are different from the internal normal form of the basis matrix.
B7. For `relation_gens` wouldn't it be more natural to return elements of
the covering module, i.e. lifts of the current output?
You can do that with `A.relations().gens()`. I added a note to
`relation_gens`.
B8. Line 979: you meant `== QQ`.
Yes, fixed.
B9. Would it make sense to derive `ChowGroup_degree_class` from some kind
of a group rather than `SageObject`?
Ideally they would be some other parents with coercions into the full
(mixed-degree) Chow group. But then thats a lot of work for very little
benefit. Not to mention that the base `FGP_Module` does not adhere to the
new coercion model, so it'll be hackisch...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9713#comment:25>
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.
