Hi Volker, On May 21, 11:24 am, Volker Braun <vbraun.n...@gmail.com> wrote: > Ok, I agree that it would be nice for all derived cones to share the > base cached data. How about Cone() just stores all of its cached data > in a hash self.shared_cache (or so) instead of in self. For the > computer thats essentially the same as what you are suggesting, but in > the implementation you wouldn't need to fiddle with __getattr__ and > would keep an inheritance chain like > > Cone -> Cone_of_fan Cone_of_toric_variety -> Cone_of_codomain > > Even if the implementation details are not important to the user, I > think it would help with the future maintenance.
Good point, that would be cleaner and easier! > > On May 21, 5:13 pm, Andrey Novoseltsev <novos...@gmail.com> wrote: > > > I especially worry about cone/fan computations that trigger calls to > > associated lattice polytopes and polyhedra > > In the long run we should write a cython module that does the basic > cone/polyhedron operations instead of parsing palp or cdd output. That > said, I've looked at the palp source code and I'm certain only Max > understands what it does. I think writing something new based on the > Parma Polyhedral Library (C++) is the way to go. > I also tried to read PALP code a couple times but gave up. Avoiding system call will definitely make things better from any point of view, but that's probably quite a bit of work. I think it still would be good to keep PALP in Sage since it is quite fast and it is the only program for computing nef partitions I am aware of. Plus - it is already in and working. > > I saw that you have some interface to get triangulations from TOPCOM. > > The main problem right now is that TOPCOM segfaults when checking > regularity (=coherence). But I think that I can fix that quickly. The > interface I have written works for everything else, though. You > probably shouldn't spend much time implementing some subdivision > algorithm in python. I already have some subdivision implemented and it is used by default, so no extra work is needed at this point. I am absolutely sure that we should keep it unless we write something else independent of packages not included into Sage (in which case we still can keep it as an alternative). The reason is that no matter how inefficient it is - it will work in the standard Sage installation (and it is actually sufficiently fast to be useful). If you will make TOPCOM a standard package, that would be great, but as I understand it is not that easy to have new packages accepted as standard in Sage. 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
