On 8/25/05, Jack Diederich <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 25, 2005 at 09:23:09PM +0300, Stelios Xanthakis wrote:
> > The explanation is this: hash
> > and comparison of objects depends on the state of the memory
> > allocator. A sample case is this:
> >
> > class A: pass
> > dummy0=47 # comment this to get a different result for min
> > a=A()
> > b=A()
> > print min (a, b)
> >
> > the result of 'min' is not only non-deterministic but also depends
> > on whether other things have been allocated before. The same
> > thing can happen for 'dictionary.keys()' if the keys are objects
> > and 'iterate-over-set' when the set contains objects.
> >
I'm also pretty sure I've caught a bug in his code, though I'm not
sure how it works exactly. I replaced the 'min' built-in with my own
min, and he's going to get nondeterministic results from this line:
mm = min((c.S, c) for c in rowitems(h))[1].D
because 'c' is often the exact same object. A snippet from my
debugging version of 'min', which prints out the tuple its handed:
(1, <__main__.LLentry object at 0x00969710>)
(1, <__main__.LLentry object at 0x00969710>)
(4, <__main__.LLentry object at 0x00969710>)
<snip more 4s from the same object>
(4, <__main__.LLentry object at 0x00969710>)
(3, <__main__.LLentry object at 0x00969710>)
(3, <__main__.LLentry object at 0x00969710>)
(3, <__main__.LLentry object at 0x00969710>)
(2, <__main__.LLentry object at 0x00969710>)
<snip more 2s, same object>
Although they appear in order here, they don't always. Often, multiple
objects have a value of 1, and he's going to get one of them at random
as the 'min' object. I'm pretty sure.
Mark, can you confirm that this is/isn't a bug?
(btw, it still runs fast with and slow without the dummies with my
custom min() func)
Peace
Bill Mill
bill.mill at gmail.com
--
http://mail.python.org/mailman/listinfo/python-list
