Re: [Numpy-discussion] location of ma in maskedarray branch
Hi Matt On Tue, Jan 22, 2008 at 10:37:29PM -0500, Matt Knox wrote: I noticed that the new masked array module resides in numpy/ma in the maskedarray branch as opposed to numpy/core/ma like it does in the current trunk. Was this intentional? Code that explicitly imports ma from the core subfolder will break from this change (like the __init__.py script for the ma subfolder in matplotlib for example). Yes, the move was intentional and was discussed beforehand. I may be mistaken, but as far as I know numpy.core is not a public API, so code should rather do from numpy import ma (that works with both the current trunk and the maskedarray branch). Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to build on Solaris 10 (x86) using sunperf?
On Jan 23, 2008 12:32 PM, David Cournapeau [EMAIL PROTECTED] wrote: The current config.h works fine for solaris with Sun compilers, in my experience, so the problem must be somewhere else. I've just tried numpy SVN with sun compiler (Sun studio 12) on Indiana, and it works fine, so there is no recent regressions on this. The problem may be because of opteron (64 bits). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] data type specifications
On Jan 23, 2008 2:48 AM, Stefan van der Walt [EMAIL PROTECTED] wrote: Hi Gary On Tue, Jan 22, 2008 at 11:18:01AM -0500, Gary Pajer wrote: Occasionally I find myself poking into docstrings and googling randomly trying to find the proper way to specify a data type, or trying to remind myself just what a float is. I can never find the info easily. Preferable: Is there a docstring somewhere that lists the data types and acceptable ways to specify them? Less Preferable: Is there a web page? This should be a good starting place (search for dtype): http://www.scipy.org/Numpy_Example_List Thanks, Stéfan. That link led me to the numpy dictionary numpy.typeDict which lists them all. -gary Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Docstring standard: how to specify variable types
Hi all,
The numpy documentation standard example shows:
Parameters
--
var1 : array_like
Array_like means all those objects -- lists, nested lists, etc. --
that can be converted to an array.
var2 : integer
Write out the full type
long_variable_name : {'hi', 'ho'}, optional
Choices in brackets, default first when optional.
I'd like to know:
1. array_like describes objects that can be forced to quack like
ndarrays. Are there any other such special descriptions?
2. How do we specify default values?
3. Why do we need the optional keyword (the function signature
already indicates that the parameter is optional).
4. Do we really need the Other Parameters list? It would make more
sense to split positional and keyword arguments, but I'm not even
sure that is necessary, since that information is already specified in the
function signature.
5. Is the {'hi', 'ho'} syntax used when a parameter can only assume a
limited number of values? In Python {} is a dictionary, so why not
use ('hi','ho') instead?
Thanks for your feedback!
Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] [ANN] numscons 0.3.0 release
Hi, I've just released the 0.3.0 release of numscons, an alternative build system for numpy. The tarballs are available on launchpad. https://launchpad.net/numpy.scons.support/0.3/0.3.0 To use it, you need to get the build_with_scons numpy branch: see http://projects.scipy.org/scipy/numpy/wiki/NumpyScons for more details. This release is an important milestone: - all regressions because of the split from numpy are fixed. - it can build numpy on linux (gcc/intel), mac os X (gcc), windows (mingw) and solaris (Sun compilers). - mkl, sunperf, accelerate/vecLib frameworks and ATLAS should work on the platforms where it makes sense. - a lot of internal changes: some basic unittest, a total revamp of the code to check for performance libraries. - almost all changes necessary to scons code are now included upstream, or pending review. If you test it and has problems building numpy, please submit a bug to launchpad: https://bugs.launchpad.net/numpy.scons.support/0.3/ Thanks, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Docstring standard: how to specify variable types
On Jan 23, 2008 6:55 AM, Stefan van der Walt [EMAIL PROTECTED] wrote:
Hi all,
The numpy documentation standard example shows:
Parameters
--
var1 : array_like
Array_like means all those objects -- lists, nested lists, etc. --
that can be converted to an array.
var2 : integer
Write out the full type
long_variable_name : {'hi', 'ho'}, optional
Choices in brackets, default first when optional.
I'd like to know:
1. array_like describes objects that can be forced to quack like
ndarrays. Are there any other such special descriptions?
I can't think of any, but that doesn't mean there aren't any.
2. How do we specify default values?
I like to put them first in the list: {-1, integer}
3. Why do we need the optional keyword (the function signature
already indicates that the parameter is optional).
It's extra information, true, but that isn't always a bad thing. It's like
looking up whole numbers in a book index and, instead of the page
reference, the index directs you to numbers, whole. Flip, flip, flip.
Drives me crazy. Besides, the function signature might be missing.
4. Do we really need the Other Parameters list? It would make more
sense to split positional and keyword arguments, but I'm not even
sure that is necessary, since that information is already specified in
the
function signature.
I agree, but Travis likes this section and I don't feel strongly about it.
5. Is the {'hi', 'ho'} syntax used when a parameter can only assume a
limited number of values? In Python {} is a dictionary, so why not
use ('hi','ho') instead?
Either would be fine. IIRC, the {} was inherited from epydoc consolidated
fields.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] changed behavior of numpy.histogram
Greetings: I just noticed a changed behavior of numpy.histogram. I
think that a recent 'fix' to the code has changed my ability to use that
function (albeit in an unconventional manner). I previously used the
histogram function to obtain counts of each unique string within a
string array. Again, I recognize that it is not a typical use of the
histogram function, but it did work very nicely for me.
Here's an example:
###numpy 1.0.3 --works just fine
import numpy
numpy.__version__
'1.0.3'
a=numpy.array(('atcg', 'atcg', '', ''))
a
array(['atcg', 'atcg', '', ''],
dtype='|S4')
b=numpy.unique(a)
numpy.histogram(a,b)
(array([2, 2]), array(['', 'atcg'],
dtype='|S4'))
###numpy 1.0.4 --no longer functions
import numpy
numpy.__version__
'1.0.4'
a=numpy.array(('atcg', 'atcg', '', ''))
a
array(['atcg', 'atcg', '', ''],
dtype='|S4')
b=numpy.unique(a)
numpy.histogram(a,b)
Traceback (most recent call last):
File stdin, line 1, in module
File
/opt/libraries/python/python-2.5.1/numpy-1.0.4-gnu/lib/python2.5/site-packages/numpy/lib/function_base.py,
line 154, in histogram
if(any(bins[1:]-bins[:-1] 0)):
TypeError: unsupported operand type(s) for -: 'numpy.ndarray' and
'numpy.ndarray'
Is this something that can possibly be fixed (should I submit a ticket)?
Or should I revert to some other approaches for implementing the same
idea? It really was a nice convenience. Or, alternately, would some
sort of new function along the lines of a numpy.countunique() ultimately
be useful?
Thanks,
-Mark
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] changed behavior of numpy.histogram
Hi -- Greetings: I just noticed a changed behavior of numpy.histogram. I think that a recent 'fix' to the code has changed my ability to use that function (albeit in an unconventional manner). You can blame me for this. I submitted a patch which prohibited the user from entering any range into histogram other than a monotonically increasing one. The ticket with the info is: http://scipy.org/scipy/numpy/ticket/586 This patch was apparently applied by the NumPy folks, and it broke your code. Sorry! Is this something that can possibly be fixed (should I submit a ticket)? Or should I revert to some other approaches for implementing the same idea? It really was a nice convenience. Or, alternately, would some sort of new function along the lines of a numpy.countunique() ultimately be useful? IMO, your use was invalid (albeit a cute and useful shortcut). Allowing non-monotonically increasing bins can lead to confusing or inexplicable results. On the other hand, I would support the idea of a new function numpy.countunique() as you suggest. Just my two cents... Stuart Brorson Interactive Supercomputing, inc. 135 Beaver Street | Waltham | MA | 02452 | USA http://www.interactivesupercomputing.com/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] changed behavior of numpy.histogram
Hi again --
You made me feel guilty about breaking your code. Here's some
suggested substitute code :
In [10]: import numpy
In [11]: a = numpy.array(('atcg', '', 'atcg', 'actg', ''))
In [12]: b = numpy.sort(a)
In [13]: c = numpy.unique(b)
In [14]: d = numpy.searchsorted(b, c)
In [15]: e = numpy.append(d[1:], len(a))
In [16]: f = e - d
In [17]:
In [17]: print c
['' 'actg' 'atcg']
In [18]: print f
[2 1 2]
Note that histogram also uses searchsorted to do its stuff.
Personally, I think the way to go is have a countunique function
which returns a list of unique occurrances of the array elements
(regardless of their type), and a list of their count. The above code
could be a basis for this fcn.
I'm not sure that this should be implemented using histogram, since
at least I ordinarily consider histogram as a numeric function.
Others may have different opinions.
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
On Wed, 23 Jan 2008, Mark.Miller wrote:
Greetings: I just noticed a changed behavior of numpy.histogram. I
think that a recent 'fix' to the code has changed my ability to use that
function (albeit in an unconventional manner). I previously used the
histogram function to obtain counts of each unique string within a
string array. Again, I recognize that it is not a typical use of the
histogram function, but it did work very nicely for me.
Here's an example:
###numpy 1.0.3 --works just fine
import numpy
numpy.__version__
'1.0.3'
a=numpy.array(('atcg', 'atcg', '', ''))
a
array(['atcg', 'atcg', '', ''],
dtype='|S4')
b=numpy.unique(a)
numpy.histogram(a,b)
(array([2, 2]), array(['', 'atcg'],
dtype='|S4'))
###numpy 1.0.4 --no longer functions
import numpy
numpy.__version__
'1.0.4'
a=numpy.array(('atcg', 'atcg', '', ''))
a
array(['atcg', 'atcg', '', ''],
dtype='|S4')
b=numpy.unique(a)
numpy.histogram(a,b)
Traceback (most recent call last):
File stdin, line 1, in module
File
/opt/libraries/python/python-2.5.1/numpy-1.0.4-gnu/lib/python2.5/site-packages/numpy/lib/function_base.py,
line 154, in histogram
if(any(bins[1:]-bins[:-1] 0)):
TypeError: unsupported operand type(s) for -: 'numpy.ndarray' and
'numpy.ndarray'
Is this something that can possibly be fixed (should I submit a ticket)?
Or should I revert to some other approaches for implementing the same
idea? It really was a nice convenience. Or, alternately, would some
sort of new function along the lines of a numpy.countunique() ultimately
be useful?
Thanks,
-Mark
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] changed behavior of numpy.histogram
Nah...no worries Stuart. Again, I recognize that what I was doing
deviated from the likely true intent of the histogram function. But it
was a nice convenient bit of code, for sure.
I'll take a look at your suggestion...it's different than what I
previously used. So, thanks for the input.
And yes...your description of a countunique() function is precisely what
I had in mind. Might be very useful if it could also work on object arrays.
Thanks again,
-Mark
Stuart Brorson wrote:
Hi again --
You made me feel guilty about breaking your code. Here's some
suggested substitute code :
In [10]: import numpy
In [11]: a = numpy.array(('atcg', '', 'atcg', 'actg', ''))
In [12]: b = numpy.sort(a)
In [13]: c = numpy.unique(b)
In [14]: d = numpy.searchsorted(b, c)
In [15]: e = numpy.append(d[1:], len(a))
In [16]: f = e - d
In [17]:
In [17]: print c
['' 'actg' 'atcg']
In [18]: print f
[2 1 2]
Note that histogram also uses searchsorted to do its stuff.
Personally, I think the way to go is have a countunique function
which returns a list of unique occurrances of the array elements
(regardless of their type), and a list of their count. The above code
could be a basis for this fcn.
I'm not sure that this should be implemented using histogram, since
at least I ordinarily consider histogram as a numeric function.
Others may have different opinions.
Cheers,
Stuart Brorson
Interactive Supercomputing, inc.
135 Beaver Street | Waltham | MA | 02452 | USA
http://www.interactivesupercomputing.com/
On Wed, 23 Jan 2008, Mark.Miller wrote:
Greetings: I just noticed a changed behavior of numpy.histogram. I
think that a recent 'fix' to the code has changed my ability to use that
function (albeit in an unconventional manner). I previously used the
histogram function to obtain counts of each unique string within a
string array. Again, I recognize that it is not a typical use of the
histogram function, but it did work very nicely for me.
Here's an example:
###numpy 1.0.3 --works just fine
import numpy
numpy.__version__
'1.0.3'
a=numpy.array(('atcg', 'atcg', '', ''))
a
array(['atcg', 'atcg', '', ''],
dtype='|S4')
b=numpy.unique(a)
numpy.histogram(a,b)
(array([2, 2]), array(['', 'atcg'],
dtype='|S4'))
###numpy 1.0.4 --no longer functions
import numpy
numpy.__version__
'1.0.4'
a=numpy.array(('atcg', 'atcg', '', ''))
a
array(['atcg', 'atcg', '', ''],
dtype='|S4')
b=numpy.unique(a)
numpy.histogram(a,b)
Traceback (most recent call last):
File stdin, line 1, in module
File
/opt/libraries/python/python-2.5.1/numpy-1.0.4-gnu/lib/python2.5/site-packages/numpy/lib/function_base.py,
line 154, in histogram
if(any(bins[1:]-bins[:-1] 0)):
TypeError: unsupported operand type(s) for -: 'numpy.ndarray' and
'numpy.ndarray'
Is this something that can possibly be fixed (should I submit a ticket)?
Or should I revert to some other approaches for implementing the same
idea? It really was a nice convenience. Or, alternately, would some
sort of new function along the lines of a numpy.countunique() ultimately
be useful?
Thanks,
-Mark
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to build on Solaris 10 (x86) using sunperf?
David Cournapeau wrote: The current config.h works fine for solaris with Sun compilers, in my experience, so the problem must be somewhere else. Peter, could you post the errors you got ? As an alternative, I am working on an alternative build system for numpy: it should work on solaris (tested on Indiana, and other people reported success on solaris 9 and 10). Unfortunately, I have been redesigning the internals quite a lot lately, and I have not tested the changes on solaris yet. If you are willing to test, it should be easy for me to make it work again on solaris in a few minutes, though. The problems I was having were due to a bad site.cfg initially and then a problem with the python pkg from sunfreeware (ctypes version mismatch). Numpy is now happily installed. If you need someone to test anything new, let me know. Thanks! Pete ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Sage/Scipy Days 8 reminder: Feb 29-March 4.
Fernando Perez wrote: Just a quick reminder for all about the upcoming Sage/Scipy Days 8 at Enthought collaborative meeting: http://wiki.sagemath.org/days8 This page says February 29 until March 4, *2007*. -- Sincerely, Chris Calloway http://www.seacoos.org office: 332 Chapman Hall phone: (919) 962-4323 mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] __array_interface__ / __array_struct__
Travis E. Oliphant schrieb: Thomas Heller wrote: Travis E. Oliphant schrieb: Thomas Heller wrote: I am experimenting with implementing __array_interface__ and/or __array_struct__ properties for ctypes instances, and have problems to create numpy arrays from them that share the memory. Probably I'm doing something wrong; what is the correct function in numpy to create these shared objects? I am using numpy.core.multiarray.array(ctypes-object), is that correct? Yes, this should work, as the array function goes through several checks including looking for the __array_struct__ and/or __array_interface__ attributes.If you can point me to the code, I can probably help. The pure-python code, using __array_interface__, is here: http://ctypes-stuff.googlecode.com/svn/trunk/numpy/ This is all very good. The only thing missing that causes the former to not share memory is you are missing a copy=False argument to the multi_array function. Thus: return multi_array(obj, copy=0) is what you need to use. Cool! Thanks for that, it works now ;-). Also, the address of the memory is also available as arr.ctypes.data if arr is a NumPy array (but this is less general than using the array interface for sure). I'm not completely sure what you are suggesting here; I just use all the info in the numpy array's __array_interface__ property to find the ctypes type to construct. And the address also is available in this property. Thanks, Thomas ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.ma.compress
Pierre, numpy.compress exists, but numpy.ma.compress does not; is this intentional? Eric ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.ma.compress
On Wed, Jan 23, 2008 at 11:17:51AM -1000, Eric Firing wrote: Pierre, numpy.compress exists, but numpy.ma.compress does not; is this intentional? Looks like x.compress exists, but it doesn't work as expected: x = N.ma.array([1,2,3],mask=[True,False,Fals]) x.compress(x2) throws ValueError: total size of new array must be unchanged Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.ma.compress
Hi Eric, On Wed, Jan 23, 2008 at 11:17:51AM -1000, Eric Firing wrote: Pierre, numpy.compress exists, but numpy.ma.compress does not; is this intentional? Thanks for the report. I added a simple implementation to SVN for the time being. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.ma.compress
Pierre GM wrote: On Wednesday 23 January 2008 16:17:51 you wrote: Pierre, numpy.compress exists, but numpy.ma.compress does not; is this intentional? Probably not. I usually don't use this function, preferring to use indexing instead. If you have a need for it, I can probably come up with something relatively soon: the basis would be to apply compress first on the ._data part, return a view with the same class as the original object, and update the mask with compress as needed. The only reason to add it would be backwards compatibility. Evidently it exists in original numpy.ma. Mike D used it in mpl's path.py until today when someone pointed out that it did not work with the maskedarray branch. (I think I tripped over the same thing a couple days ago, but worked around it at a higher level.) I agree that it is better *not* to use it, and we can easily strip it out of mpl if it occurs anywhere else; but there may be other user code that will trip over its absence when 1.05 comes out, so it might be easier to put it in, preserving similarity to numpy as well as old numpy.ma, than to leave it out and have to field future questions about it. Eric ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] planet.scipy.org
thanks. On Jan 22, 2008 10:04 PM, Jarrod Millman [EMAIL PROTECTED] wrote: On Jan 18, 2008 11:17 PM, Barry Wark [EMAIL PROTECTED] wrote: I promise: last change. I changed the URL to http://physionconsulting.blogspot.com/search/label/scipy. My wife said physion consultants is a crappy name. Oh well :) Done. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.ma.compress
On Wednesday 23 January 2008 17:05:25 Stefan van der Walt wrote: On Wed, Jan 23, 2008 at 11:17:51AM -1000, Eric Firing wrote: Pierre, numpy.compress exists, but numpy.ma.compress does not; is this intentional? Looks like x.compress exists, but it doesn't work as expected: x = N.ma.array([1,2,3],mask=[True,False,Fals]) x.compress(x2) throws ValueError: total size of new array must be unchanged Hardly a surprise: .compress is inherited from ndarray, and doesn't know how to handle the mask. We end up with a mask that doesn't have the size of the data, hence the ValueError. Stefan's modification should work for now. I'm working on a version closer to the numpy original (that accepts the other arguments as well), I'll try to commit it later tonight. Thanks again for your help ! ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] where() on mac/pc return different things
Hi, numpy.where() returns different things on my windowsXP machine than on my collaborator's mac osx machine. For example, consider: import numpy a = numpy.array([1,2,3,4]) b = numpy.where( a 2 ) On WindowsXP (python 2.4.2, numpy 1.0.1), I get: print b (array([2, 3]), ) print b[0] [2 3] While in OSX (python 2.4.3, numpy 0.9.6), he gets: print b [2, 3] print b[0] 2 This matters because we use where() to get indices to loop over. On the mac you can then loop through the b array: for item in b: if b 5: print 'hi' But this approach fails on a pc because: if b 5: ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() I'd like to avoid having to do: if mac: b = numpy.where( a 5) if pc: b = numpy.where( a 5)[0] Has anybody else notice dealt with this? Is this a mac/pc difference or a numpy 1.01 vs. numpy 0.9.6 difference? Thanks for the help, James ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] where() on mac/pc return different things
Robert, Thanks for solving that puzzle! I'll get our group on the same 1.0.x numpy release. Take care, James ** Harvard University Dept. of Astronomy 60 Garden Street MS-10 Cambridge, MA 02138 phone 617.496.5988 lab 617.495.3267 email [EMAIL PROTECTED] web http://www.cfa.harvard.edu/~jbattat ** On Wed, 23 Jan 2008, Robert Kern wrote: James Battat wrote: Hi, numpy.where() returns different things on my windowsXP machine than on my collaborator's mac osx machine. For example, consider: import numpy a = numpy.array([1,2,3,4]) b = numpy.where( a 2 ) On WindowsXP (python 2.4.2, numpy 1.0.1), I get: print b (array([2, 3]), ) print b[0] [2 3] While in OSX (python 2.4.3, numpy 0.9.6), he gets: print b [2, 3] print b[0] 2 This matters because we use where() to get indices to loop over. On the mac you can then loop through the b array: for item in b: if b 5: print 'hi' But this approach fails on a pc because: if b 5: ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() I'd like to avoid having to do: if mac: b = numpy.where( a 5) if pc: b = numpy.where( a 5)[0] Has anybody else notice dealt with this? Is this a mac/pc difference or a numpy 1.01 vs. numpy 0.9.6 difference? The latter. Before the 1.0 release, we tried to make it clear that we were still experimenting with the APIs and that they might change up until 1.0 got released. -- 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.ma.compress
All, I just committed a fix on the SVN. Now, the axis keyword should be recognized. Sorry for the delay. Pierre ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
