[Numpy-discussion] Numeric3.0 - Currently available under scipy/base as version 0.6.1 (Windows)

[Colin J. Williams]

Travis Oliphant wrote:

> Colin J. Williams wrote:
>
>>
>> I have a package based on subclassing numarray, which is working 
>> satisfactorily, and am looking at the possibility of transferring the 
>> package to work under the revised Numeric.
>>
>> My feeling is that the transfer is probably feasible but that it 
>> would be premature to work on it at this time.
>
>
> That's unfortunate.  The more feedback we get early on about 
> subclassing, the better.

The publication of  Python style defs, together with doc strings
describing the acceptable arguments for the various __new__
methods would help here.  I don't find info on ndarray.__new__.
Incidentally, ArrayType seems a better, more meaningful name for the
class/type.

>>
>> One of the problems is the cluttered namespace, through the use of 
>> "from X import *".  This is a style which is deprecated, see page 401 
>> of Alex Martelli's /Python in a Nutshell/.
>
>
> You will have to be more specific about what you think is wrong.  What 
> namespace is "cluttered" exactly.   Just because use is made of from X 
> import * in one module does not mean everything is "cluttered".  SciPy 
> Core makes use of the __all__ variables to control what gets imported 
> and usually only specific functions are imported as necessary. 
>
>> Another problem, at this stage, is that many doc strings are missing 
>> and that some which exist are a little cryptic.
>
>
> I would submit there are more docstrings then Numeric had.   Jump in 
> and help.   The water is fine.
>
>>
>> I would like to take another look when the next win32 binaries are 
>> available.
>
>
> There has been much improvement since the last beta.  I'm trying to 
> track down some remaining memory leaks before releasing new windows 
> binaries.    The SVN code is always available for check out and it is 
> quite easy to build.   We could always use more build testers to make 
> sure building is going as smoothly as we believe it is.
>
I now have 0.6.1, thanks.  Now, some documentation on ndarray/ArrayType
would be helpful, with the fact that __new__ alone is used instead of
the usual __new__ + __init__.  Among the parameters is buffer, it seems
that this accepts buffers or strings, anything else? Iinformation on
call backs (from ufuncs?) would help.

For many cases, it would be better to create a Sub instance with
Sub(aList) but, if the subclass must respond to callbacks then this may
be inhibited.

>>
>> Some further thoughts on the present state of Numeric3.0 are 
>> available here <http://www3.sympatico.ca/cjw/scipy1/>.
>
>
>
> Most of your comments have more to do with differences between builtin 
> types and Python classes than anything about scipy.    The type-class 
> chasm has shrunken of late, but there are still remaining issues.     
> These are Python issues that I believe are of little concern.
>
> I will comment on your issues that are not related to the above comment:
>
>
>      Use of package __init__.py to create namespace.
>
> If the epydoc and pydoc tools are not respecting the __init__.py code 
> then I would say they are broken.    Using the __init__.py this way 
> frees the user from having to understand every little detail of the 
> package structure (which could also change as better organization is 
> obtained in the future).
>
>
>      Use of the from X import Y style
>
> Please give more support here.  Just because one Python user advocates 
> against it is not sufficient argument.  There is an argument to be 
> made for avoiding attribute lookups by importing the names directly in 
> this fashion.
>
>
>      *Methods vs functions*
>
> I agree that methods and functions are somewhat redundant.  However, 
> the functions are still needed both to support lists and especially 
> for back-wards compatibility. Your example using take is odd (perhaps 
> it's a bug in an old release).  I get consistent behavior.   One 
> problem is you define a 1-d array in one case and a 2-d array in 
> another.  Of course the answers will be different.  
> One difference is that the default axis argument is different.  The 
> old functions have exactly the same default axis argument as they 
> always did, while the methods have a default of None for the axis 
> (which means treat the array as flat).
>
>
>      Lack of basic information in the doc strings
>
> Your examples are all class constructors.  First of all, there is no 
> special __init__  method for the ndarray because __new__ takes care of 
> it.    Second of all, the new method does need better documentation.  
> I'm not sure where to put it, though.   The array_new function is 
> placed in the TypeObject of the array type.   The __new__ attribute is 
> pasted on by PyTypeReady.  I'm not sure how to give a docstring as well.
> I suspect the proper thing to do is place the information in the 
> docstring for the Type Object.
>
>
> -Travis
>
I was wrong in my earlier comment about take but there are some problems
as, I hope, the script below illustrates.

Colin W.

# tTake.py

'''
In those cases where there is a duplication, it is suggested that only
the method is needed unless the function handles a wider range of data
than a method.

The function take does more than the method:

>>> S.ndarray((1,2)).take([0])

array([[ 1.05176460e-305, 5.63390393e-311]])

>>> S.take([[1, 2]], [0])

array([[1, 2]])

>>> S.take.__doc__

>>>

'''

import numarray.numarraycore as N
import numarray.numerictypes as NT
import scipy as S

a= S.ndarray((2, ), dtype= S.int8, buffer= '12')
print 'a:', `a`
b= S.arange(12, dtype= S.int8).reshape(3, 4)
print 'b:', `b`
print 'b.take(((0, 0), (2, 2)), 1):', `b.take(((0, 0), (2, 2)), 1)`
c= N.arange(12, dtype=NT.Int8, shape=(3, 4))    # this is a bit easier
to use
print 'c:', `c`
print 'c.take(((0, 0), (2, 2)), 1):', `c.take(((0, 0), (2, 2)), 1)`  #
not quite the same as above
print 'b-c:', `b-c`                             # this needs to raise an
exception