On Wednesday 30 June 2004 11:33 pm, gerard.vermeulen at grenoble.cnrs.fr wrote:
> On 30 Jun 2004 17:54:19 -0400, Todd Miller wrote
>
> > So... you use the "meta" code to provide package specific ordinary
> > (not-macro-fied) functions to keep the different versions of the
> > Present() and isArray() macros from conflicting.
> >
> > It would be nice to have a standard approach for using the same
> > "extension enhancement code" for both numarray and Numeric. The PEP
> > should really be expanded to provide an example of dual support for one
> > complete and real function, guts and all, so people can see the process
> > end-to-end; Something like a simple arrayprint. That process needs
> > to be refined to remove as much tedium and duplication of effort as
> > possible. The idea is to make it as close to providing one
> > implementation to support both array packages as possible. I think it's
> > important to illustrate how to partition the extension module into
> > separate compilation units which correctly navigate the dual
> > implementation mine field in the easiest possible way.
> >
> > It would also be nice to add some logic to the meta-functions so that
> > which array package gets used is configurable. We did something like
> > that for the matplotlib plotting software at the Python level with
> > the "numerix" layer, an idea I think we copied from Chaco. The kind
> > of dispatch I think might be good to support configurability looks like
> > this:
> >
> > PyObject *
> > whatsThis(PyObject *dummy, PyObject *args)
> > {
> > PyObject *result, *what = NULL;
> > if (!PyArg_ParseTuple(args, "O", &what))
> > return 0;
> > switch(PyArray_Which(what)) {
> > USE_NUMERIC:
> > result = Numeric_whatsThis(what); break;
> > USE_NUMARRAY:
> > result = Numarray_whatsThis(what); break;
> > USE_SEQUENCE:
> > result = Sequence_whatsThis(what); break;
> > }
> > Py_INCREF(Py_None);
> > return Py_None;
> > }
> >
> > In the above, I'm picturing a separate .c file for Numeric_whatsThis
> > and for Numarray_whatsThis. It would be nice to streamline that to one
> > .c and a process which somehow (simply) produces both functions.
> >
> > Or, ideally, the above would be done more like this:
> >
> > PyObject *
> > whatsThis(PyObject *dummy, PyObject *args)
> > {
> > PyObject *result, *what = NULL;
> > if (!PyArg_ParseTuple(args, "O", &what))
> > return 0;
> > switch(Numerix_Which(what)) {
> > USE_NUMERIX:
> > result = Numerix_whatsThis(what); break;
> > USE_SEQUENCE:
> > result = Sequence_whatsThis(what); break;
> > }
> > Py_INCREF(Py_None);
> > return Py_None;
> > }
> >
> > Here, a common Numerix implementation supports both numarray and Numeric
> > from a single simple .c. The extension module would do "#include
> > numerix/arrayobject.h" and "import_numerix()" and otherwise just call
> > PyArray_* functions.
> >
> > The current stumbling block is that numarray is not binary compatible
> > with Numeric... so numerix in C falls apart. I haven't analyzed
> > every symbol and struct to see if it is really feasible... but it
> > seems like it is *almost* feasible, at least for typical usage.
> >
> > So, in a nutshell, I think the dual implementation support you
> > demoed is important and we should work up an example and kick it
> > around to make sure it's the best way we can think of doing it.
> > Then we should add a section to the PEP describing dual support as well.
>
> I would never apply numarray code to Numeric arrays and the inverse. It
> looks dangerous and I do not know if it is possible. The first thing
> coming to mind is that numarray and Numeric arrays refer to different type
> objects (this is what my pep module uses to differentiate them). So, even
> if numarray and Numeric are binary compatible, any 'alien' code referring
> the the 'Python-standard part' of the type objects may lead to surprises. A
> PEP proposing hacks will raise eyebrows at least.
>
> Secondly, most people use Numeric *or* numarray and not both.
>
> So, I prefer: Numeric In => Numeric Out or Numarray In => Numarray Out
> (NINO) Of course, Numeric or numarray output can be a user option if NINO
> does not apply. (explicit safe conversion between Numeric and numarray is
> possible if really needed).
>
> I'll try to flesh out the demo with real functions in the way you indicated
> (going as far as I consider safe).
>
> The problem of coding the Numeric (or numarray) functions in more than
> a single source file has also be addressed.
>
> It may take 2 weeks because I am off to a conference next week.
>
> Regards -- Gerard
Hi all,
first, I would like to state that I don't understand much of this discussion;
so the only comment I wanted to make is that IF this where possible, to make
(C/C++) code that can live with both Numeric and numarray, then I think it
would be used more and more - think: transition phase !! (e.g. someone could
start making the FFTW part of scipy numarray friendly without having to
switch everything at one [hint ;-)] )
These where just my 2 cents.
Cheers,
Sebastian Haase