Hmmm... Looks like there is already something like that in .hasse_diagram, in the _leq_matrix() method :
def _leq_matrix(self): ... # Redefine self.is_lequal self.is_lequal = self._alternate_is_lequal ... Though this Matrix is defined to be a sparse matrix defined on ZZ. Don't know how much faster comparisons can be with a real binary matrix. Right now, it looks like it is created when the users asks for the matrix, and when he tests whether to elements are comparable/incomparable. So it's not sure somebody who would like to compute many comparisons would end up creating this matrix. Hmmmmmmm... Wonder what should be done there... O_o Nathann On 31 December 2013 11:29, Nathann Cohen <nathann.co...@gmail.com> wrote: > Yoooooooooooo !! > > > I certainly can recall dealing with lots and lots of small posets > > (typical for algebraic combinatorics: your combinatorial objects are > > small, but you are often considering all of them at once because you > > are talking formal linear combinations of them and likewise). I also > > have dealt with medium-size posets (30 to 40 vertices), but in those > > cases I don't think the comparisons were much of a bottleneck. I don't > > recall ever dealing with huge posets (as in thousands of vertices), > > but I can imagine myself doing that every once in a while. > > > > On another note: I remember the __init__ of Poset (well, FinitePoset) > > being way slower than it reasonably should be. I think this is related > > to it ducktyping the input (which IMHO is a bad thing anyway but seems > > standard in Sage). It would be nice to have quicker ways to initialize > > a poset from an already sanitized/predigested input datastructure. > > > > This all said, I'd very much like to see things not getting slower in > > the less-used regime while the more popular regime gets optimized. > > I see. Thank you very much for this informative answer ! > > This duck typing I think is standard in Sage-combinat, but not in the > other parts of Sage that I know (which may be very few, admittedly). I also > think that this is where most of your ressources go when you use Posets, > and that there should be a way to disable it. For some operations in graphs > most of the time is spent dealing with labels, especially when they are > complicated and hard-to-hash things. > > Let me withdraw what I said above about code getting slower at first : it > turns out that the code I thought would have to be re-written for the new > immutable backend already works fine with this backend, so using this new > backend should only make things faster. Rewriting this code for this > specific backend should be even better. > > Right now, what I wonder is the following : #14589, when it will be > reviewed (please, help me !), can be used to store efficiently in memory a > dense digraph, and in this context the transitive closure of your Poset. > Which means that comparing two elements will just amount to check that a > bit is set to 1, which is *FAST*. Most of the time should be spent > translating the vertex's label to an integer, but well, it should be fast. > > The question is : when should this transitive closure be computed ? Should > it be computed when when the first comparison is requested ? I guess that > this would make this ._transitive_closure a lazy attribute of Posets. > Or should it be computed when the user explicitly asks for it ? It would > mean that a keyword could be added to the Poset constructor, somehow asking > the user which data structure should be used to store it : only hasse > diagram, or the transitive closure too ? > > I wonder. It may be better to compute it immediately when a comparison is > tried, but that would mean a huge slowdown if you build a lot of posets, > compare two elements and throw them away. It should be much faster if you > compare a lot of things on the same poset. > > What do you think ? > > Have fuuuuuuuuuuuuuuuuuunnn !! > > Nathann > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
