[Numpy-discussion] OpenOpt Suite release 0.45

[Dmitrey]

--- Исходное сообщение ---
От кого: "Matthieu Brucher" <matthieu.brucher at gmail.com>
Дата: 16 марта 2013, 12:39:07

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.



but, as I have already mentioned, comparison of oofun(s) via __le__,
__eq__ etc doesn't change their inner state (but the methods can create
additional oofun(s), although).
I have checked via debugger - my methods __le__, __eq__, __lt__, __gt__,
__ge__ are not called from the buggy place of code, only __hash__ is
called from there. Python could check key objects equivalence via id(),
although, but I don't see any possible bug source from using id().
D.




2013/3/16 Dmitrey <tmp50 at ukr.net>



--- Исходное сообщение ---
От кого: "Matthieu Brucher" <matthieu.brucher at gmail.com>
Дата: 16 марта 2013, 11:33:39

Hi,

Different objects can have the same hash, so it compares to
find the actual correct object.
Usually when you store something in a dict and later you
can't find it anymore, it is that the internal state changed
and that the hash is not the same anymore.


my objects (oofuns) definitely have different __hash__() results
- it's just integers 1,2,3 etc assigned to the oofuns (stored in
oofun._id field) when they are created.

D.



Matthieu


2013/3/16 Dmitrey <tmp50 at ukr.net>



--- Исходное сообщение ---
От кого: "Alan G Isaac" <alan.isaac at gmail.com>
Дата: 15 марта 2013, 22:54:21

On 3/15/2013 3:34 PM, Dmitrey wrote:
> the suspected bugs are not documented yet


I'm going to guess that the state of the F_i changes
when you use them as keys (i.e., when you call __le__.        

no, their state doesn't change for operations like __le__
. AFAIK searching Python dict doesn't calls __le__ on the
object keys at all, it operates with method .__hash__(),
and latter returns fixed integer numbers assigned to the
objects earlier (at least in my case).


 It is very hard to imagine that this is a Python or NumPy bug.

Cheers,
Alan

_______________________________________________
NumPy-Discussion mailing list          NumPy-Discussion at scipy.org                    http://mail.scipy.org/mailman/listinfo/numpy-discussion                  


_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion at scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion




--
Information System Engineer, Ph.D.
Blog: http://matt.eifelle.com
LinkedIn: http://www.linkedin.com/in/matthieubrucher
Music band: http://liliejay.com/

_______________________________________________
NumPy-Discussion mailing list      NumPy-Discussion at scipy.org            http://mail.scipy.org/mailman/listinfo/numpy-discussion          




--
Information System Engineer, Ph.D.
Blog: http://matt.eifelle.com
LinkedIn: http://www.linkedin.com/in/matthieubrucher
Music band: http://liliejay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130316/2102a545/attachment.html>