[Numpy-discussion] Numarray header PEP
Todd Miller
jmiller at stsci.edu
Tue Jun 29 14:43:10 EDT 2004
Awesome! Thanks Gerard. This certainly sounds like the way to do it.
I'll take a closer look tomorrow.
Regards,
Todd
On Tue, 2004-06-29 at 17:32, gerard.vermeulen at grenoble.cnrs.fr wrote:
> On 29 Jun 2004 15:09:43 -0400, Todd Miller wrote
> > On Tue, 2004-06-29 at 13:44, Gerard Vermeulen wrote:
> > > >
> > > > The PEP is attached. It is formatted using the docutils package which
> > > > can be used to generate HTML or PDF. Comments and corrections would be
> > > > appreciated.
> > > >
> > > PyQwt is a Python extension which can be conditionally compiled against
> > > Numeric and/or numarray (both, one of them or none).
> >
> > Well that's cool! I'll have to keep the PyQwt guys in mind as potential
> > first users.
> >
> > > Your PEP excludes importing of Numeric and numarray in the same C-extension.
> >
> > This is true but I don't understand your solution so I'll blather on
> > below.
> >
> > > All you need to do is to hide the macros PyArray_Present(), PyArray_isArray()
> > > and import_array() into a few functions with numarray specific names, so
> > > that the following becomes possible:
> > >
> > > #include <Numeric/meta.h>
> > > /* defines the functions (no macros)
> > > int Numeric_Present();
> > > int Numeric_isArray();
> > > void import_numeric();
> > > to hide the Numeric C-API stuff in a small Numeric/meta.c file.
> > > */
> > > #include <numarray/meta.h>
> > > /* defines the functions (no macros)
> > > int numarray_Present();
> > > int numarray_isArray();
> > > void import_numarray();
> > > to hide the numarray C-API stuff in a small numarray/meta.c file.
> > > */
> > >
> >
> > I may have come up with the wrong scheme for the Present() and
> > isArray(). With my scheme, they *have* to be macros because the API
> > functions are unsafe: when numarray or Numeric is not present, the API
> > function table pointers are NULL so calling through them results in
> > either a fatal error or a segfault.
> >
> The macros can be hidden from the module file scope by wrapping them
> in a function (see attached demo)
> >
> > There is an additional problem that the "same functions" need to be
> > called through different API pointers depending on whether numarray
> > or Numeric is being supported. Redefinition of typedefs and enumerations
> >
> > (or perhaps conditional compilation short-circuited re-definitions) may
> > also present a problem with compiling (or worse, running).
> >
> Tested and works.
> >
> > I certainly like the idea of supporting both in the same extension
> > module, but don't see how to get there, other than with separate
> > compilation units. With seperate .c files, I'm not aware of a problem
> > other than lots of global symbols. I haven't demoed that yet so I am
> > interested if someone has made it work.
> >
> Yes, you cannot mix the numarray API and Numeric API in the same .c
> file, but nevertheless you can hide the macros in small functions so
> that the macros don't pollute.
>
> Here you have a litte extension module 'pep' which tries to import Numeric
> and numarray. It has a method 'whatsThere' that prints the names of
> the Numerical/numarray extension modules it has imported.
>
> It has also a method 'whatsThis' that prints if an object is a Numeric
> array, a numarray array or something else:
>
> Python 2.3.3 (#2, Feb 17 2004, 11:45:40)
> [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import pep
> >>> pep.whatsThere()
> Numeric!
> Numarray!
> >>> import Numeric
> >>> a = Numeric.arange(10)
> >>> pep.whatsThis(a)
> Numeric array
> >>> import numarray
> >>> a = numarray.arange(10)
> >>> pep.whatsThis(a)
> Numarray array
> >>> a = 10
> >>> pep.whatsThis(a)
> Something else
> >>>
>
> The MANIFEST reads:
> pepmodule.c
> setup.py
> Numeric/meta.c
> Numeric/meta.h
> numarray/meta.c
> numarray/meta.h
>
> My initial idea was to add the meta.* files to the Numeric/numarray include
> files, but I did not try yet to solve the problem of the
> PyArray_API PY_ARRAY_UNIQUE_SYMBOL defines in the same way (I am sure
> it can be done.
>
> Regards -- Gerard
--
More information about the NumPy-Discussion
mailing list