bug in numerix?

Hi,

I think there are a bug in numerix. I was expecting the same result from
pylab.where and numpy.where (in my matplotlibrc I have numerix define for
numpy) but like you can see in the following example the result is quite
different.

N.

Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
Type "copyright", "credits" or "license" for more information.

IPython 0.7.3.svn -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

  Welcome to pylab, a matplotlib-based Python environment.
  For more information, type 'help(pylab)'.

In [1]: import numpy

In [2]: a = numpy.arange(123)

In [3]: pylab.where(a>23)

···

---------------------------------------------------------------------------
exceptions.TypeError Traceback (most recent
call last)

/home/humufr/<ipython console>

TypeError: where() takes exactly 3 arguments (1 given)

In [4]: from matplotlib import rcParams

In [5]: rcPara
rcParams rcParamsDefault

In [5]: rcParams['numerix']
Out[5]: 'numpy'

In [6]: numpy.where(a>23)
Out[6]:
(array([ 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,
        37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
        50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62,
        63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75,
        76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
        89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101,
       102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114,
       115, 116, 117, 118, 119, 120, 121, 122]),)

It is not a bug in numerix; numerix is using an older version of where, provided by numpy for compatibility with Numeric:

In [4]:numpy.where?
Type: builtin_function_or_method
Base Class: <type 'builtin_function_or_method'>
String Form: <built-in function where>
Namespace: Interactive
Docstring:
     where(condition, | x, y)

     The result is shaped like condition and has elements of x and y where
     condition is respectively true or false. If x or y are not given,
     then it is equivalent to condition.nonzero().

     To group the indices by element, rather than dimension, use

         transpose(where(condition, | x, y))

     instead. This always results in a 2d array, with a row of indices for
     each element that satisfies the condition.

In [5]:pylab.where?
Type: function
Base Class: <type 'function'>
String Form: <function where at 0xb6e2a924>
Namespace: Interactive
File: /usr/lib/python2.4/site-packages/numpy/oldnumeric/functions.py
Definition: pylab.where(condition, x, y)
Docstring:
     <no docstring>

Eric

humufr@...136... wrote:

···

Hi,

I think there are a bug in numerix. I was expecting the same result from pylab.where and numpy.where (in my matplotlibrc I have numerix define for numpy) but like you can see in the following example the result is quite different.

N.

Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
Type "copyright", "credits" or "license" for more information.

IPython 0.7.3.svn -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

  Welcome to pylab, a matplotlib-based Python environment.
  For more information, type 'help(pylab)'.

In [1]: import numpy

In [2]: a = numpy.arange(123)

In [3]: pylab.where(a>23)
---------------------------------------------------------------------------
exceptions.TypeError Traceback (most recent call last)

/home/humufr/<ipython console>

TypeError: where() takes exactly 3 arguments (1 given)

In [4]: from matplotlib import rcParams

In [5]: rcPara
rcParams rcParamsDefault

In [5]: rcParams['numerix']
Out[5]: 'numpy'

In [6]: numpy.where(a>23)
Out[6]:
(array([ 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,
        37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
        50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62,
        63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75,
        76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
        89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101,
       102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114,
       115, 116, 117, 118, 119, 120, 121, 122]),)

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

But why the compatibility function is used? Not the new one from numpy? I
didn't ask for a Numeric compatibility?
I don't understand the need to have the Numeric function when I'm using numpy.
I think this is a bad "feature" perhaps not a bug but not the thing that the
majority of people would like. In my opinion, if numerix is define to be
numpy, all the function from numpy must be the default ones. In other hand
that will confuse plenty of people.
Now I understand that I have to avoid all numerix function. The problem is
that I love to use ipython -pylab and so I have to be more careful when I'm
doing fast plot...

N.

···

Le mardi 26 septembre 2006 14:00, Eric Firing a écrit :

It is not a bug in numerix; numerix is using an older version of where,
provided by numpy for compatibility with Numeric:

In [4]:numpy.where?
Type: builtin_function_or_method
Base Class: <type 'builtin_function_or_method'>
String Form: <built-in function where>
Namespace: Interactive
Docstring:
     where(condition, | x, y)

     The result is shaped like condition and has elements of x and y where
     condition is respectively true or false. If x or y are not given,
     then it is equivalent to condition.nonzero().

     To group the indices by element, rather than dimension, use

         transpose(where(condition, | x, y))

     instead. This always results in a 2d array, with a row of indices for
     each element that satisfies the condition.

In [5]:pylab.where?
Type: function
Base Class: <type 'function'>
String Form: <function where at 0xb6e2a924>
Namespace: Interactive
File:
/usr/lib/python2.4/site-packages/numpy/oldnumeric/functions.py
Definition: pylab.where(condition, x, y)
Docstring:
     <no docstring>

Eric

humufr@...136... wrote:
> Hi,
>
> I think there are a bug in numerix. I was expecting the same result from
> pylab.where and numpy.where (in my matplotlibrc I have numerix define
> for numpy) but like you can see in the following example the result is
> quite different.
>
> N.
>
>
>
>
> Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.7.3.svn -- An enhanced Interactive Python.
> ? -> Introduction to IPython's features.
> %magic -> Information about IPython's 'magic' % functions.
> help -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
>
> Welcome to pylab, a matplotlib-based Python environment.
> For more information, type 'help(pylab)'.
>
> In [1]: import numpy
>
> In [2]: a = numpy.arange(123)
>
> In [3]: pylab.where(a>23)
> -------------------------------------------------------------------------
>-- exceptions.TypeError Traceback (most
> recent call last)
>
> /home/humufr/<ipython console>
>
> TypeError: where() takes exactly 3 arguments (1 given)
>
> In [4]: from matplotlib import rcParams
>
> In [5]: rcPara
> rcParams rcParamsDefault
>
> In [5]: rcParams['numerix']
> Out[5]: 'numpy'
>
> In [6]: numpy.where(a>23)
> Out[6]:
> (array([ 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,
> 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
> 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62,
> 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75,
> 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
> 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101,
> 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114,
> 115, 116, 117, 118, 119, 120, 121, 122]),)
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

humufr@...136... wrote:

But why the compatibility function is used? Not the new one from numpy? I didn't ask for a Numeric compatibility?
I don't understand the need to have the Numeric function when I'm using numpy.

The numerix layer is also used internally by matplotlib such that it does not need to have three different implementations to support the three array packages. It serves to be a uniform layer over the three packages, not just serve as a common place to get array functions from. That it is also exposed by importing everything from pylab is a side effect. If you don't want this, then you can configure ipython to import everything you want from numpy *after* pylab.

···

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco