numerix bug and bugfix

Community matplotlib-users
1

John, For the command-line selection mechanism of numerix.py

    > to work, the following change is needed:

    > if which[0] is None: ## Add this line which =
    > rcParams['numerix'], "rc"

    > Otherwise, the rcParams value clobbers the command-line
    > value.

Thanks for the alert on the numerix problem. The numerix module was
written before matplotlibrc existed and it appears was not properly
updated. It may be better to simplify this and only provide 2
choices, command line then rc file. Does anyone need any of the other
methods of choosing numerix? Is there any reason to keep .numerix or
the NUMERIX env var?

    > Update on pcolor_demo2.py: strange things are going on, but
    > now, using profile.py, I get 2.72 seconds with Numeric and
    > 9.49 seconds with numarray. I don't have any explanation
    > for why it was taking 80 seconds with numarray when I tried
    > it earlier today. It is still much slower than with
    > Numeric, though, which seems odd.

pcolor_demo2 uses imshow which is written in extension code using the
numerix/numarray compatibility layer. Todd and Perry can correct me
if I'm wrong, but I think you'll get better numarray performance if
you compile that extension with the 'NUMERIX = numarray' in setup.py.
The NUMERIX variable in setup.py determines which library the
extension code is compiled against. Whether you use numeric or
numarray, it will work with either, but you should get much better
performance if you match this compile flag to the library you use
most.

Let us know if this is indeed the cause of the performance hit. Here
are my numbers (best of three runs)

                     rc setting
                 Numeric | numarray
      compiled |

···

--------------------------------
      Numeric | 0.45s | 1.13s
      numarray | 0.59s | 0.60s

JDH

2

    > John, For the command-line selection mechanism of numerix.py
    > to work, the following change is needed:

    > if which[0] is None: ## Add this line which =
    > rcParams['numerix'], "rc"

    > Otherwise, the rcParams value clobbers the command-line
    > value.

Thanks for the alert on the numerix problem. The numerix module was
written before matplotlibrc existed and it appears was not properly
updated. It may be better to simplify this and only provide 2
choices, command line then rc file. Does anyone need any of the other
methods of choosing numerix? Is there any reason to keep .numerix or

I don't think so. It's only useful outside the context of matplotlib.

the NUMERIX env var?

I can't think of any reason here. What I'd use the env var for is
probably better handled by the command line option anyway.

If no one objects, I'll rip this stuff out and update the module
docstring as Eric suggested.

Todd

···

On Thu, 2004-06-10 at 09:57, John Hunter wrote:

3

John,

Compiling with numarray improved the pcolor_demo2 times by about a factor of 3 when selecting numarray via numerix, although it is still a little slower on my machine than Numeric-linkage/Numeric Python. No big deal. I am sticking with numarray.

Eric

···

The NUMERIX variable in setup.py determines which library the
extension code is compiled against. Whether you use numeric or
numarray, it will work with either, but you should get much better
performance if you match this compile flag to the library you use
most.

Let us know if this is indeed the cause of the performance hit. Here
are my numbers (best of three runs)