More on transitioning to Numarray

Today, I realized that I needed to restate what my intention in raising the subject to begin with was. First of all, I would like to see everybody transition to Numarray someday. On the other hand, I'm not willing to ignore performance issues just to reach that desireable goal. I would like to recast my proposal into the framework of helping SciPy transition to Numarray. Basically, I don't think Numarray will be ready to fully support SciPy in less than a year (basically because it probably won't happen until some of us SciPy folks do a bit more work with Numarray). To help that along I am proposing making a few changes to the Numeric object that SciPy uses so that the array object SciPy expects starts looking more and more like the Numarray object. We have wanted to do this in SciPy and were simply wondering if it would make sense to change the Numeric object or to grab the Numeric code base into SciPy and make changes there. The feedback from the community has convinced me personally that we should leave Numeric alone and make any changes to something we create inside of SciPy. There is a lot of concern over having multiple implementations of nd arrays due to potential splitting of tools, etc. But, I should think that tools should be coded to an interface (API, methods, data structures) instead of a signle implementation, so that the actual underlying object should not matter greatly. I thought that was the point of modular development and object-orientedness .... Anyone doing coding with numeric arrays already has to distinguish between: Python Imaging Objects, Lists of lists, and other array-like objects. I think it is pretty clear that Numeric won't be changing. Thus, anything we do with the Numeric object will be done from the framework of SciPy. Best regards. Travis O.
participants (1)
-
Travis Oliphant