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
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group
Travis and I fixed the bug on the ticket. See the comments there.
Thank you for working on that.
Nathann
--
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
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
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
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 =
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
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
--
You received this message because you are subscribed to the Google Groups
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
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
On 2014-10-02, Nathann Cohen nathann.co...@gmail.com wrote:
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,
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
On Wed, Oct 01, 2014 at 12:10:51PM +0200, Nathann Cohen wrote:
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.
Yes. *used*.
As for your other comments about grants, food,
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
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
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
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.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and
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
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
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
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
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
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
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
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 =
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
--
You received this message because you are subscribed to the Google Groups
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.
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
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.
--
You received this message
Then there is an easy normal form, sort the vertex labels and permute the
Hasse diagram accordingly.
= is always a total order ?
Nathann
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails
On Monday, September 29, 2014 1:50:32 PM UTC+1, Nathann Cohen wrote:
Then there is an easy normal form, sort the vertex labels and permute
the
Hasse diagram accordingly.
= is always a total order ?
If they are all distinct then = is the same as
If is not a total order then you need
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
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
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
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,
34 matches
Mail list logo
