Tell me how the design of the Poset class is not flawed

[Nathann Cohen]

Hello everybody,

Here is the current design of the Poset class:

def Poset(an_acyclic_labelled_digraph):
    ...
FinitePoset(UniqueRepresentation):
    def __init__(self, an_integer_labelled_hasse_diagram, list_of_vertex_labels):
        ...

As FinitePoset are UniqueRepresentation, two posets p1,p2 are equal if and only if they were created in the very same way, i.e. if the pairs (an_integer_labelled_hasse_diagram, list_of_vertex_labels) are equal in both cases.

The problem, now, is the following: given a labelled digraph D, how can you associate to D in a unique way a pair (an_integer_labelled_hasse_diagram, list_of_vertex_labels) ?

The answer, as far as I can tell, is that this is impossible because there is not necessarily a total order on the set of vertex labels.

Apply any of the digraph automorphism to the list of labels and you get the very same graph, but the posets will be non-equal for UniqueRepresentation.

This is one of the reasons behind the bug reported 2 years ago in #14019:

sage: d = DiGraph({2:[1],3:[1]})  
sage: p1 = Poset(d)
sage: p2 = p1.relabel({1:1,2:3,3:2})
sage: p1.hasse_diagram() == p2.hasse_diagram()
True
sage: p1 == p2
False

We cannot have a UniqueRepresentation poset class which takes a list of vertices as arguments. It must only take a HasseDigraph. If you see another way, please enlighten me.

Nathann

[Volker Braun]

The obvious answer: if the vertex labels are not all distinct then you need to replace the (single) Hasse diagram with the equivalence class of Hasse diagrams under the vertex permutations fixing the labels. Either find some normal form of Hasse diagram under the permutation action, or use frozenset(orbit) as the UniqueRepresentation data.

And yes, this is going to be dog-slow.

The answer if you care about fast computation: Define == as strict identity of pair(Hasse diagram, labels), not isomorphism up to permutation. Provide a separate is_isomorphic() method for the latter.

[Nathann Cohen]

> The obvious answer: if the vertex labels are not all distinct

They are all distinct.

> The answer if you care about fast computation: Define == as strict identity of pair(Hasse diagram, labels), not isomorphism up to permutation. Provide a separate is_isomorphic() method for the latter.

I am not talking of isomorphism test. Two posets defined on the same
sets of points, and such that x<y in one iif x<y in the other must be
declared equal by Sage.

Nathann

[Viviane Pons]

I don't know much about the design of Posets, I guess Travis knows much more than I do. But from what I see, the problem comes specifically from the relabel method, can you reproduce an equality error without using relabel?

This, for instance, is working as it should:

sage: p1 = Poset(([1,2,3],[(2,1),(3,1)]))
sage: p2 = Poset(([1,3,2],[(2,1),(3,1)]))
sage: p1==p2

True

[Nathann Cohen]

> But from what I see, the problem comes specifically from the
> relabel method,

My design problem is asbtract well-defined.

> can you reproduce an equality error without using relabel?

No, is that a problem ?

Nathann

[Viviane Pons]

Well, then can you find other places where this design is an issue? (What I mean by that, is giving wrong answer)

