> 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 sage-d
> 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 gr
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
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
> 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
> 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! Respons
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
"
On 5 October 2014 02:59, Jakob Kroeker 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
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 concl
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, f
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 2014-10-02, Nathann Cohen 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,
>> push that int
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 thi
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'
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 Sa
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
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
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 whi
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 hop
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
comb
> 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 goo
> 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 des
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_d
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_o
> 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 coo
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
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
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 th
> 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 email
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 messa
> 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
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.
2014-09-2
> 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 Group
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],[(
> 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.
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
froz
36 matches
Mail list logo
