Hi Andrey,
I like the ToricLattice/ToricLatticeMorphism/FanMorphism, though I
would call the latter ToricMorphism. Domain/Codomain always reminds me
of "Cohomology Operations and Homology Cooperations" (Capter 17 in
Switzer) but if we want to use that nomenclature then thats fine with
me :-)
As for whether to subclass Cone/Cone_of_fan further, your proposal of
not doing this is precisely what I did the first time when I
implemented toric morphisms. Great Minds think alike :-) And I found
it to be a big mistake, and had to completely rewrite my code. Here
are some of the reasons:
* As you say, you end up with two totally different interfaces for the
same functionality: Everything that can be computed from a cone can be
gotten from
cone.compute_this(). And most things have a relative (fiberwise)
version that you then get from morphism.compute_this(cone)? That gets
very confusing after a while.
* Cones of a fan don't just need to know their relative positions,
you'll also want choices of lattice generators and lattice quotients
cached by the cone. For all of this there is a relative version. If
you don't allow one to extend the Cone to a Cone_of_fan and a
Cone_of_domain then you need to cache everything in hashes
{cone:property} that you maintain by hand. I would argue that
subclassing cones further decreases the complexity (and probability of
bugs), not the other way round.
* OOP prefers cone.compute_this() over fan.compute_this(cone).
* There are no circular dependencies / imports.
* I've never worked with toric varieties over finite fields, but I'm
pretty sure that change of base field does not change the fan or
anything in the combinatorial description. After all, the M-lattice is
just a fancy way of enumerating monomials and there are still
infinitely many polynomials over finite fields.
Finally, I don't understand your claim that this would be a problem
for pickling. Can you elaborate on that? There are circular
references, but that is handled just fine by cpickle?
Best wishes,
Volker
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
