Hell guys !!
Yesterday Simon finished dealing with #15278, which defines equality and
hash methods for immutable graphs. That's a good news for the combinat/
code, as it now uses an ugly hack to pretend that non-immutable graphs are
immutable, and that's a mess. A mess that we will be
If G is a Lie group and H is a maximal subgroup, the branching rule G=H is
the
rule describing how irreducible representations of G decompose into
irreducibles
of H. These are implemented in Sage as methods of the WeylCharacterRing,
but until recently there were a few gaps in the built-in rules.
Hi Nathann,
I would like to look at huge posets and define a random walk on its
linear extensions (or eventually run through its linear extensions
using a Markov chain derived from this one). The methods involved
currently are
sage: P = Poset(([1,2,3],[[1,2]]))
sage: L = P.linear_extensions()
Yo !
I would like to look at huge posets
Would you mind telling me what huge means ? It does make a difference
when one writes the code.
and define a random walk on its
linear extensions (or eventually run through its linear extensions
using a Markov chain derived from this one). The
Hi Nathann,
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
Hi Darij,
On 2013-12-30, Darij Grinberg darijgrinb...@gmail.com wrote:
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
Would you mind telling me what huge means ? It does make a difference when
one writes the code.
Probably with hundreds of vertices.
sage: view(G)
On huge digraphs ? I don't think so :-P
This was only for you to see what the graphs look like :-)
Anne
--
You received this message
