octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #44643] classdef handle object can go into an


From: Lachlan Andrew
Subject: [Octave-bug-tracker] [bug #44643] classdef handle object can go into an recursive loop with isequal(obj1, obj2) if both are self-referential
Date: Wed, 29 Jun 2016 02:52:22 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0

Update of bug #44643 (project octave):

              Item Group:                   Crash => Matlab Compatibility   
                 Summary: classdef handle object can go into an recursive loop
with isequal(obj,obj) => classdef handle object can go into an recursive loop
with isequal(obj1,obj2) if both are self-referential

    _______________________________________________________

Follow-up Comment #3:

I don't think this is trivial.

The issue is that


a.parent = b;
b.child = a;


is assigning handles to the objects, rather than assigning values.  That gives
rise to a closed loop:  a.parent.child = a.  Naively walking that structure as
a tree gives the loop.

If we repeat that with


c = foo ();
d = foo ();
c.parent = d;
d.child = c;


then to compare isequal(a, c), we need __isequal__ to learn the actual
structure (since we can't simply rely on checking that the "rep" is the same,
which was my first thought).

It isn't even clear what __isequal__(a,c) should be.  Either "true" or "false"
is self-consistent.

Perhaps we can still walk the tree keeping track of the rep values we have
seen.  If one finds the n'th rep again and the other also finds the n'th rep
at the same point, we report success without the recursive call.  If one finds
the n'th rep again and the other doesn't, we return false.

That will consume a huge amount of memory when comparing large trees.  It
would be helped slightly if a persistent variable is used, so we don't need
the list of visited nodes in each stack frame.

I'm reassigning this from "crash" to "Matlab compatibility".  (There is still
no way to distinguish a very dangerous silent "incorrect result" from
something that simply reports an error.)

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44643>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]