On Thursday, August 31, 2017 at 12:41:26 AM UTC+9, Jeroen Demeyer wrote:
>
> On 2017-08-30 09:37, david@inria.fr wrote:
> > It's not a bug, it's how equality is defined
>
> Thinking of the coercion model, I would argue that this is a bug.
>
It is not a bug as it behaves as documented.
On 2017-08-30 09:37, david.coud...@inria.fr wrote:
It's not a bug, it's how equality is defined
Thinking of the coercion model, I would argue that this is a bug.
Of course we don't do coercions for graphs, but one could imagine a coercion
graphs without loops -> graphs with loops
and then
It's not a bug, it's how equality is defined (they have the same settings
for loops, multiedges and weightedness). It's different from being
isomorphic.
def __eq__(self, other):
"""
Compare self and other for equality.
Do not call this method directly. That is, for
I would say this is a bug
David
On Mon, Aug 28, 2017 at 9:25 PM, Vincent Delecroix <
20100.delecr...@gmail.com> wrote:
> Hi,
>
> I found the following curious
>
> sage: G = Graph([(0,3),(1,3),(2,3)])
> sage: H = G.copy()
> sage: G == H
> True
> sage: H.allow_loops(True)
> sage: G == H
>
Hi,
I found the following curious
sage: G = Graph([(0,3),(1,3),(2,3)])
sage: H = G.copy()
sage: G == H
True
sage: H.allow_loops(True)
sage: G == H
False
Is there any reason why allowing loops in H should change the status of
equality!?
Vincent
--
You received this message because you are