Otherwise, maybe it can be fixed on the relabel function level (once again, I don't know how it works). And yes, I agree Sage should should say True on the example you give.

[Nathann Cohen]

> Well, then can you find other places where this design is an issue? (What I
> mean by that, is giving wrong answer)

I don't know how to produce it differently, for in many places the
elements are "sorted" in this way:
list({a_dictionary_whose_keys_are_the_vertices})

> Otherwise, maybe it can be fixed on the relabel function level (once again,
> I don't know how it works).

I don't see how. I tried many times, and each time I was sent back to
this design problem: the default value of the list of vertices is not
properly defined, and good a good reason (i.e. the question I asked).

Nathann

[Volker Braun]

On Monday, September 29, 2014 1:16:36 PM UTC+1, Nathann Cohen wrote:

> The obvious answer: if the vertex labels are not all distinct
They are all distinct.

Then there is an easy normal form, sort the vertex labels and permute the Hasse diagram accordingly.

 

[Nathann Cohen]

> Then there is an easy normal form, sort the vertex labels and permute the
> Hasse diagram accordingly.

<= is always a total order ?

Nathann

[Volker Braun]

If they are all distinct then <= is the same as <

If < is not a total order then you need to define the permutation with respect to a chosen set of vertex labels (another UniqueRepresentation for vertex label set). Though frankly I'd be happy to require that vertex labels are sortable if distinct.

If == is not transitive then you have to define what you mean by "same" set of points. 

[Nathann Cohen]

Yo !

> If < is not a total order then you need to define the permutation with
> respect to a chosen set of vertex labels (another UniqueRepresentation for
> vertex label set). Though frankly I'd be happy to require that vertex labels
> are sortable if distinct.

We have a lot of code in Graph that are only there because you cannot
assume that vertices can be compared.

sage: {1}<{2}
False
sage: {2}<{1}
False
sage: Set([1])<Set([2])
True
sage: Set([2])<Set([1])
True

And I swear that I already had to create digraphs whose vertices are sets.

> If == is not transitive then you have to define what you mean by "same" set
> of points.

No problem there, == is well defined.

Nathann

[Volker Braun]

On Monday, September 29, 2014 2:19:25 PM UTC+1, Nathann Cohen wrote:

No problem there, == is well defined. 

 

Obligatory: You mean equality of the set of vertex labels or equality of the vertex labels up to permutation?

sage: GF(5)(1) == 11

True

sage: Set([GF(5)(1)]) == Set([11])

False

 

[Nathann Cohen]

> Obligatory: You mean equality of the set of vertex labels or equality of the
> vertex labels up to permutation?

I mean that I suppose that for any vertex x among my n vertices there
is only ONE vertex y such that x==y is True.

Now if we could talk about the question I asked it would be very cool,
because the problem remains and the bug has been reported 2 years ago.

Nathann

[Erik Massop]

Dear list,


Let's for sanity's sake suppose that == among all vertex labels of
FinitePosets is an equivalence relation. Let's moreover suppose that
hashing respects this equivalence relation.

Then the problem seems to be that in the unique representation
(an_integer_labelled_hasse_diagram, list_of_vertex_labels)
of FinitePoset the internal mapping from vertex labels to integers is
exposed.

It seems to me that this can be fixed by
A) getting rid of the exposure of the internal mapping,
or
B) by making the internal mapping unique given the Hasse diagram
labelled using the actual vertex labels.

Option A probably involves using a vertex label labelled Hasse diagram
in the unique representation. The issue then becomes implementing that.

This could perhaps be an object storing a set, an integer labelled Hasse
diagram, and a map from the set to the integers. Then equality of such
objects is equality of the sets together with equality of the integer
labelled Hasse diagrams after the appropriate permutation. Coming up
with a good hash function for such objects might be hard.

Option B can be done by
i) requiring that the occurring vertex labels have a total ordering
or
ii) making up a total ordering of the occurring vertex labels and
storing it globally.


There're probably more options, but I hope this helps.


Regards,

Erik Massop

[Nathann Cohen]

Hello,

> Let's for sanity's sake suppose that == among all vertex labels of
> FinitePosets is an equivalence relation. Let's moreover suppose that
> hashing respects this equivalence relation.

Thanks,

> Then the problem seems to be that in the unique representation
> (an_integer_labelled_hasse_diagram, list_of_vertex_labels)
> of FinitePoset the internal mapping from vertex labels to integers is
> exposed.
>
> It seems to me that this can be fixed by
> A) getting rid of the exposure of the internal mapping,
> or
> B) by making the internal mapping unique given the Hasse diagram
> labelled using the actual vertex labels.
>
> Option A probably involves using a vertex label labelled Hasse diagram
> in the unique representation. The issue then becomes implementing that.

