On Fri, Dec 4, 2009 at 9:23 PM, Francesc Alted <fal...@pytables.org> wrote:
> A Thursday 03 December 2009 14:56:16 Dag Sverre Seljebotn escrigué:
>> Pauli Virtanen wrote:
>> > Thu, 03 Dec 2009 14:03:13 +0100, Dag Sverre Seljebotn wrote:
>> > [clip]
>> >
>> >> Great! Are you storing the format string in the dtype types as well? (So
>> >> that no release is needed and acquisitions are cheap...)
>> >
>> > I regenerate it on each buffer acquisition. It's simple low-level C code,
>> > and I suspect it will always be fast enough. Of course, we could *cache*
>> > the result in the dtype. (If dtypes are immutable, which I don't remember
>> > right now.)
>>
>> We discussed this at SciPy 09 -- basically, they are not necesarrily
>> immutable in implementation, but anywhere they are not that is a bug and
>> no code should depend on their mutability, so we are free to assume so.
>
> Mmh, the only case that I'm aware about dtype *mutability* is changing the
> names of compound types:
>
> In [19]: t = np.dtype("i4,f4")
>
> In [20]: t
> Out[20]: dtype([('f0', '<i4'), ('f1', '<f4')])
>
> In [21]: hash(t)
> Out[21]: -9041335829180134223
>
> In [22]: t.names = ('one', 'other')
>
> In [23]: t
> Out[23]: dtype([('one', '<i4'), ('other', '<f4')])
>
> In [24]: hash(t)
> Out[24]: 8637734220020415106
>
> Perhaps this should be marked as a bug? I'm not sure about that, because the
> above seems quite useful.
Hm, that's strange - I get the same hash in both cases, but I thought
I took into account names when I implemented the hashing protocol for
dtype. Which version of numpy on which os are you seeing this ?
David
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
