[Numpy-discussion] NumPy SVN broken

Charles R Harris charlesr.harris@gmail....
Wed Oct 7 12:48:45 CDT 2009


On Wed, Oct 7, 2009 at 7:07 AM, Charles R Harris
<charlesr.harris@gmail.com>wrote:

>
>
> On Wed, Oct 7, 2009 at 6:59 AM, Charles R Harris <
> charlesr.harris@gmail.com> wrote:
>
>>
>>
>> On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau <cournape@gmail.com>wrote:
>>
>>> On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
>>> <charlesr.harris@gmail.com> wrote:
>>> >
>>> >
>>> > On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau <cournape@gmail.com>
>>> wrote:
>>> >>
>>> >> On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
>>> >> <charlesr.harris@gmail.com> wrote:
>>> >> >
>>> >> >
>>> >> > Looks like a clue ;)
>>> >>
>>> >> Ok, I fixed it here:
>>> >>
>>> >> http://github.com/cournape/numpy/tree/fix_abi
>>> >>
>>> >> But that's an ugly hack. I think we should consider rewriting how we
>>> >> generate the API: instead of automatically growing the API array of
>>> >> fptr, we should explicitly mark which function name has which index,
>>> >> and hardcode it. It would help quite a bit to avoid changing the ABI
>>> >> unvoluntary.
>>> >>
>>> >
>>> > I'm thinking the safest thing to do is to move the new type to the end
>>> of
>>> > the list.
>>>
>>> That's what the above branch does.
>>>
>>> > I'm not sure what all the ramifications are for compatibility to
>>> > having it stuck in the middle like that, does it change the type
>>> numbers for
>>> > all the types after?
>>>
>>> Yes, there is no space left between the types declarations and the
>>> first functions. Currently, I just put things at the end manually, but
>>> that's really error prone.
>>>
>>> I am a bit lazy to fix this for real (I was thinking about using a
>>> python dict with hardcoded indexes as an entry instead of the current
>>> .txt files, but this requires several changes in the code generator,
>>> which is already not the greatest code to begin with).
>>>
>>>
>> What I'm concerned about is that, IIRC, types in the c-code can be
>> referenced by their index in a list of types and that internal mechanism
>> might be exposed to the outside somewhere. That is, what has happened to the
>> order of the enumerated types? If that has changed, and if external code
>> references a type by a hard-wired number, then there is a problem that goes
>> beyond the code generator. The safe(r) thing to do in that case is add the
>> new type to the end of the enumerated types and fix the promotion code so it
>> doesn't try to rely on a linear order.
>>
>>
> Here, for instance:
>
> "The various character codes indicating certain types are also part of an
> enumerated
> list. References to type characters (should they be needed at all) should
> always use
> these enumerations. The form of them is NPY <NAME>LTR where <NAME>"
>
> So those macros will generate a hard-coded number at compile time, and
> number that might have changed with the addition of the new types.
>
>
Nevermind, it looks like the new type number is at the end as it should be.

In [22]: typecodes
Out[22]:
{'All': '?bhilqpBHILQPfdgFDGSUVOMm',
 'AllFloat': 'fdgFDG',
 'AllInteger': 'bBhHiIlLqQpP',
 'Character': 'c',
 'Complex': 'FDG',
 'Datetime': 'Mm',
 'Float': 'fdg',
 'Integer': 'bhilqp',
 'UnsignedInteger': 'BHILQP'}

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20091007/26c54b16/attachment-0001.html 


More information about the NumPy-Discussion mailing list