On Sunday, June 3, 2012, Ralf Gommers wrote:
>
>
> On Sun, Jun 3, 2012 at 4:49 PM, Nathaniel Smith
> <n...@pobox.com<javascript:_e({}, 'cvml', 'n...@pobox.com');>
> > wrote:
>
>> On Sun, Jun 3, 2012 at 3:28 PM, Ralf Gommers
>> <ralf.gomm...@googlemail.com <javascript:_e({}, 'cvml',
>> 'ralf.gomm...@googlemail.com');>> wrote:
>> > Hi,
>> >
>> > Just ran into this:
>> >
>> >>>> np.__version__
>> > '1.5.1'
>> >>>> np.empty((1,), dtype='>h2') # works in 1.6.2 too
>> > array([0], dtype=int16)
>> >
>> >>>> np.__version__
>> > '1.7.0.dev-fd78546'
>> >>>> np.empty((1,), dtype='>h2')
>> > Traceback (most recent call last):
>> > File "<stdin>", line 1, in <module>
>> > TypeError: data type ">h2" not understood
>>
>> For reference the problem seems to be that in 1.6 and earlier, "h"
>> plus a number was allowed, and the number was ignored:
>>
>> >>> np.__version__
>> '1.5.1'
>> >>> np.dtype("h2")
>> dtype('int16')
>> >>> np.dtype("h4")
>> dtype('int16')
>> >>> np.dtype("h100")
>> dtype('int16')
>>
>> In current master, the number is disallowed -- all of those give
>> TypeErrors. Presumably because "h" already means the same as "i2", so
>> adding a second number on their is weird.
>>
>> Other typecodes with an "intrinsic size" seem to have the same problem
>> -- "q", "l", etc.
>>
>> Obviously "h2" should be allowed in 1.7, seeing as disallowing it
>> breaks scipy. And the behavior for "h100" is clearly broken and should
>> be disallowed in the long run. So I guess we need to do two things:
>>
>> 1) Re-enable the use of typecode + size specifier even in cases where
>> the typcode has an intrinsic size
>> 2) Issue a deprecation warning for cases where the intrinsic size and
>> the specified size don't match (like "h100"), and then turn that into
>> an error in 1.8.
>>
>> Does that sound correct?
>
>
> Seems correct as far as I can tell. Your approach to fixing the issue
> sounds good.
>
>
>> I guess the other option would be to
>> deprecate *all* use of size specifiers with these typecodes (i.e.,
>> deprecate "h2" as well, where the size specifier is merely redundant),
>> but I'm not sure removing that feature is really worth it.
>>
>
> Either way would be OK I think. Using "h2" is redundant, but I can see how
> someone could prefer writing it like that for clarity. It's not like 'h'
> --> np.int16 is obvious.
>
> Ralf
>
Also, we still need the number for some type codes such as 'a' to indicate
the length of the string. I like the first solution much better.
Ben Root
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