I will rewrite it by making Poset.__init__ only depend on a hasse diagram represented by a labelled digraph (which will then be translated internally into an integer-labelled HasseDiagram). This way the key is the labelled hasse diagram, which is the only thing that makes sense.

Nicolas told me that this "_elements" thing was only used by Anne Schilling in her markov-related code. So I will create some AnneSchillingPoset class with list of elements, keys and everything she needs and get us a real Poset class. And I hope everything will hold together afterwards.

Thank you for your message, though. Asking a design question only earned me answers about "what is equality", and "can you provide a bug report which is not the bug report you provided".

Now, all I have to do is write somebody else's code.

Nathann

[Nathann Cohen]

> Now, all I have to do is write somebody else's code.

I will not.

I spent many hours on this yesterday, went back home just to sleep,
and continued today.

it is too much work, and it is not my job. I cannot do that. I do not
know the code.

I am stuck here just cause somebody put some badly designed code in
Sage, and now all I can do is rewrite it all from scratch just to
solve a bug, while rebasing all her work above. Hours and hours of
work which is totally pointless to me. It would not be fair. It would
not be fair if by writing bad code she gets me to rewrite it all, only
because it is now "sage code".

It is too much work.

I can't do that.

Nathann

[kcrisman]

> Otherwise, maybe it can be fixed on the relabel function level (once again,
> I don't know how it works).

I don't see how. I tried many times, and each time I was sent back to
this design problem: the default value of the list of vertices is not
properly defined, and good a good reason (i.e. the question I asked).

Perhaps a dumb question, because I am not surprised that totally rewriting is challenging...

Could you in the interim use internally (for your purposes now) a new is_isomorphic (or perhaps is_really_actually_equal) method as Volker suggests, that could be easily replaced by (or replace) == once that works correctly?  Or would that run into the infinite loop problem you mention at the ticket (though it seems like that issue has since been resolved/hacked around).  I apologize if you have already answered this, but I didn't see exactly this question answered - perhaps because you are right that it's not just isomorphism.

I agree this is not optimal.  But I also can see that probably it is just too much work for any one person to completely restructure this, nor can this kind of thing happening be easily resolved without imposing a far more stringent structure on Sage development itself, which is already at times quite onerous (yes, I know I am sometimes one of the ones imposing that!).

Anyway, unless you are exposing the (wrong) behavior directly in what you are working on, maybe this is better than nothing happening, both for you and the originator(s) of FinitePosets.  If this is not a useful suggestion, again my apologies :(

- kcrisman

[Anne Schilling]

Hi Nathann,

Whoo hoo. First of all, you put my wrong e-mail address and I am not reading sage-devel all the time. Second of all, I did not write the poset code.
As far as I know, it was written by Peter Jipsen and Franco Saliola. I used the poset code in the new class LinearExtensions in
combinat/posets/linear_extensions.py

Anne

[Nathann Cohen]

Hello Anne,

> Second of all, I did not write the poset code.
> As far as I know, it was written by Peter Jipsen and Franco Saliola. I used the poset code in the new class LinearExtensions in
> combinat/posets/linear_extensions.py

I see.

Well, Anne, regardless of that it we need your help.

I hope that I gave in my first message a good explanation of why the current design cannot work. The __init__ (and so the __eq__) depends on both an unlabeled HasseDiagram and a list of labels, and there is not a unique way to obtain these two elements from a labelled Hasse Diagram.

Thus, as Erik noticed, we need to split this Poset class into two:
- On one side a Poset class that only takes a labelled Hasse Diagram as input
- On the other side a PosetWithLinearExtension that takes a Poset and a linear extension of it as input.

I do not think that we can have the two in one class as it is now, as some things cannot work for both at once, like equality.

I tried many times to solve the problem myself: I created #14019 two years ago (and we discussed it together), and I tried to solve it now again. But the truth is that I do not know where and how this information is used, so I kept on coding something, only to notice later that my design would not work, and had to start from scratch again.

I have been told that you were the one who needed the feature for something you do related to Markov chain, so surely you know how it works better than anybody here.

We also need your help for during last week Jori Mäntysalo has been writing a lot of Poset code to fix bugs and add new features:

http://trac.sagemath.org/ticket/16984
http://trac.sagemath.org/ticket/17050
http://trac.sagemath.org/ticket/17022
http://trac.sagemath.org/ticket/17004
http://trac.sagemath.org/ticket/16985
http://trac.sagemath.org/ticket/16873
http://trac.sagemath.org/ticket/17051
http://trac.sagemath.org/ticket/17037
http://trac.sagemath.org/ticket/17036
http://trac.sagemath.org/ticket/16892

And there are other tickets of his that I need to review today.

Anne, we need a Poset class that we understand and can work with, and right now the Posets carry this linear extension that does not belong there. It is a lot of work to do that when you do not know the code. You use it and know it, so please help us and dissociate those classes. Otherwise we are just stuck with a code we do not understand, cannot change and cannot remove.

Thanks,

Nathann

[Nicolas M. Thiery]

Hey,

Let me clarify the situation. There are two useful features: plain
posets and posets endowed with a distinguished linear extension. At
this point, and since its implementation in 2008, Poset implements the
latter. This could use some clarification in the documentation.

For a long while this went unnoticed. 20 months ago it was realized
and discussed that we needed both features, and that it would natural
if, by default, Poset would implement the former, like its name
suggests. At this point I believe the only spot in the Sage library
that uses the second feature is the linear extension code by Anne, and
it's specifying the linear extension explicitly, so handling backward
compatibility should not be too bad.

Someone volunteered to fix the code, and did not get to do it. You
volunteered and tried hard -- which I really appreciate -- and did not
get to do it either.

Nathann: I understand your frustration that nothing happened in 20
months. I am really frustrated too; we are not doing well here.

You may conclude that things don't happen by being kind and welcoming,
if you wish. I let you analyze whether being aggressive works any
better. But one needs to take into account all the time and energy
spent in non productive discussions and hurt feelings. For example,
Anne is now rightfully upset at being publicly blamed for the
situation, when she just used and followed the current specifications.

I let you judge by yourself whether, instead, the original author,
Franco, should be blamed for not clarifying the situation on the onset
and not implementing both features from the onset.

I am personally grateful that he wrote the poset code, even with its
current limitations and despite all the time I already spent
fixing/working around some of them. Still this has been less time than
if I had had to write it myself from scratch.

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

[Nathann Cohen]

And so you are going to leave me alone everytime I try to get code
written and bug fixed, every time I scream for help.

And you are going to answer this thread only to defend your friend.

And nothing will happen, because you will talk of feelings, and my aggressivity.

And nobody will do anything.

Nathann

> --
> You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/WXNmH3PL7kY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Nathann Cohen]

P.S. : You know why I said it was Anne's code. I went to your office, and you told me that "this linear extension code is only used by Anne's Markov-related code".

[Anne Schilling]

Hi Nathann,

As I said, I did not write the poset code, so I probably do not know it better than you do.

Yes, we do seem to need two classes Poset and PosetWithLinearExtension. We discussed this
at a design discussion about two years ago, but then you did not show up to the discussion
at the Sage Days. Things like this are much easier to discuss in person than via e-mail.

Perhaps you can come to Sage Days 64 and we could make this one of the goals.

Anne

[Travis Scrimshaw]

Hey everyone,

   From a quick look-over of the code, it seems like we can always run a topological sort on the elements list passed into FinitePoset without any significant pentality (and should solve the equality issue), or better yet, push that into the linear_extension() method. There doesn't appear to be any linear extension code that is based on the ordering of the elements being passed into FinitePoset. I haven't looked too deeply into it but I could likely do so over the weekend and maybe come up with a working branch. If it's not so simple, I'd be happy to work on this at Days64 too.

   Also Nathann, just for the record, I'm very tempted to not work on this based upon your comments because I don't want to make it seem like I'm rewarding your behavior. However, I will do so because I want Jori to continue to develop for posets and I want to improve the overall quality of Sage. I'm sorry if I'm being a complete ass here. I want you to be a part of the Sage community because you are a good programmer, but the continuous attacks you are doing really irritates me.

Best,
Travis

[Nathann Cohen]

Hello !

>    From a quick look-over of the code, it seems like we can always run a
> topological sort on the elements list passed into FinitePoset without any
> significant pentality (and should solve the equality issue), or better yet,
> push that into the linear_extension() method.

I do not think that it is sufficient: this is what my first message was about. There is no unique linear extension in a Poset, and I see no way to compute a canonical one when the elements can be 'anything' (and do not have a natural total order).

> There doesn't appear to be any

> linear extension code that is based on the ordering of the elements being
> passed into FinitePoset. I haven't looked too deeply into it but I could
> likely do so over the weekend and maybe come up with a working branch.

Beware, for in FinitePoset the ._list is not 'only' a list but has to be a linear extension. This is one of the things you find out when working on that class.

>    Also Nathann, just for the record, I'm very tempted to not work on this

> based upon your comments because I don't want to make it seem like I'm
> rewarding your behavior.

I do not need Poset equality to be true. I do not need this class to be well-written. I don't use it. I don't trust its code anyway.

I am doing this because this thing is an open-source software, and that when we write code that returns wrong answers we create trouble for other persons. They pay our carelessness.

My problem, and the reason why I am angry, is that absolutely nobody cares about that. That Florent promised that he would do it 20 months ago and that he did absolutely nothing since. That those who use Posets do not care sufficiently to spend the time to fix that.

Furthermore, I hate with all my heart that the same persons who come tell me that "they do not have sufficient time" suddenly find all the time they need to write Grant proposals to the US or Europe, and get solid real tens of thousands of euros of public money or more "because of what they will do in Sage". To pay for their planes, for their hotels, for their food.

You are telling me that you do not want to reward a bad behaviour ? Look at me: all the work I do in Sage, all the bugs I fixed and the features I added, all this is what they sell when they ask US and Europe to give them money. And I cannnot trust them even to fix the bugs they create when they code. When a problem happens, everybody ignores it and waits for somebody else to fix it.

Even during two years. Even when the problem is so basic that beginners will encounter it. And I obviously don't want you to believe that it is the only time this happened.

> However, I will do so because I want Jori to
> continue to develop for posets and I want to improve the overall quality of
> Sage.

Yeah, me too. That's why I am here. That's why I tried to fix this many times, but really I do not know how. There is too much code accumulated there that I do not know.

> I'm sorry if I'm being a complete ass here. I want you to be a part of
> the Sage community because you are a good programmer, but the continuous
> attacks you are doing really irritates me.

Sorry for irritating you. I would only want to be able to rely on my colleagues.

Nathann

[Dima Pasechnik]

I don't think you are fair here. This is basically a punch below the belt from
someone who has great job security to do whatever one wants with their time
aimed, perhaps inderectly, at Sage developers who depend on grant money
for the very possibility to work on Sage, or in science in general.

> You are telling me that you do not want to reward a bad behaviour ? Look at
> me: all the work I do in Sage, all the bugs I fixed and the features I
> added, all this is what they sell when they ask US and Europe to give them
> money. And I cannnot trust them even to fix the bugs they create when they
> code. When a problem happens, everybody ignores it and waits for somebody
> else to fix it.

this is one of the realities of the research software - one has to do new things
in academia (e.g. one cannot tell an MSc student that his project will be to fix
Sage bugs - he has to do something new!).
One of the aims of these grants would be to fund developers specifically to
fix bugs.

In short - you are in a small minority of people here who can afford to spend
time on fixing Sage bugs instead of writing papers and grant applications.

[Jakob Kroeker]

Dima wrote 

this is one of the realities of the research software - one has to do new things
in academia (e.g. one cannot tell an MSc student that his project will be to fix
Sage bugs - he has to do something new!).

 

But how to deal with this problem?
I predict that if the Sage community fails to solve it, Sage will end up at the same point where Singular or other CAS project in trouble is now.
With the SageMathCloud stuff William tries to get money for development, and I really hope that the project will succeed.

In short - you are in a small minority of people here who can afford to spend
time on fixing Sage bugs instead of writing papers and grant applications.

 

Each individual may of course gain some short-term benefit ignoring bugs or design issues.
But the community _cannot_ afford to ignore quality problems(technical debt) and in the long term we all will pay the bills!
Or, to formulate it in a positive manner, in the long term adequate quality will likely lead to higher productivity.



Jakob

[Nicolas M. Thiery]

Yes. *used*.

As for your other comments about grants, food, ...,

I hate to be pretentious, but I believe that I have done enough work
for Sage, writing code, cleaning existing code, including a *lot* of
code which is not mine, fixing bugs, training people, writing
documentation, tutorials, that I'd better ignore them.

[Jakob Kroeker]

I looked at the ticket #12536 and came to the following conclusion:

It is likely
(I do not understand much about the changes and the #14019 issue)
that indeed  'relabel()'  is based on existing code, which is probably buggy,
 so the bug #14019 is only a subsequent error. At the same time I conclude that 'relabel()' was
 not sufficiently tested! Responsible for the latter in my opinion are Anne and the reviewer.
Of course this does not help much to solve the issue...

In general a couple of simple examples is not a sufficient test. But also consider
that  most mathematicians are not  professional software developers
(e.g. at least with basic knowledge in software engineering and adequate practical experience)
and just didn't know better. I think that is a big problem.

There should be also resources for maintenance in addition of grants for the 'new fancy stuff'.
Probably all of you would agree that at a certain point building on top of broken software
 is just stupid and leads to nowhere. But this happens in real life (probably less in Sage in comparison to other CAS, but who knows)
and therefore for me it seems that this insight is not yet in the heads of all research sponsors and researchers.


Jakob

[Francesco Biscani]

On 5 October 2014 02:59, Jakob Kroeker <kro...@uni-math.gwdg.de> wrote:

There should be also resources for maintenance in addition of grants for the 'new fancy stuff'.
Probably all of you would agree that at a certain point building on top of broken software
 is just stupid and leads to nowhere. But this happens in real life (probably less in Sage in comparison to other CAS, but who knows)
and therefore for me it seems that this insight is not yet in the heads of all research sponsors and researchers.

Building on top of broken stuff happens all the time in real life. Commercial software companies will never choose to spend one or more release cycles doing maintenance and fixing fundamental design problems (which often are identifiable only after the software has been used and developed for some time - it's effectively impossible to get something "right" the first time). They mostly ignore the "technical debt" (eh) and go for features. Given enough time, the software becomes an unmaintainable mess and eventually someone decides that it's time to do a full rewrite.

Supposedly, one of the advantages of open source software is that, due to the lack of commercial pressure, developers can afford to spend time doing the right thing, and tackle the hard, boring and soul-crushing job of fixing past mistakes and porting over existing functionality. I think that free software is the only type of software that has the *potential* of achieving a certain type of long-term quality. I think the Linux kernel is one of the best examples of this (I remember reading a few years ago that the USB stack had seen something like six or seven full rewrites).

In reality though most of the time this does not happen. There are typically few developers familiar with the inner intricacies of a non-trivial project, and in general people just prefer to code the sexy and the new. And as you say, it does not help that this is the type of job for which it is surprisingly so hard to get financial support - even in programs like GSoC. No flashy goals, no awe-inspiring proposals, just boring, fundamental wood chopping.

 

Jakob

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

[Anne Schilling]

The bug you are all talking about might have already been taken care of with http://trac.sagemath.org/ticket/17059. See my comment on the ticket. At least I cannot reproduce it with the latest version of Sage.

Anne

[Anne Schilling]

> It is likely
> (I do not understand much about the changes and the #14019 issue)
> that indeed 'relabel()' is based on existing code, which is probably buggy,
> so the bug #14019 is only a subsequent error. At the same time I conclude that 'relabel()' was
> not sufficiently tested! Responsible for the latter in my opinion are Anne and the reviewer.
> Of course this does not help much to solve the issue...

The real issue is the FinitePoset code:

sage: d = DiGraph({0:[2],1:[2]})
sage: from sage.combinat.posets.posets import FinitePoset
sage: P = FinitePoset(d,elements=[1,2,3])
sage: Q = FinitePoset(d,elements=[2,1,3])
sage: P == Q
False
sage: P.hasse_diagram() == Q.hasse_diagram()
True

It has nothing to do with the relabel function.

Regards,

Anne

[Nathann Cohen]

> The bug you are all talking about might have already been taken care of with
> http://trac.sagemath.org/ticket/17059. See my comment on the ticket. At
> least I cannot reproduce it with the latest version of Sage.

No Anne, I am not complaining about a bug that I fixed myself last week.

I found #17059 while working on it, and #17059 is only about a bad
'category' argument.

In particular, I can still reproduce it on my computer.

This being said, the code has absolutely no reason to be
machine-dependent in its current state. Can you check this again and
give us the output of p1._list and p2._list ? The relabel function,
which you wrote yourself in #12536, makes sure that the `._list` flag
is modified, which breaks equality. This is not machine-dependent, so
I do not understand why it may work on your computer.

Nathann

[Nathann Cohen]

Hello,

> The real issue is the FinitePoset code:

Yes. It is possible that I mentionned it several times in this thread.

> sage: d = DiGraph({0:[2],1:[2]})
> sage: from sage.combinat.posets.posets import FinitePoset
> sage: P = FinitePoset(d,elements=[1,2,3])
> sage: Q = FinitePoset(d,elements=[2,1,3])
> sage: P == Q
> False
> sage: P.hasse_diagram() == Q.hasse_diagram()
> True

The authors of the code meant it to work like that, so this is not a bug.

You created the posets with different informations, and this
information is meant to make the posets non-equal.

That this is bad programming is correct, for a Poset is a very clearly
defined mathematical object and somebody merged inside informations
like an ordered list of elements or a linear extension, and that
breaks the features that one expects to find in the Poset objects when
they are used normally, without this additional information.

What I have been saying here repeatedly is that those features need to
be split apart, with one one hand the Poset class by itself and on the
other all these "linear extension related mess" (that includes the
ridiculous 'key' parameter).

> It has nothing to do with the relabel function.

There is something wrong with the relabelling function, which is the
only way I know to reproduce the bug at the moment. In your example
you specified a different input, and this is what the authors of that
code thought was sufficient to brea equality (you think that it is
wrong, I think that it is wrong, we agree here).

But that was not a bug. The bug is when a guy wants to work on a
simple poset, defined from its graph, and finds out that equality is
not behaving as it should.

Nathann

[Nathann Cohen]

Just an update because I was not clear in my other message:

> The real issue is the FinitePoset code:

The actual bug I reported was created by #12536
(http://trac.sagemath.org/ticket/12536).

Indeed, it is incorrect to relabel the (automatically computed) linear
extension of a Poset A (when A is relabelled into B) for the
relabelled linear extension is *NOT* necessarily equal to the
(automatically computed) linear extension of B.

The reason why I cannot fix the bug, however, is because of a bad
design that appeared before.

Nathann

[Anne Schilling]

> The reason why I cannot fix the bug, however, is because of a bad
> design that appeared before.

Travis and I fixed the bug on the ticket. See the comments there.

Anne

[Nathann Cohen]

> Travis and I fixed the bug on the ticket. See the comments there.

Thank you for working on that.

Nathann