On Thu, Mar 24, 2011 at 07:33:47AM -0700, Andrey Novoseltsev wrote:
> Awesome!
:-)
> Out of curiosity - why does Poset.mro have to stay in the list of
> constructors?
Because Posets is a (new style) class. So unless one hacks `dir`
(which we could do) the method mro of classes will appear in the
On Mar 24, 3:47 am, "Nicolas M. Thiery"
wrote:
> Hi Poset fans,
>
> I just recalled that there already exists two categories
> PartialyOrderedSets and PartialyOrderedMonoids, with aliases
> OrderedSets and OrderedMonoids. At this point, those categories are
> stubs, and are not used anywer
On Wed, Mar 23, 2011 at 09:40:16AM -0700, Anne Schilling wrote:
> Ah, yes, it would be more user friendly to use the actual vertices of the
> poset rather
> than numbers from 0,1,...,n-1. Does it matter that in one case the class is a
> DiGraph and in the other a separate class?
Not that much, un
On 3/23/11 9:34 AM, Martin Rubey wrote:
"Nicolas M. Thiery" writes:
Dear poset fans,
In the process of refactoring / categorifying the poset code, I am
creating a category for posets which are lattices. What should be the
name for this category? Lattices() would be natural, but might
"Nicolas M. Thiery" writes:
> Dear poset fans,
>
> In the process of refactoring / categorifying the poset code, I am
> creating a category for posets which are lattices. What should be the
> name for this category? Lattices() would be natural, but might get
> into conflict with other kind
Dear poset fans,
In the process of refactoring / categorifying the poset code, I am
creating a category for posets which are lattices. What should be the
name for this category? Lattices() would be natural, but might get
into conflict with other kind of lattices. Should we use
LatticePoset
On Wed, Mar 23, 2011 at 01:02:59PM +0100, Martin Rubey wrote:
> "Nicolas M. Thiery" writes:
>
> >The rationale for using 0,...,n-1 is that this makes the code
> >simpler and quite faster, in particular when the elements of the
> >poset are large objects with expensive hash function. T
"Nicolas M. Thiery" writes:
>The rationale for using 0,...,n-1 is that this makes the code
>simpler and quite faster, in particular when the elements of the
>poset are large objects with expensive hash function. That's a
>standard approach in the Sage library (see e.g. Mike's patc
On Tue, Mar 22, 2011 at 01:21:44PM -0400, Christian Stump wrote:
> > Another question is whether we want the vertices P.hasse_diagram()
> > to be wrapped or not. And if we are unhappy with the situation, is
> > still time to change this?
>
> I think wrapping them is fine in the hasse diagram, I
"Nicolas M. Thiery" writes:
> Dear poset fans,
>
> I posted below the current log of the patch. Altogether, I am
> essentially done, except for looking at the antichains optimizations,
> and a couple issues to be discussed now:
>
> - Currently P.hasse_diagram() returns a graph G whose nodes
> I posted below the current log of the patch. Altogether, I am
> essentially done, except for looking at the antichains optimizations,
> and a couple issues to be discussed now:
it looks nice, thanks!
> - Currently P.hasse_diagram() returns a graph G whose nodes are the
> elements of P (wrapped
On Tue, Mar 22, 2011 at 07:09:09AM -0700, Anne Schilling wrote:
> Impressive, your work on posets!
:-)
Kudos also go to Christian and Frédéric!
Oh, and I should mention that if the facade option was so far
straightforward to implement, that's because Franco's original code
was well written and e
Dear Nicolas,
Impressive, your work on posets!
...
- Currently P.hasse_diagram() returns a graph G whose nodes are the
elements of P (wrapped as elements of P; so one needs to do
x.element to actually get the original element). This graph is still
in the HasseDiagram class. Th
Dear poset fans,
I posted below the current log of the patch. Altogether, I am
essentially done, except for looking at the antichains optimizations,
and a couple issues to be discussed now:
- Currently P.hasse_diagram() returns a graph G whose nodes are the
elements of P (wrapped as ele
On Mon, Mar 21, 2011 at 07:53:03PM -0700, Andrey Novoseltsev wrote:
> How about "lt" for "<" and "le" for "<="? I think these are more
> standard.
That is to follow the convention for operator.* and the .__*__
methods. That sounds good to me. Everybody ok?
> And just to make sure I understand it
On Mar 21, 11:30 am, "Nicolas M. Thiery"
wrote:
> In particular, one would need good names for the basic poset
> operations:
>
> P.le(a,b) (returns a< b in P)
> P.lequal(a,b) (returns a<=b in P)
Hi Nicolas,
How about "lt" for "<" and "le" for "<="? I think these are more
standard.
16 matches
Mail list logo
