On Wed, May 19, 2010 at 4:24 AM, Volker Braun <vbraun.n...@gmail.com> wrote: > Hi Andrey, > > I've looked over your code and I think it would be good to extend the > class hierarchy of cones. I'm thinking about > > Cone > Cone_of_fan(Cone) > keeps reference of fan > Cone_of_ToricVariety(Cone_of_fan) > keeps reference of toric variety > Cone_of_DomainOfToricMorphism(Cone_of_ToricVariety) > knows the image cone (smallest cone containing image) > Cone_of_RangeOfToricMorphism(Cone_of_ToricVariety) > knows the preimage cones > > etc... > > In order to allow this and future extensions, the > RationalPolyhedralFan() must create new cones from a factory(**) that > is passed to RationalPolyhedralFan.__init__(). The default factory > would create Cone_of_fan objects. Do you agree? > > (**) One cannot use a virtual method of RationalPolyhedralFan, > ToricVariety(RationalPolyhedralFan) since the constructor always calls > base methods.
Hi Volker, I do not support the idea of cones bound to toric varieties and morphisms. Right now, for example, when you change the base field of a toric variety it uses exactly the same fan and this is good not only for speed and memory usage of this change itself, but also for cached computations - working with any of the varieties different only by fields will accumulate cone lattices, Gale transforms, etc. As far as I know it would be very nice for certain applications to perform computations over changing finite fields for the "same" toric variety. If would be better if one did not have to reconstruct all fans and cones each time, even if compatibility checks are suppressed. On the other hand, I didn't think about it before but I definitely agree with you that for morphisms we do need to store where do cones go and where do they come from. What do you think about creating the following: - ToricLattice class. - ToricLatticeMorphism, which is basically just a matrix and a pair of lattices for domain/codomain (I prefer codomain rather than range since this is what is used in Sage now, plus by "range" one can mean the actual image of the domain which can be smaller than the codomain). No relation to cones/fans yet. - While mathematically it is pretty much the same, for implementation purposes we should create something like FanMorphism (a single cone can always be turned into a fan). It should be either derived from ToricLatticeMorphism or just store one inside (second is probably better). In addition it has fans living in the domain and the codomain of the ToricLatticeMorphism. The constructor should check that these fans are compatible with the lattice morphism (unless check=False). This class should have methods like image_cone and preimage_cones. These functions will return cones you have mentioned, given a cone or its index in the appropriate fan (cones are hashable and can be used as keys if we implement it as a dictionary). This will allow the same fans to be shared by different morphisms. Note that with the approach above these morphisms have nothing to do with schemes and toric varieties and can be incorporated exclusively into sage.geometry. This will make framework of cones/fans quite complete, polished, and stable. Even inside the geometry modules it will be nicely structured: * ToricLattice is "independent" * ToricLatticeMorphism depends on ToricLattice * Cone depends (slightly) on ToricLattice * Fan depends on Cone * FanMorphism depends on Fan and ToricLatticeMorphism The variant allowing construction of Fans with cones designed for morphisms creates circular dependencies in this diagram (or even ties it further to toric varieties!) and it will be easier to introduce bugs. Another technical argument against passing cone constructors is that it may interfere with pickling and therefore fail TestSuite(...).run(). (There is already a method in Cones that discards associated polyhedron during pickling because something funny is going on there - it took me a few hours to figure out that this is the problem, although I still don't know what happens in polyhedra). Of course, in addition to all this talking I am also willing to actually work and do this ;-) FanMorphism should eventually induce morphisms between ToricVarieties in the sense of general scheme morphisms in Sage (and I definitely want to allow non-toric morphisms between toric varieties!). Unfortunately, this part will likely require a lot of work on the existing Sage morphisms. I am willing to do it as well but I very much doubt that I can finish it by the end of August (surprisingly I got a quite dense summer ahead ;-)). Fortunately, as I understand your current code does not need it at all, as it relies on the combinatorial description! So it should not be an obstacle for your divisors/cohomology code for now and once "scheme morphisms of toric varieties" are good enough, we can see if anything has to be "ported." Having written the above arguments against deriving new classes and recreating of objects I see that they may be applied also to my classes ConeFace and Cone_of_fan. We may consider eliminating them, but the main reason for their creation was to remember incidence information in the face or cone lattice. They are also more likely to be used interactively by users, so the ability to write cone.fan_rays() instead of fan.ray_indices(cone) seems to be nice. As I said, we may consider eliminating these classes if you agree with my proposals above and think that they should be applied here as well. Let me know what you think! Andrey -- 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
