On May 21, 5:24 am, Volker Braun <vbraun.n...@gmail.com> wrote: > Hi Andrey, > > Just to clarify, I only wanted to subclass Cones, but not Fans. The > fan is a container class for cones and that doesn't change. In > particular, I never felt the need to add any functionality at that > level in my code. > > As for sharing of cached data, I think a clearer way would be to > define a copy method in addition to the creation in the factory. Then > we just have to extend RationalPolyhedralFan to > * create new cone if cone was specified by point indices, and > * copy if the cone is already a cone of a (different) fan (that is, > c.is_Cone()==True) > > For example: > > class Cone_of_fan_Factory(SageObject): > def new(self, fan_rays, fan_generating_cones, fan): > return Cone_of_fan(fan_rays, fan_generating_cones, fan) > def copy(self, cone): > new_cone = copy(cone) > cone.__class__ = Cone_of_fan > > I think your timeline looks good! > > 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 athttp://groups.google.com/group/sage-devel > URL:http://www.sagemath.org
Hi Volker, I imagine creating a toric morphism between fans in such a way: sage: fan1 = ... sage: fan2 = ... sage: data = ... sage: phi = ToricMorphism(phi, fan1, fan2) sage: other_data sage: psi = ToricMorphism(other_data, fan2, fan1) ... (even more morphisms involving these and other fans in different combinations) Where fan1 and fan2 are usual standalone fans (e.g. face fans of polytopes) and data and other_data are either a matrices or ToricLatticeMorphism objects (this class is basically a wrapper around a matrix, but I want to create it to allow extra checks and conversions for "compatibility of lattices" in the spirit of having lattices everywhere else). The constructor of ToricMorphism will then create two "copies" of each of fan1 and fan2 with cones designed for domain and codomain. The natural way to do it seems to be like I wrote before: sage: domain = EnhancedFan(fan1, Cone_of_domain) sage: codomain = EnhancedFan(fan2, Cone_of_codomain) This "creation of fans from fans" does not seem to be natural from the point of view of the Fan constructor, so it seems reasonable to have a separate function or class to do it, even if there is no need for extra methods. Plus, it will allow me to hide (from you ;-)) the actual implementation of this. Copying suggested by you will work and will share cached data, but, as I understand, only those that were created *before* copying. Storing a reference to the original fans and cones will allow sharing of all the future "general" cached information as well, phi and psi will store only data which are related to the actual morhphisms, which clearly must be separate. Again, from your perspective in morphisms module working with these "enhanced" fans and cones should be in any way different than direct use of RationalPolyhedralFan and deriving from Cone_of_fan - same methods will be available, giving the same results (except that sometimes these results should be available faster). In fact, I am considering doing it "the easy way" for now and worrying about optimization later, but inserting these classes now will allow this future optimization without disrupting the morphism module in any way. I especially worry about cone/fan computations that trigger calls to associated lattice polytopes and polyhedra (cone_lattice is a good example) - if these calls result in invoking PALP or cdd, each operation is at least about 0.1s long, no matter how simple is the computation. With 10 cones it will be noticeable, with 100 - annoying. There is a workaround for this in lattice polytopes allowing computing data for many polytopes in a single run of PALP, but it is not always possible to use it. Some other comments: I think that cone.is_Cone() is a bad testing syntax since "not-cones" are likely not to have such a method at all. Instead, it seems that many modules in Sage define functions like is_Cone(cone), which can then accept absolutely any argument and return True or False without raising exceptions. I think I have written such functions for everything but fans, which probably should be added too. Did you do any work on your module for toric lattices since the version posted here: http://www.stp.dias.ie/~vbraun/Sage/ ? If yes, could you please update it? It will be good for me to see what things do you need from them, in case there is something that I would not think about. I saw that you have some interface to get triangulations from TOPCOM. Can you perhaps make an experimental package for it? I tried to install it sometime ago but was not successful as there were some build errors and my Linux knowledge is not that great. My code does include an algorithm to produce some subdivision, but I imagine that TOPCOM is faster and has way more features. Making it a standard package is a bit involved and will require long-term commitment from you, but since it is a relatively simple thing, I think that an experimental one will work just fine and then there can be more subdividing options for fans. (I already tried to write it with several algorithms in mind.) I also really want to have that "database of named toric varieties" implemented in your files, although I'd rather have a separate function (or even module) for this functionality instead of building it into ToricVariety(...). So please do include it! Thank you, 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
