Re: [Numpy-discussion] fast access and normalizing of ndarray slices
Hi, On Mon, Jun 4, 2012 at 12:44 AM, srean srean.l...@gmail.com wrote: Hi Wolfgang, I think you are looking for reduceat( ), in particular add.reduceat() Indeed OP could utilize add.reduceat(...), like: # tst.py import numpy as np def reduce(data, lengths): ind, ends= np.r_[lengths, lengths], lengths.cumsum() ind[::2], ind[1::2]= ends- lengths, ends return np.add.reduceat(np.r_[data, 0], ind)[::2] def normalize(data, lengths): return data/ np.repeat(reduce(data, lengths), lengths) def gen(par): lengths= np.random.randint(*par) return np.random.randn(lengths.sum()), lengths if __name__ == '__main__': data= np.array([1, 2, 1, 2, 3, 4, 1, 2, 3], dtype= float) lengths= np.array([2, 4, 3]) print reduce(data, lengths) print normalize(data, lengths).round(2) Resulting: In []: %run tst [ 3. 10. 6.] [ 0.33 0.67 0.1 0.2 0.3 0.4 0.17 0.33 0.5 ] Fast enough: In []: data, lengths= gen([5, 15, 5e4]) In []: data.size Out[]: 476028 In []: %timeit normalize(data, lengths) 10 loops, best of 3: 29.4 ms per loop My 2 cents, -eat -- srean On Thu, May 31, 2012 at 12:36 AM, Wolfgang Kerzendorf wkerzend...@gmail.com wrote: Dear all, I have an ndarray which consists of many arrays stacked behind each other (only conceptually, in truth it's a normal 1d float64 array). I have a second array which tells me the start of the individual data sets in the 1d float64 array and another one which tells me the length. Example: data_array = (conceptually) [[1,2], [1,2,3,4], [1,2,3]] = in reality [1,2,1,2,3,4,1,2,3, dtype=float64] start_pointer = [0, 2, 6] length_data = [2, 4, 3] I now want to normalize each of the individual data sets. I wrote a simple for loop over the start_pointer and length data grabbed the data and normalized it and wrote it back to the big array. That's slow. Is there an elegant numpy way to do that? Do I have to go the cython way? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] better error message possible?
On Fri, Jun 1, 2012 at 6:56 PM, Chris Withers ch...@simplistix.co.uk wrote: On 01/06/2012 16:39, Benjamin Root wrote: import numpy numpy.zeros(10)[-123] Traceback (most recent call last): File stdin, line 1, in module IndexError: index out of bounds ...could say this: numpy.zeros(10)[-123] Traceback (most recent call last): File stdin, line 1, in module IndexError: -123 is out of bounds Only that no-one has implemented it, I guess. If you want to then that'd be cool :-). To be generally useful for debugging, it would probably be good for the error message to also mention which dimension is involved, and/or the actual size of the array in that dimension. You can also get such error messages from expressions like 'arr[i, j, k]', after all, where it's even less obvious what went wrong. -- Nathaniel +1, please! Indeed, sadly I'm not a C developer. It's a pet bugbear of mine that Python's built-in exceptions often tell you what went wrong but not what data caused the error, even when it's easily to hand when raising the exception. I could look into this. There are only ~10 places the code generates this error, so it should be a pretty minor change. Ray Jones ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] better error message possible?
On 4. juni 2012, at 16:27, Thouis (Ray) Jones wrote: On Fri, Jun 1, 2012 at 6:56 PM, Chris Withers ch...@simplistix.co.uk wrote: On 01/06/2012 16:39, Benjamin Root wrote: import numpy numpy.zeros(10)[-123] Traceback (most recent call last): File stdin, line 1, in module IndexError: index out of bounds ...could say this: numpy.zeros(10)[-123] Traceback (most recent call last): File stdin, line 1, in module IndexError: -123 is out of bounds Only that no-one has implemented it, I guess. If you want to then that'd be cool :-). To be generally useful for debugging, it would probably be good for the error message to also mention which dimension is involved, and/or the actual size of the array in that dimension. You can also get such error messages from expressions like 'arr[i, j, k]', after all, where it's even less obvious what went wrong. -- Nathaniel +1, please! Indeed, sadly I'm not a C developer. It's a pet bugbear of mine that Python's built-in exceptions often tell you what went wrong but not what data caused the error, even when it's easily to hand when raising the exception. I could look into this. There are only ~10 places the code generates this error, so it should be a pretty minor change. Ray Jones Isn't it useful even if you change it in just one of those locations? Better to have the information available when you can, than to never have it. Paul ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, The issue tracking discussion seems to have died. Since github issues looks to be a viable alternative at this point, I propose to turn it on for the numpy repository and start directing people in that direction. Thoughts? Sounds good, as long as we don't create duplicates or do something to make the conversion from Trac harder. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Mon, Jun 4, 2012 at 9:34 AM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, The issue tracking discussion seems to have died. Since github issues looks to be a viable alternative at this point, I propose to turn it on for the numpy repository and start directing people in that direction. Thoughts? Sounds good, as long as we don't create duplicates or do something to make the conversion from Trac harder. I looked into this a bit, and it looks like the first task is to set up labels. They should probably track what we currently have for trac in order to make moving some (all?) of the tickets over. I'm thinking component, priority, type, milestone, and version, omitting the keywords. I'm not sure how we should handle attachments. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to remove any row or column of a numpy matrix whose sum is 3?
On Mon, Jun 4, 2012 at 5:21 PM, bob tnur bobtnu...@gmail.com wrote: Hello every body. I am new to python. How to remove any row or column of a numpy matrix whose sum is 3. To obtain and save new matrix P with (sum(anyrow)!=3 and sum(anycolumn)!=3 elements. I tried like this: P = M[np.logical_not( (M[n,:].sum()==3) (M[:,n].sum()==3))] or P = M[np.logical_not( (np.sum(M[n,:])==3) (np.sum(M[:,n])==3))] M is the nxn numpy matrix. But I got indexerror. So can anyone correct this or any other elegant way of doing this? If M is 5x5 matrix, then M[5,:] and M[:,5] don't work. You can't index past the last element. Python sequences in general and numpy arrays in particular use 0-based indexing. I'm not entirely sure what you intended with those expressions anyways. Here is how I would do it. # Get the integer indices of the rows that sum up to 3 # and the columns that sum up to 3. bad_rows = np.nonzero(M.sum(axis=1) == 3) bad_cols = np.nonzero(M.sum(axis=0) == 3) # Now use the numpy.delete() function to get the matrix # with those rows and columns removed from the original matrix. P = np.delete(M, bad_rows, axis=0) P = np.delete(P, bad_cols, axis=1) -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to remove any row or column of a numpy matrix whose sum is 3?
On Mon, Jun 4, 2012 at 9:21 AM, bob tnur bobtnu...@gmail.com wrote: Hello every body. I am new to python. How to remove any row or column of a numpy matrix whose sum is 3. To obtain and save new matrix P with (sum(anyrow)!=3 and sum(anycolumn)!=3 elements. well, one question is -- do you want to remove the particular rows first, then remove the particular columns, or compute the sums of both with all in place, then remove rows and columns -- but some ideas: In [357]: m Out[357]: array([[ 1., 1., 1., 1., 0.], [ 1., 0., 1., 1., 1.], [ 1., 1., 1., 0., 0.], [ 1., 1., 1., 1., 1.]]) # which rows, columns sum to 3? In [363]: rows_3 = np.argwhere(m.sum(axis=1) == 3) In [364]: rows_3 Out[364]: array([[2]]) In [365]: cols_3 = np.argwhere(m.sum(axis=0) == 3) In [366]: cols_3 Out[366]: array([[1], [3]]) # but it's probably easier to know which do not sum to 3: In [367]: rows_3 = np.argwhere(m.sum(axis=1) != 3) In [368]: rows_3 Out[368]: array([[0], [1], [3]]) In [371]: cols_3 = np.argwhere(m.sum(axis=0) != 3) In [372]: cols_3 Out[372]: array([[0], [2], [4]]) now build the new array: m2 = In [415]: m2 = m[rows_3[:,0]][:, cols_3[:,0]] In [416]: m2 Out[416]: array([[ 1., 1., 0.], [ 1., 1., 1.], [ 1., 1., 1.]]) some trickery there: the [:,2] index is because argwhere() returns a 2-d (nXm)array of indexes -- where m is the rank of the input array -- in this case one, so we want the single column (it's done this way so you can do: arr[ argwhere(arr == something) ] for n-dim arrays I also found I need to pull out the rows first, then the columns, because: arr[a_1, a_2] is interpreted as two arrays of individual indexes, not as indexes to the roes an columsn, i.e.: In [428]: arr Out[428]: array([[ 0, 1, 2, 3], [ 4, 5, 6, 7], [ 8, 9, 10, 11]]) In [430]: arr[(1,2), (2,3)] Out[430]: array([ 6, 11]) you got the elements at: (1,2) and (2,3) There may be a way to do that a bit cleaner -- it escapes me at the moment. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 1D array sorting ascending and descending by fields
Hi! I have a one-dimensional ndarray with two fields. I'd like to sort in descending order by field 'a', breaking ties by sorting in ascending order by field 'b'. I've found combinations of sorting and reversing followed by stable sorting that work, but there must be a straightforward way to do it. Your help is appreciated! Thank you, Patrick ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
There is an interesting project called http://huboard.com/The projects suggests using a few Column Labels that provides a nice card-based window onto the Github issues. I have turned on issue tracking and started a few labels. Feel free to add more / adjust the names as appropriate. I am trying to find someone who can help manage the migration from Trac. I have two people but they are both quite inexperienced, and it will take them some time to learn the process. If anyone out there is in a position to spend a month, there are resources available to do the migration. I think this is ideal for someone just getting started in the NumPy community who knows something about web-apis and data-bases (or is eager to learn). Best, -Travis On Jun 4, 2012, at 11:40 AM, Ralf Gommers wrote: On Mon, Jun 4, 2012 at 6:05 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Jun 4, 2012 at 9:34 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, The issue tracking discussion seems to have died. Since github issues looks to be a viable alternative at this point, I propose to turn it on for the numpy repository and start directing people in that direction. Thoughts? Sounds good, as long as we don't create duplicates or do something to make the conversion from Trac harder. I looked into this a bit, and it looks like the first task is to set up labels. They should probably track what we currently have for trac in order to make moving some (all?) of the tickets over. I'm thinking component, priority, type, milestone, and version, omitting the keywords. I'm not sure how we should handle attachments. Version can be left out I think, unless someone finds it useful. We can think about extra labels too. I'd like easy-fix, as a guide for new contributors to issues to get started on. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1D array sorting ascending and descending by fields
Here's how I sorted primarily by field 'a' descending and secondarily by
field 'b' ascending:
(Note that 'a' is the second column, 'b' is the first)
data
array([('b', 0.03),
('c', 0.03),
('f', 0.03),
('e', 0.01),
('d', 0.04),
('a', 0.04)],
dtype=[('b', '|S32'), ('a', 'f8')])
data.sort(order='b') # sort by b
data = data[::-1] # reverse
data[numpy.argsort(data['a'])][::-1] # sort by a and reverse
array([('a', 0.04),
('d', 0.04),
('b', 0.03),
('c', 0.03),
('f', 0.03),
('e', 0.01)],
dtype=[('b', '|S32'), ('a', 'f8')])
My question is whether there's an easier way to do this. Originally I
thought it would be possible to just do:
data.sort(order=('-a', 'b'))
...indicating that the order of 'a' is descending, but this isn't part of
NumPy's sort behavior.
Your help is appreciated!
Thank you,
Patrick
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes in PyArray_FromAny between 1.5.x and 1.6.x
On Mon, May 28, 2012 at 3:15 AM, Mike Hansen mhan...@gmail.com wrote:
In trying to upgrade NumPy within Sage, we notices some differences in
behavior between 1.5 and 1.6. In particular, in 1.5, we have
sage: f = 0.5
sage: f.__array_interface__
{'typestr': '=f8'}
sage: numpy.array(f)
array(0.5)
sage: numpy.array(float(f))
array(0.5)
In 1.6, we get the following,
sage: f = 0.5
sage: f.__array_interface__
{'typestr': '=f8'}
sage: numpy.array(f)
array(0.500, dtype=object)
This seems to be do to the changes in PyArray_FromAny introduced in
https://github.com/mwhansen/numpy/commit/2635398db3f26529ce2aaea4028a8118844f3c48
. In particular, _array_find_type used to be used to query our
__array_interface__ attribute, and it no longer seems to work. Is
there a way to get the old behavior with the current code?
Any ideas?
Thanks,
--Mike
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy + SWIG
There are two types of swig problems that I was hoping to get some help with.
First, suppose I have some C function
void f(double *x, int nx, double *y, int ny);
where we input one array, and we output another array, both of which should be
the same size.
I have used in my .i file:
%apply(double *IN_ARRAY1, int DIM1){(double *x, int nx)}
%apply(double *ARGOUT_ARRAY1, int DIM1){(double *y, int ny)}
and this produces a workable function. However, it expects, as the functions
second argument, the length of the array x. Now, it's easy enough to call:
module.f(x, x.shape[0])
but is there a way to automatically get it to use the length of the array?
The second problem I have is for a function of the fomr
void g(double *x, int nx, double *y, int ny, double *z, int nz);
which evaluates some function g at all (x,y) pairs. The the thing is that nx
and ny need not be the same size, but nz should be nx * ny. I'd like to wrap
this too, and ideally it would also automatically handle the array lengths, but
I'd be happy to have anything right now. I'm also quite comfortable with the
idea of packing z as a column array and reshaping it as necessary.
-gideon
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] better error message possible?
On Mon, Jun 4, 2012 at 4:27 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Jun 1, 2012 at 6:56 PM, Chris Withers ch...@simplistix.co.uk wrote: On 01/06/2012 16:39, Benjamin Root wrote: import numpy numpy.zeros(10)[-123] Traceback (most recent call last): File stdin, line 1, in module IndexError: index out of bounds ...could say this: numpy.zeros(10)[-123] Traceback (most recent call last): File stdin, line 1, in module IndexError: -123 is out of bounds Only that no-one has implemented it, I guess. If you want to then that'd be cool :-). To be generally useful for debugging, it would probably be good for the error message to also mention which dimension is involved, and/or the actual size of the array in that dimension. You can also get such error messages from expressions like 'arr[i, j, k]', after all, where it's even less obvious what went wrong. -- Nathaniel +1, please! Indeed, sadly I'm not a C developer. It's a pet bugbear of mine that Python's built-in exceptions often tell you what went wrong but not what data caused the error, even when it's easily to hand when raising the exception. I could look into this. There are only ~10 places the code generates this error, so it should be a pretty minor change. My initial estimate was low, but not overly so. An initial pass at adding index/dimension information to IndexErrors is here: https://github.com/thouis/numpy/tree/index_error_info A typical result: numpy.zeros(3)[5] Traceback (most recent call last): File stdin, line 1, in module IndexError: index 5 out of bounds in dimension 0 I thought it best to have erroring indices report their initial value: numpy.zeros(3)[-15] Traceback (most recent call last): File stdin, line 1, in module IndexError: index -15 out of bounds in dimension 0 This is different from some places in the code where IndexErrors already had bad index and dimension information (including the maximum value possible for an index in that dimension). I left these alone, though most of them would report that the bad index was -12 instead of -15. For instance: https://github.com/thouis/numpy/blob/index_error_info/numpy/core/src/multiarray/mapping.c#L1640 Also there were a few indexing errors that were throwing ValueErrors. I changed these to IndexErrors. If someone could give this a cursory review before I issue a PR, I'd appreciate it. I don't expect that most of these code paths are heavily exercised in the tests (but I could be wrong). Ray Jones ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] better error message possible?
On Mon, Jun 4, 2012 at 10:00 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Mon, Jun 4, 2012 at 4:27 PM, Thouis (Ray) Jones tho...@gmail.com wrote: I could look into this. There are only ~10 places the code generates this error, so it should be a pretty minor change. My initial estimate was low, but not overly so. An initial pass at adding index/dimension information to IndexErrors is here: https://github.com/thouis/numpy/tree/index_error_info Fabulous! I made a few comments there, but also: A typical result: numpy.zeros(3)[5] Traceback (most recent call last): File stdin, line 1, in module IndexError: index 5 out of bounds in dimension 0 I would say for, not in. index 5 is a bit ambiguous too... people might mis-read it as the dimension, like, the 5th index value I gave? Not sure how to make it unambiguous. Maybe: IndexError: dimension 0 index out of bounds: got 5, size is 3 ? I thought it best to have erroring indices report their initial value: numpy.zeros(3)[-15] Traceback (most recent call last): File stdin, line 1, in module IndexError: index -15 out of bounds in dimension 0 This is different from some places in the code where IndexErrors already had bad index and dimension information (including the maximum value possible for an index in that dimension). I left these alone, though most of them would report that the bad index was -12 instead of -15. For instance: https://github.com/thouis/numpy/blob/index_error_info/numpy/core/src/multiarray/mapping.c#L1640 I think this code you link to is actually correct, but yeah, it should definitely report whatever the user passed in, or it will be a debugging hindrance rather than a debugging help! Also there were a few indexing errors that were throwing ValueErrors. I changed these to IndexErrors. If someone could give this a cursory review before I issue a PR, I'd appreciate it. I don't expect that most of these code paths are heavily exercised in the tests (but I could be wrong). Perhaps the easiest thing would be to just add a test? It should be about 1 line each per code path... or 2 if you check both the negative and positive versions. def test_index_bound_checking(): assert_raises(IndexError, my_array.__getitem__, (0, 100)) assert_raises(IndexError, my_array.__getitem__, (0, -101)) # etc. - N ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1D array sorting ascending and descending by fields
On Mon, Jun 4, 2012 at 11:10 AM, Patrick Redmond plredm...@gmail.com wrote:
Here's how I sorted primarily by field 'a' descending and secondarily by
field 'b' ascending:
could you multiply the numeric field by -1, sort, then put it back --
somethign like:
data *- -1
data_sorted = np.sort(data, order=['a','b'])
data_sorted *= -1
(reverse if necessary -- I lost track...)
-Chris
(Note that 'a' is the second column, 'b' is the first)
data
array([('b', 0.03),
('c', 0.03),
('f', 0.03),
('e', 0.01),
('d', 0.04),
('a', 0.04)],
dtype=[('b', '|S32'), ('a', 'f8')])
data.sort(order='b') # sort by b
data = data[::-1] # reverse
data[numpy.argsort(data['a'])][::-1] # sort by a and reverse
array([('a', 0.04),
('d', 0.04),
('b', 0.03),
('c', 0.03),
('f', 0.03),
('e', 0.01)],
dtype=[('b', '|S32'), ('a', 'f8')])
My question is whether there's an easier way to do this.
could you multipily the nubmeric field by -1, sort, then multiply it again?
Originally I
thought it would be possible to just do:
data.sort(order=('-a', 'b'))
...indicating that the order of 'a' is descending, but this isn't part of
NumPy's sort behavior.
Your help is appreciated!
Thank you,
Patrick
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [EXTERNAL] Numpy + SWIG
Gideon,
For these use cases, you will need to write short wrapper functions yourself.
In the online docs,
http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html
in the section entitled Beyond the Provided Typemaps, subsection A Common
Example, there is an example of how to do this for a similar, but subtly
different use case. This example looks more like your second problem than your
first, but you tackle the first problem using the same technique.
If you have trouble getting something to work, feel free to contact me off-list.
-Bill
On Jun 4, 2012, at 3:00 PM, Gideon Simpson wrote:
There are two types of swig problems that I was hoping to get some help with.
First, suppose I have some C function
void f(double *x, int nx, double *y, int ny);
where we input one array, and we output another array, both of which should
be the same size.
I have used in my .i file:
%apply(double *IN_ARRAY1, int DIM1){(double *x, int nx)}
%apply(double *ARGOUT_ARRAY1, int DIM1){(double *y, int ny)}
and this produces a workable function. However, it expects, as the functions
second argument, the length of the array x. Now, it's easy enough to call:
module.f(x, x.shape[0])
but is there a way to automatically get it to use the length of the array?
The second problem I have is for a function of the fomr
void g(double *x, int nx, double *y, int ny, double *z, int nz);
which evaluates some function g at all (x,y) pairs. The the thing is that nx
and ny need not be the same size, but nz should be nx * ny. I'd like to wrap
this too, and ideally it would also automatically handle the array lengths,
but I'd be happy to have anything right now. I'm also quite comfortable with
the idea of packing z as a column array and reshaping it as necessary.
-gideon
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
** Bill Spotz **
** Sandia National Laboratories Voice: (505)845-0170 **
** P.O. Box 5800 Fax: (505)284-0154 **
** Albuquerque, NM 87185-0370Email: wfsp...@sandia.gov **
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1D array sorting ascending and descending by fields
On Monday, June 4, 2012, Chris Barker wrote: On Mon, Jun 4, 2012 at 11:10 AM, Patrick Redmond plredm...@gmail.comjavascript:; wrote: Here's how I sorted primarily by field 'a' descending and secondarily by field 'b' ascending: could you multiply the numeric field by -1, sort, then put it back -- somethign like: data *- -1 data_sorted = np.sort(data, order=['a','b']) data_sorted *= -1 (reverse if necessary -- I lost track...) -Chris While that may work for this users case, that would not work for all dtypes. Some, such as timedelta, datetime and strings would not be able to be multiplied by a number. Would be an interesting feature to add, but I am not certain if the negative sign notation would be best. Is it possible for a named field to start with a negative sign? Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes in PyArray_FromAny between 1.5.x and 1.6.x
Can you raise an issue on the Github issue tracker for NumPy? These issues
will be looked at more closely. This kind of change should not have made it
in to the release.
off-topic
Given the lack of availability of time from enough experts in NumPy, this is
the sort of thing that can happen. I was not able to guide development of
NumPy appropriately at my old job. That's a big reason I left. I still have
more to do than just guide NumPy now, but making sure NumPy is maintained is a
big part of what I am doing and why both NumFOCUS and Continuum Analytics
exist. I am very hopeful that we can avoid this sort of regression in the
future. More tests will help.
off-topic
I think it's important to note that there are many people who will be in the
same boat of upgrading to 1.6 over the coming year and there are going to be
other little issues like this we will need to address.
-Travis
On Jun 4, 2012, at 4:12 PM, Dag Sverre Seljebotn wrote:
On 06/04/2012 09:06 PM, Mike Hansen wrote:
On Mon, May 28, 2012 at 3:15 AM, Mike Hansenmhan...@gmail.com wrote:
In trying to upgrade NumPy within Sage, we notices some differences in
behavior between 1.5 and 1.6. In particular, in 1.5, we have
sage: f = 0.5
sage: f.__array_interface__
{'typestr': '=f8'}
sage: numpy.array(f)
array(0.5)
sage: numpy.array(float(f))
array(0.5)
In 1.6, we get the following,
sage: f = 0.5
sage: f.__array_interface__
{'typestr': '=f8'}
sage: numpy.array(f)
array(0.500, dtype=object)
This seems to be do to the changes in PyArray_FromAny introduced in
https://github.com/mwhansen/numpy/commit/2635398db3f26529ce2aaea4028a8118844f3c48
. In particular, _array_find_type used to be used to query our
__array_interface__ attribute, and it no longer seems to work. Is
there a way to get the old behavior with the current code?
No idea. If you want to spend the time to fix this properly, you could
implement PEP 3118 and use that instead to export your array data (which
can be done from Cython using __getbuffer__ on a Cython class).
Dag
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] some typestrings not recognized anymore
Using the 'h2' is redundant, but it should not have been changed so quickly.
I could see raising a deprecation warning and communicating the correct
spelling ('i2').
-Travis
On Jun 3, 2012, at 6:45 PM, Benjamin Root wrote:
On Sunday, June 3, 2012, Ralf Gommers wrote:
On Sun, Jun 3, 2012 at 4:49 PM, Nathaniel Smith n...@pobox.com wrote:
On Sun, Jun 3, 2012 at 3:28 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
Hi,
Just ran into this:
np.__version__
'1.5.1'
np.empty((1,), dtype='h2') # works in 1.6.2 too
array([0], dtype=int16)
np.__version__
'1.7.0.dev-fd78546'
np.empty((1,), dtype='h2')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: data type h2 not understood
For reference the problem seems to be that in 1.6 and earlier, h
plus a number was allowed, and the number was ignored:
np.__version__
'1.5.1'
np.dtype(h2)
dtype('int16')
np.dtype(h4)
dtype('int16')
np.dtype(h100)
dtype('int16')
In current master, the number is disallowed -- all of those give
TypeErrors. Presumably because h already means the same as i2, so
adding a second number on their is weird.
Other typecodes with an intrinsic size seem to have the same problem
-- q, l, etc.
Obviously h2 should be allowed in 1.7, seeing as disallowing it
breaks scipy. And the behavior for h100 is clearly broken and should
be disallowed in the long run. So I guess we need to do two things:
1) Re-enable the use of typecode + size specifier even in cases where
the typcode has an intrinsic size
2) Issue a deprecation warning for cases where the intrinsic size and
the specified size don't match (like h100), and then turn that into
an error in 1.8.
Does that sound correct?
Seems correct as far as I can tell. Your approach to fixing the issue sounds
good.
I guess the other option would be to
deprecate *all* use of size specifiers with these typecodes (i.e.,
deprecate h2 as well, where the size specifier is merely redundant),
but I'm not sure removing that feature is really worth it.
Either way would be OK I think. Using h2 is redundant, but I can see how
someone could prefer writing it like that for clarity. It's not like 'h' --
np.int16 is obvious.
Ralf
Also, we still need the number for some type codes such as 'a' to indicate
the length of the string. I like the first solution much better.
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes in PyArray_FromAny between 1.5.x and 1.6.x
On Mon, Jun 4, 2012 at 9:30 PM, Travis Oliphant tra...@continuum.io wrote: Can you raise an issue on the Github issue tracker for NumPy? These issues will be looked at more closely. This kind of change should not have made it in to the release. Thanks Travis! I've made this https://github.com/numpy/numpy/issues/291 --Mike ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
