Mailing List Archive

trashcan and PR#7
While I'm at it, maybe the same recursion control logic could be
used to remedy (most probably in PyObject_Compare) PR#7:
"comparisons of recursive objects" reported by David Asher?

--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
Re: trashcan and PR#7 [ In reply to ]
Vladimir Marangozov wrote:
>
> While I'm at it, maybe the same recursion control logic could be
> used to remedy (most probably in PyObject_Compare) PR#7:
> "comparisons of recursive objects" reported by David Asher?

Hey, what a good idea.

You know what's happening? We are moving towards tail recursion.
If we do this everywhere, Python converges towards Stackless Python.

and-most-probably-a-better-one-than-mince - ly y'rs - chris

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com
Re: trashcan and PR#7 [ In reply to ]
>>>>> "CT" == Christian Tismer <tismer@tismer.com> writes:

CT> Vladimir Marangozov wrote:
>> While I'm at it, maybe the same recursion control logic could be
>> used to remedy (most probably in PyObject_Compare) PR#7:
>> "comparisons of recursive objects" reported by David Asher?

CT> Hey, what a good idea.

CT> You know what's happening? We are moving towards tail recursion.
CT> If we do this everywhere, Python converges towards Stackless
CT> Python.

It doesn't seem like tail-recursion is the issue, rather we need to
define some rules about when to end the recursion. If I understand
what is being suggest, it is to create a worklist of subobjects to
compare instead of making recursive calls to compare. This change
would turn the core dump into an infinite loop; I guess that's an
improvement, but not much of one.

I have tried to come up with a solution in the same style as the repr
solution. repr maintains a list of objects currently being repred.
If it encounters a recursive request to repr the same object, it just
prints "...". (There are better solutions, but this one is fairly
simple.) I always get hung up on a cmp that works this way because at
some point you discover a recursive cmp of two objects and you need to
decide what to do. You can't just print "..." :-).

So the real problem is defining some reasonable semantics for
comparison of recursive objects. I checked what Scheme and Common
Lisp, thinking that these languages must have dealt with the issue
before. The answer, at least in Scheme, is infinite loop. R5RS
notes: "'Equal?' may fail to terminate if its arguments are circular
data structures. " http://www-swiss.ai.mit.edu/~jaffer/r5rs_8.html#SEC49
For eq? and eqv?, the answer is #f.

The issue was also discussed in some detail by the ANSI commitee
X3J13. A summary of the discussion is at here:
http://www.xanalys.com/software_tools/reference/HyperSpec/Issues/iss143-writeup.html

The result was to "Clarify that EQUAL and EQUALP do not descend any
structures or data types other than the ones explicitly specified
here:" [.both descend for cons, bit-vectors, and strings; equalp has
some special rules for hashtables and arrays]

I believe this means that Common Lisp behaves the same way that Scheme
does: comparison of circular data structures does not terminate.

I don't think an infinite loop is any better than a core dump. At
least with the core dump, you can inspect the core file and figure out
what went wrong. In the infinite loop case, you'd wonder for a while
why your program doesn't terminate, then kill it and inspect the core
file anway :-).

I think the comparison ought to return false or raise a ValueError.
I'm not sure which is right. It seems odd to me that comparing two
builtin lists could ever raise an exception, but it may be more
Pythonic to raise an exception in the face of ambiguity. As the
X3J13 committee noted:

Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program.

So, in the end, I propose ValueError.

Jeremy
Re: trashcan and PR#7 [ In reply to ]
Jeremy Hylton wrote:
>
> >>>>> "CT" == Christian Tismer <tismer@tismer.com> writes:
>
> CT> Vladimir Marangozov wrote:
> >> While I'm at it, maybe the same recursion control logic could be
> >> used to remedy (most probably in PyObject_Compare) PR#7:
> >> "comparisons of recursive objects" reported by David Asher?
>
> CT> Hey, what a good idea.
>
> CT> You know what's happening? We are moving towards tail recursion.
> CT> If we do this everywhere, Python converges towards Stackless
> CT> Python.
>
> It doesn't seem like tail-recursion is the issue, rather we need to
> define some rules about when to end the recursion. If I understand
> what is being suggest, it is to create a worklist of subobjects to
> compare instead of making recursive calls to compare. This change
> would turn the core dump into an infinite loop; I guess that's an
> improvement, but not much of one.

Well, I actually didn't read PR#7 before replying.
Thought it was about comparing deeply nested structures.

What about this?
For one, we do an improved comparison, which is of course
towards tail recursion, since we push part of the work
after the "return".
Second, we can guess the number of actually existing objects,
and limit the number of comparisons by this.
If we need more comparisons than we have objects,
then we raise an exception.

Might still take some time, but a bit less than infinite.

ciao - chris (sub-cantor-set-minded)

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com
Re: trashcan and PR#7 [ In reply to ]
Just after I sent the previous message, I realized that the "trashcan"
approach is needed in addition to some application-specific logic for
what to do when recursive traversals of objects occur. This is true
for repr and for a compare that fixes PR#7.

Current recipe for repr coredump:

original = l = []
for i in range(1000000):
new = []
l.append(new)
l = new
l.append(original)
repr(l)

Jeremy