[Numpy-discussion] OpenOpt Suite release 0.45

[Robert Kern]

On Sat, Mar 16, 2013 at 6:19 PM, Dmitrey <tmp50 at ukr.net> wrote:
>
>
> --- Исходное сообщение ---
> От кого: "Robert Kern" <robert.kern at gmail.com>
> Дата: 16 марта 2013, 19:54:51
>
> On Sat, Mar 16, 2013 at 10:39 AM, Matthieu Brucher
> <matthieu.brucher at gmail.com> wrote:
>> Even if they have different hashes, they can be stored in the same
>> underlying list before they are retrieved. Then, an actual comparison is
>> done to check if the given key (i.e. object instance, not hash) is the
>> same
>> as one of the stored keys.
>
> Right. And the rule is that if two objects compare equal, then they
> must also hash equal. Unfortunately, it looks like `oofun` objects do
> not obey this property. oofun.__eq__() seems to return a Constraint
> rather than a bool, so oofun objects should simply not be used as
> dictionary keys.
>
> It is one of several base features FuncDesigner is build on and is used
> extremely often and wide; then whole FuncDesigner would work incorrectly
> while it is used intensively and solves many problems better than its
> competitors.

I understand. It just means that you can't oofun objects as dictionary
keys. Adding a __hash__() method is not enough to make that work.

> That's quite possibly the source of the bug. Or at
> least, that's a bug that needs to get fixed first before attempting to
> debug anything else or attribute bugs to Python or numpy. Also, the
> lack of a bool-returning __eq__() will prevent proper sorting, which
> also seems to be used in the code snippet that Dmitrey showed.
>
> as I have already mentioned, I ensured via debugger that my __eq__, __le__
> etc are not involved from the buggy place of the code, only __hash__ is
> involved from there.

oofun.__lt__() will certainly be called, and it too is problematic. If
pointDerivates is a dict mapping oofun objects to other objects as you
say, then derivative_items will be a list of (oofun, object) tuples.
If you sort derivative_items by the first element, the oofun objects,
then oofun.__lt__() *will* be called. That's how list.sort() works. I
was wrong: oofun.__eq__() won't be called by the sorting.

You are probably not seeing the oofun.__eq__() problem in that code
because of an implementation detail in Python: dicts will check
identity first before trying to compare with __eq__(). You may be
having problems in the construction of the pointDerivates dict or
ooVarsIndDict outside of this code snippet, so if you just ran your
debugger over this code snippet, you would not detect those calls.
However, if you are not seeing the oofun.__lt__() calls from the
sorting with your debugger, then your debugger may be missing the
oofun.__eq__() calls, too.

By all means, if you still think the bug is in someone else's code,
please post a short example that other people can run that will
demonstrate the problem.

--
Robert Kern