Changing the default behaviour of Poset

[Nathann Cohen]

Helloooooooooooooo everybody !!!

I spent many hours fighting with Posets under Sage. I enjoyed it a lot, but I can already tell that it gets on Florent's and Nicolas' nerves, and so I was thinking of whether I should put an end to it. For their sake.

Here's the problem. With comments.

-------------------------------
Building the poset from a DiGraph defined on integers :
sage: g = DiGraph([(1,2),(1,3),(2,4),(3,4)])
sage: p = Poset(g)

Is 3 in the poset ?

sage: 3 in p                                
True

Of course it is !

sage: list(p)                              
[1, 2, 3, 4]
sage: 3 in list(p)                          
False

Not it is not ! So what the hell is this list [1,2,3,4] that we get as a result to list(p) ?

sage: map(type,list(p))
[<class 'sage.combinat.posets.elements.FinitePoset_with_category.element_class'>, <class 'sage.combinat.posets.elements.FinitePoset_with_category.element_class'>, <class 'sage.combinat.posets.elements.FinitePoset_with_category.element_class'>, <class 'sage.combinat.posets.elements.FinitePoset_with_category.element_class'>]

O_O;;;

sage: p.cover_relations()
[[1, 2], [1, 3], [2, 4], [3, 4]]
sage: [1,3] in p.cover_relations()
False
sage: (1,3) in p.cover_relations()
False

And of course :

sage: p.hasse_diagraph() == g
False
------------------------

WELL. I personally consider that this behaviour is totally crazy, and I often say so (very loud, and very frequently. Just come eat with us anyday at lunch and I will probably complain about that, or about LaTeX). This being said, I also heard that it may possibly make sense in a very sick logic, and that the correction of some code may actually depend on that.

I personally think that having this as the default behaviour of Poset is *madness*. I personally *ONLY* use Posets with he flag "facade = True" when I do not forget it, and lose half an hour when I do forget it. What would you think of making it the default behaviour of Poset ? This way, normal people could use a Poset without having to know what a facade is. Without having to hear about parents, elements, the .value() method and all.
I mean. Why the hell should this stay the default behaviour ?

Thank you for listening. Very soon, I hope to convince you that the way Poset.relabel is written is an insult to computer science. I think I may already have convinced Florent Hivert of the sin this method is.

Nathann

[Dima Pasechnik]

On 2012-11-11, Nathann Cohen <nathan...@gmail.com> wrote:
> --14dae9340db323c21304ce3faaf8
> Content-Type: text/plain; charset=ISO-8859-1

I agree that this looks very odd. A poset is a pair (set, binary
relation), and one would fully expect that list() will produce
the list of the elements in the set ordered in a way preserving
the partial order...
Actually, I tried googling poset+facade, and all the maths hits are
Sage, with an exception of a dissertation on posets, where the only
place the word "facade" is used is the following quote:

It turns out that an eerie type of chaos
can lurk just behind a facade of order
and yet, deep inside the chaos
lurks an even eerier type of order.
D. Hofstadter

Thus indeed, we should not show "an eerie type of chaos",
unless a user expicitly asks for it...

Best,
Dima

[Nicolas M. Thiery]

On Mon, Nov 12, 2012 at 05:03:58AM +0000, Dima Pasechnik wrote:
> On 2012-11-11, Nathann Cohen <nathan...@gmail.com> wrote:
> > I spent many hours fighting with Posets under Sage. I enjoyed it a lot, but
> > I can already tell that it gets on Florent's and Nicolas' nerves, and so I
> > was thinking of whether I should put an end to it. For their sake.
> >
> > Here's the problem. With comments.
> >
> > -------------------------------
> > Building the poset from a DiGraph defined on integers :
> > sage: g = DiGraph([(1,2),(1,3),(2,4),(3,4)])
> > sage: p = Poset(g)
> >
> > Is 3 in the poset ?
> >
> > sage: 3 in p
> > True
> >
> > Of course it is !
> >
> > sage: list(p)
> > [1, 2, 3, 4]
> > sage: 3 in list(p)
> > False
> >
> > Not it is not ! So what the hell is this list [1,2,3,4] that we get as a
> > result to list(p) ?
> >
> > sage: map(type,list(p))
> > [<class
> > 'sage.combinat.posets.elements.FinitePoset_with_category.element_class'>,

> > ...

First thing: for those who want to know more on what a facade is:

sage: S = Sets()
sage: S.Facade?

Now, just to put this in perspective. I think many people would find
the following madness if the end result was 3 and not 0:

sage: G = IntegerModRing(3)
sage: G.list()
[0, 1, 2]
sage: a,b,c=G.list()
sage: b+c
0

In the above use case, you want the element of G, as returned by G, to
be aware that they live in G, so that arithmetic get done
accordingly. Similarly, for posets, there are use cases where one
wants a<b to compare a and b in the poset.

All of this to say that both facade and non facade posets are useful.
Now there is the question of the default value for this option. I
think we all agree (including the original poset authors; facades did
not exist back then), that facade=True is the natural default as this
is the most common use case.

The single remaining question is whether the issue is important enough
to break backward compatibility (with an appropriate transition period
of course).

> Actually, I tried googling poset+facade, and all the maths hits are
> Sage, with an exception of a dissertation on posets, where the only
> place the word "facade" is used is the following quote:
>
> It turns out that an eerie type of chaos
> can lurk just behind a facade of order
> and yet, deep inside the chaos
> lurks an even eerier type of order.
> D. Hofstadter
>
> Thus indeed, we should not show "an eerie type of chaos",
> unless a user expicitly asks for it...

:-)

Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[Marco Streng]

2012/11/12 Nicolas M. Thiery <Nicolas...@u-psud.fr>

First thing: for those who want to know more on what a facade is:

    sage: S = Sets()
    sage: S.Facade?

Object `S.Facade` not found.

It should be:

sage: S.Facades? 

[Nicolas M. Thiery]

Oops, right; I should have checked with a stock Sage :-)

[Travis Scrimshaw]

Hey everyone,

   I just had an idea, and maybe this is more wishful thinking, but I feel like we should be able to pass a poset/lambda function(s)/class which contains comparison methods into a parent and have that be able to override the default ordering (similar to what C++ does in the STL). Something like this:

    sage: g = DiGraph([(0,1),(0,2)]) 
    sage: p = Poset(g)

    sage: G = IntegerRingMod(3, ordering=p)

    sage: G(0) < G(1)

    True

    sage: G(0) < G(2)

    True

    sage: G(1) < G(2)

    False

Or for partitions under dominance order (instead of how we currently are doing them in 13605):

    sage: P = Partitions(3, cmp_lt=Partition_class.dominates) # after 13605 this would just be Partition.dominates

    sage: P([2,2,1]) < P([3,1,1])

    True

Thoughts?

Best,

Travis