On Fri, Sep 9, 2011 at 1:41 PM, leif <not.rea...@online.de> wrote:
> On 9 Sep., 19:07, Simon King <simon.k...@uni-jena.de> wrote:
>> Hi!
>>
>> While I am at it: Why isn't there a __hash__ method for
>> sage.structure.SageObject written in Cython that can be inherited from
>> all elements and parents and needs not to be overridden? In
>> particular, needs not to be overridden by a slow Python method?
>>
>> I mean something like
>>
>> sage: cython("""
>> cdef class bla:
>> cdef object __hash
>> def __hash__(self):
>> if self.__hash is not None:
>> return self.__hash
>> self.__hash = self._hash_()
>> return self.__hash
>> """)
>> sage: class Foo(bla, object):
>> ....: def _hash_(self):
>> ....: return hash(repr(self))
>> ....:
>> sage: f = Foo()
>> sage: %timeit hash(f)
>> 625 loops, best of 3: 213 ns per loop
>>
>> Compare this with the current default __hash__:
>> sage: P = Parent()
>> sage: %timeit hash(P)
>> 625 loops, best of 3: 18.9 µs per loop
>>
>> Hence, for implementing the hash, the user provides _hash_ rather than
>> __hash__.
>>
>> Storing the hash value should be possible, since mutable objects are
>> not supposed to be hashable, right?
>>
>> Of course, that would mean a lot of dull work, namely: Rename any
>> __hash__ method into _hash_, for any class derived from SageObject.
>> And also "of course", one may provide the possibility to make a class
>> unhashable.
>>
>> But I think if all SageObjects would only need 213 ns rather than 18.9
>> µs to return their hash, one could get a very decent general speed-up
>> of Sage. So, the dull work could be worth it, isn't it?
>
> Zounds reeznbl, give it a try... :P
>
> (Perhaps ask Robert B. if he could write some script changing all the
> instances of __hash__() to _hash_ for classes derived from
> SageObject.)
>
> I'm not sure whether one would notice (or even be able to measure) any
> performance gain though, since for typical Sage objects most time is
> certainly spent in actually computing the hash (assuming the
> __hash__() methods are already cached, which I'm not sure about),
My impression is that they are usually *not* already cached. The
point I think of Simon's suggestion is to make sure that they are
always cached by default, with no extra work by the developer. This
sounds like a really good idea.
William
>
>
> -leif
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
