numeric / numarray

I just updated the image module to work with Numeric or numarray (now
that matplotlib is the recommended 2D plotting package on the numarray
homepage!). Changes in CVS.

The code uses the Numeric compatibility layer of numarray, but I am
unsure how to best handle the decision of which one to build with.
Whichever arrayobject.h you include (Numeric or numarray), the code
works with either kind of array, so that is not the issue. But there
will be those who want to build with numarray and vice-versa, so my
question is how to best support this.

Here is what I am currently doing in setup.py:

    # build the image support module - requires agg and Numeric or
    # numarray. You can build the image module with either Numeric or
    # numarray. Whichever way you build it, the code will work with
    # both Numeric or numarray arrays, but you will get the best
    # performance if you build with the type of array you use most
    #BUILD_IMAGE = 0 # no image support
    #BUILD_IMAGE = 'Numeric' # use Numeric
    BUILD_IMAGE = 'numarray' # use numarray

and then setting a precompiler macro in setupext.py which determines
which header is used.

Another possibility is to look for a matplotlibrc file at build time
and build according to the numerix setting. I think this is a nice
solution but adds an extra later of complexity.
        
The additional (and perhaps most important) question is how to handle
the win32 build vis-a-vis Numeric/numarray?

I ran some very rough profiling numbers. image_demo.py and
image_demo_na.py are identical except the latter defines
rcParams['numerix'] = 'numarray'.

    # build with Numeric
    hunter:> time python image_demo.py -dAgg
    0.460u 0.070s 0:00.61 86.8% 0+0k 0+0io 5040pf+0w
    hunter:> time python image_demo_na.py -dAgg
    2.550u 0.080s 0:02.79 94.2% 0+0k 0+0io 5211pf+0w

    # build with numarray
    hunter:> time python image_demo.py -dAgg
    0.560u 0.140s 0:00.78 89.7% 0+0k 0+0io 5226pf+0w
    hunter:> time python image_demo_na.py -dAgg
    0.540u 0.120s 0:00.72 91.6% 0+0k 0+0io 5197pf+0w

The basic result is that numarray users pay a heavy performance price
if the image module is built with Numeric, but if built with numarray
both types of arrays perform comparably (and are performance
competitive with the pure numeric case)

Finally, if any of you stsci folks on the list have a nice color image
of the heavens you could produce with imshow, that would make a
stellar screenshot for the website :slight_smile:

JDH

I just updated the image module to work with Numeric or numarray (now
that matplotlib is the recommended 2D plotting package on the numarray
homepage!). Changes in CVS.

The code uses the Numeric compatibility layer of numarray, but I am
unsure how to best handle the decision of which one to build with.
Whichever arrayobject.h you include (Numeric or numarray), the code
works with either kind of array, so that is not the issue. But there
will be those who want to build with numarray and vice-versa, so my
question is how to best support this.

Here is what I am currently doing in setup.py:

    # build the image support module - requires agg and Numeric or
    # numarray. You can build the image module with either Numeric or
    # numarray. Whichever way you build it, the code will work with
    # both Numeric or numarray arrays, but you will get the best
    # performance if you build with the type of array you use most
    #BUILD_IMAGE = 0 # no image support
    #BUILD_IMAGE = 'Numeric' # use Numeric
    BUILD_IMAGE = 'numarray' # use numarray

and then setting a precompiler macro in setupext.py which determines
which header is used.

Another possibility is to look for a matplotlibrc file at build time
and build according to the numerix setting. I think this is a nice
solution but adds an extra later of complexity.
        
The additional (and perhaps most important) question is how to handle
the win32 build vis-a-vis Numeric/numarray?

I ran some very rough profiling numbers. image_demo.py and
image_demo_na.py are identical except the latter defines
rcParams['numerix'] = 'numarray'.

    # build with Numeric
    hunter:> time python image_demo.py -dAgg
    0.460u 0.070s 0:00.61 86.8% 0+0k 0+0io 5040pf+0w
    hunter:> time python image_demo_na.py -dAgg
    2.550u 0.080s 0:02.79 94.2% 0+0k 0+0io 5211pf+0w

    # build with numarray
    hunter:> time python image_demo.py -dAgg
    0.560u 0.140s 0:00.78 89.7% 0+0k 0+0io 5226pf+0w
    hunter:> time python image_demo_na.py -dAgg
    0.540u 0.120s 0:00.72 91.6% 0+0k 0+0io 5197pf+0w

The basic result is that numarray users pay a heavy performance price
if the image module is built with Numeric, but if built with numarray
both types of arrays perform comparably (and are performance
competitive with the pure numeric case)

I'll try to find out why there's a difference here.

Finally, if any of you stsci folks on the list have a nice color image
of the heavens you could produce with imshow, that would make a
stellar screenshot for the website :slight_smile:

Perry probably has ideas about more appropriate images for this
application, but here is one of the coolest images I know of. (check it
out even if you don't want a jpeg):

http://imgsrc.hubblesite.org/hu/db/2004/07/images/m/formats/full_jpg.jpg

I believe the deepest optical image ever taken, The Deepest. It's
called the Hubble Ultra Deep Field (HUDF). Almost everything in the
picture are galaxies. The picture itself represents a very small region
of sky. Each little spec is billions of suns.

Regards,
Todd

···

On Sat, 2004-03-27 at 16:22, John Hunter wrote:

JDH

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Todd Miller <jmiller@...31...>