[Numpy-discussion] OpenOpt Suite release 0.45
Wed Apr 10 04:45:09 CDT 2013
On Wed, 2013-04-10 at 11:54 +0300, Dmitrey wrote:
> On 04/10/2013 10:31 AM, Robert Kern wrote:
> > You think comparing tracked bug counts across different projects
> > means anything? That's adorable. I admire your diligence at
> > addressing the bugs that you do acknowledge. That was never in
> > question. But refusing to acknowledge a bug is not the same thing as
> > fixing a bug. You cannot use objects that do not have a valid
> > __eq__() (as in, returns boolean True if and only if they are to be
> > considered equivalent for the purpose of dictionary lookup,
> > otherwise returns False) as dictionary keys. Your oofun object still
> > violates this principle. As dictionary keys, you want them to use
> > their `id` attributes to distinguish them, but their __eq__() method
> > still just returns another oofun with the default
> > object.__nonzero__() implementation. This means that bool(some_oofun
> > == other_oofun) is always True regardless of the `id` attributes.
> > You have been unfortunate enough to not run into cases where this
> > causes a problem yet, but the bug is still there, lurking, waiting
> > for a chance hash collision to silently give you wrong results. That
> > is the worst kind of bug. -- Robert Kern
> I had encountered the bugs with bool(some_oofun == other_oofun) when
> it was raised from other, than dict, cases, e.g. from "in list" (e.f.
> "if my_oofun in freeVarsList") etc, and had fixed them all. But that
> one doesn't occur from "in dict", I traced it with both debugger and
> putting print("in __eq__"),print("in __le__"), print("in __lt__"),
> print('in __gt__'), print('in __ge__') statements.
This is all good and nice, but Robert is still right. For dictionaries
to work predictable you need to ensure two things.
if object1 == object2:
assert bool(hash(object1) == hash(object2))
and second, which is your case for the dictionary lookup to be
predictable this must always work:
keys, values = zip(*dictionary.keys())
assert(keys.count(object2) == 1)
index = keys.index(object2)
value = values[index]
And apparently this is not the case and it simply invites bugs which are
impossible to track down because you will not see them in small tests.
Instead you will have code that runs great for toy problems and can
suddenly break down in impossible to understand ways when you have large
So hopefully the list fixes you mention provide that the second code
block will work as you would expect dictionary[object2] to work, but if
this is not the case...
> As I had mentioned, removing mapping oofuns as dict keys is mere
> impossible - this is fundamental thing whole FuncDesigner is build on,
> as well as its user API.
> NumPy-Discussion mailing list
More information about the NumPy-Discussion