[Numpy-discussion] End of Holidays small comments

[Todd Miller]

Wow!   This is great feedback.  Thanks Edward.

Edward C. Jones wrote:

> node35.html:
>
>     >>> print x.type(), x.real.type()
>     D d
>
> should be
>
>     >>> print x.type(), x.real.type()
>     numarray type: Complex64 numarray type: Float64

I taked this over with Perry,  and think it should behave and be 
documented more like:
 >>> print x.type(), x.real.type()
Complex64  Float64

>
> ------------------------------------------------
>
> Why use both NUM_C_ARRAY and C_ARRAY?

In the context of the defining enumeration,  NUM_C_ARRAY looks correct. 
  Anywhere else,  C_ARRAY is about all I can stand.   C_ARRAY is so 
common that I thought a little irregularity would be tolerable.  Chock 
it up to tastelessness.

>
> ------------------------------------------------
>
> in  _ndarraymodule.c:
>
>         {"_byteoffset",
>          (getter)_ndarray_byteoffset_get,
>          (setter)_ndarray_byteoffset_set,
>          "shortest seperation between elements in bytes"},
>         {"_bytestride",
>          (getter)_ndarray_bytestride_get,
>          (setter)_ndarray_bytestride_set,
>          "shortest seperation between elements in bytes"},
>
> One of the comments is wrong. Also "separation".

Noted.

>
> ------------------------------------------------
>
> libnumarraymodule.c:
>
>     /* Create an empty array. */
>     static PyArrayObject *
>     NA_Empty(int ndim, int *shape, NumarrayType type)
>
> node42.html:
>
>     static PyObject* NA_Empty( NumarrayType type, int ndim, ...)
>
Noted.

>
> ------------------------------------------------
>
> I think NA_New should be
>
>     NA_New(int ndim, int* shape, NumarrayType type, void* buffer)
>
> The current NA_New is useful only when ndim is known at code-writing 
> time.

NA_New is a  "convenience wrapper" around NA_NewAll,  but I see your point.

How about NA_vNew(),  in the spirit of vprintf?

>
> ------------------------------------------------
>
> node39.html:
>
>     Note: the type parameter for a macro is one of the Numarray Numeric
>     Data Types, not a NumarrayType enumeration value.
>
> There should be an example of one of the GET/SET macros. How about
>
>     unsigned char n;
>     int i;
>     ...
>     n = NA_GET1(arr, UInt8, i);

OK.

>
> ------------------------------------------------
>
> It seems that the parameters "aligned" and "writeable" are ignored in 
> the source code for NA_NewAll and class NumArray.

"aligned" is used.

"writeable" should probably be dropped since it is no longer used.   
Since doing that would break an interface someone might be using,  I'd 
rather not.

>
> ------------------------------------------------
>
> I would like to see an "int* strides" parameter added to NA_NewAll, so a
> non-contiguous "buffer" can be used. 

OK.   How about NA_NewAllWithStrides (or insert a better name here)?

>
> ------------------------------------------------
>
> I suggest NA_Copy(PyObject* arr) which is something like
>
> static PyObject* NA_Copy(PyObject* arr)
> {
>     PyArrayObject* arr1 = arr;
>     return NA_NewAll(arr1->nd, (long*) arr1->dimensions, 

This  ((long *)) doesn't work portably, so I would recommend avoiding it.

>
>        arr1->descr->type_num, arr1->data, arr1->byteoffset,
>        arr1->bytestride, arr1->byteorder, 1, 1);
> }
>
I'll add NA_Copy().