Re: [Numpy-discussion] OSX installer: please test
OT: How do you make a dmg ? Is there a (simple) command line tool for this ? Thanks, Sebastian Haase On Wed, Apr 23, 2008 at 9:46 PM, Christopher Barker [EMAIL PROTECTED] wrote: Christopher Burns wrote: I've built a Universal Mac binary for numpy 1.1.0. http://1.1.0. If Mac people would kindly test it, I'd appreciate any feedback. Download here: https://cirl.berkeley.edu/numpy/numpy-1.1.0rc1-py2.5-macosx10.5.dmg Note that it's called *osx10.5.dmg, but it seems to work just fine on 10.4 -- same python. All tests pass: Dual PPC G5 OS-X 10.4.11 python.org version 2.5.1 Thanks! -Chris ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] OSX installer: please test
On Fri, 2008-04-25 at 11:17 +0200, Sebastian Haase wrote: OT: How do you make a dmg ? Is there a (simple) command line tool for this ? .dmg is just an iso 9660 file (e.g. a CD fs), which is recognized by Mac OS X as such. It really is not different than mounting an iso on any unix (you can mount dmg on linux, normally). To get to your point: hdiutil is the command you are looking for. I don't have my macbook available right now, and I have not used it for quite a while, but I guess man hdiutil should give you all the information you are looking for. http://www.kernelthread.com/mac/apme/archive/ cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] insert 1D to a 2D array and change it to 3D
2008/4/25, tournesol [EMAIL PROTECTED]: Hi All. I just want to conver Fortran 77 source to Python. Here is my F77 source. DIMENSION A(25,60,13),B(25,60,13) open(15,file='data.dat') DO 60 K=1,2 READ(15,1602) ((B(I,J),J=1,60),I=1,25) 60 CONTINUE 1602 FORMAT(15I4) DO 63 K=1,10 DO 62 I=1,25 DO 62 J=1,60 A(I,J,K)=B(I,J) 62 CONTINUE 63 CONTINUE END Q1: Fortran-contiguous is ARRAY(row,colum,depth). How about the Python-contiguous ? array(depth,row,colum) ? Default is C-contiguous, but you can you Fortran contiguous arrays. Q2: How can I insert 1D to a 2D array and make it to 3D array. ex:) B:25x60 == A: 10X25X60 I don't understand what you want to do, but broadcasting allows copying several instances of an array into another one. Matthieu -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] insert 1D to a 2D array and change it to 3D
Hi All. I just want to conver Fortran 77 source to Python. Here is my F77 source. DIMENSION A(25,60,13),B(25,60,13) open(15,file='data.dat') DO 60 K=1,2 READ(15,1602) ((B(I,J),J=1,60),I=1,25) 60 CONTINUE 1602 FORMAT(15I4) DO 63 K=1,10 DO 62 I=1,25 DO 62 J=1,60 A(I,J,K)=B(I,J) 62 CONTINUE 63 CONTINUE END Q1: Fortran-contiguous is ARRAY(row,colum,depth). How about the Python-contiguous ? array(depth,row,colum) ? Q2: How can I insert 1D to a 2D array and make it to 3D array. ex:) B:25x60 == A: 10X25X60 Any advice please. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] insert 1D to a 2D array and change it to 3D
why not using something like numpy.repeat? In [18]: B = numpy.random.rand(4,3) In [19]: A = numpy.repeat(B[:,:,numpy.newaxis],2,axis=2) In [20]: B.shape Out[20]: (4, 3) In [21]: A.shape Out[21]: (4, 3, 2) In [22]: numpy.all(A[:,:,0] == A[:,:,1]) Out[22]: True hth, L. On Fri, Apr 25, 2008 at 12:09 PM, Matthieu Brucher [EMAIL PROTECTED] wrote: 2008/4/25, tournesol [EMAIL PROTECTED]: Hi All. I just want to conver Fortran 77 source to Python. Here is my F77 source. DIMENSION A(25,60,13),B(25,60,13) open(15,file='data.dat') DO 60 K=1,2 READ(15,1602) ((B(I,J),J=1,60),I=1,25) 60 CONTINUE 1602 FORMAT(15I4) DO 63 K=1,10 DO 62 I=1,25 DO 62 J=1,60 A(I,J,K)=B(I,J) 62 CONTINUE 63 CONTINUE END Q1: Fortran-contiguous is ARRAY(row,colum,depth). How about the Python-contiguous ? array(depth,row,colum) ? Default is C-contiguous, but you can you Fortran contiguous arrays. Q2: How can I insert 1D to a 2D array and make it to 3D array. ex:) B:25x60 == A: 10X25X60 I don't understand what you want to do, but broadcasting allows copying several instances of an array into another one. Matthieu -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- Lorenzo Bolla [EMAIL PROTECTED] http://lorenzobolla.emurse.com/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generating Bell Curves (was: Using normal() )
On Thu, 24 Apr 2008, Keith Goodman wrote: A Gaussian never reaches zero. Keith, I know, and that's why I need to find another way to draw these curves. While mathematically any 'y' value 0.2 (the default) is equivalent to zero, the curves must reach zero in the figures. Briefly, this model is used in regulatory compliance that may also end up in legal proceedings. While the results are robust and not affected by the curve not reaching zero, the appearance can cause problems in the regulatory and legal arenas. They would be a distraction, a red herring, and consume resources to explain. All this can be avoided by bell curves that reach y=0.0 at the ends. Rich -- Richard B. Shepard, Ph.D. | IntegrityCredibility Applied Ecosystem Services, Inc.|Innovation http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] problem with view() and strided arrays?
Hi all,
Actually -- it seems like view() doesn't work with strided arrays at
all. (?)
In : a = numpy.ones((4,32), dtype=numpy.uint8)
In : a.view(numpy.uint16).shape
Out: (4, 16)
In : a[:,:16].view(numpy.uint16)
ValueError: new type not compatible with array.
I think this might be a recent regression, because before I updated my
numpy installation to the latest SVN version (to check if the bug was
fixed!), I'm pretty sure this kind of operation worked.
The problem starts out in arrayobject.c:6392, in array_descr_set(),
where the following test is performed:
if ((newtype-elsize != self-descr-elsize) \
(self-nd == 0 || !PyArray_ISONESEGMENT(self) || \
newtype-subarray)) goto fail;
I *think* I could fix it by relaxing the restrictions to only require
that the array have at least one dimension where self-strides[dim] ==
self-descr-elsize, and then adjust the size of that dimension.
Here's my perhaps-fix. The old code is:
if ((newtype-elsize != self-descr-elsize) \
(self-nd == 0 || !PyArray_ISONESEGMENT(self) || \
newtype-subarray)) goto fail;
if (PyArray_ISCONTIGUOUS(self)) index = self-nd - 1;
else index = 0;
My suggested fix is:
if ((newtype-elsize != self-descr-elsize) \
(self-nd == 0 || newtype-subarray)) goto fail;
if (PyArray_ISCONTIGUOUS(self)) index = self-nd - 1;
else if (PyArray_ISFORTRAN(self)) index = 0;
else {
int index_found = FALSE;
for (index = 0; index self-nd; index++) {
if (self-strides[index] == self-descr-elsize) {
index_found = TRUE;
break;
}
}
if (!index_found) goto fail;
}
Could someone look this over? If it looks basically right, I'll make
this a proper patch and post it to trac.
Thanks,
Zach
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/25 Alan G Isaac [EMAIL PROTECTED]: 2008/4/25 Alan G Isaac : So, if X is 2 by 2, then X[0] will be a row vector. But if X is 1 by 2, then X[0] will be a scalar? Ouch! Bye bye generic code. On Fri, 25 Apr 2008, Stefan van der Walt apparently wrote: Yup. That's the current state of things. I do not understand. The released state of things is that for matrix ``x`` we have that ``x[0]`` is a **matrix**. I'm not working with SVN NumPy, but my understanding was that as of revision r5072 ``x[0]`` always returns a 1d array. The core requirement was that ``x[0][0]`` produce the first element of the matrix. I do not have time to look at the revision right now, but if a matrix ``x`` we have that ``x[0]`` can return a scalar, that is very undesirable. In current SVN: In [3]: x = np.matrix(np.arange(9).reshape((3,3))) In [5]: x Out[5]: matrix([[0, 1, 2], [3, 4, 5], [6, 7, 8]]) In [6]: x[0] Out[6]: matrix([[0, 1, 2]]) In [7]: x[0,:] Out[7]: matrix([[0, 1, 2]]) In [8]: x[0][0] Out[8]: 0 In [9]: x[0,:][0] Out[9]: 0 In [10]: x[:,0] Out[10]: matrix([[0], [3], [6]]) In [11]: x[:,0][0] Out[11]: 0 In [12]: x[:2,:2][0] Out[12]: matrix([[0, 1]]) Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generating Bell Curves (was: Using normal() )
Other suggestions for bounded bell-shaped functions that reach zero on a finite interval: - Beta distribution: http://en.wikipedia.org/wiki/Beta_distribution - Cubic B-splines:http://www.ibiblio.org/e-notes/Splines/Basis.htm 2008/4/25 Bruce Southey [EMAIL PROTECTED]: Rich Shepard wrote: Thanks to several of you I produced test code using the normal density function, and it does not do what we need. Neither does the Gaussian function using fwhm that I've tried. The latter comes closer, but the ends do not reach y=0 when the inflection point is y=0.5. So, let me ask the collective expertise here how to generate the curves that we need. We need to generate bell-shaped curves given a midpoint, width (where y=0) and inflection point (by default, y=0.5) where y is [0.0, 1.0], and x is usually [0, 100], but can vary. Using the NumPy arange() function to produce the x values (e.g, arange(0, 100, 0.1)), I need a function that will produce the associated y values for a bell-shaped curve. These curves represent the membership functions for fuzzy term sets, and generally adjacent curves overlap where y=0.5. It would be a bonus to be able to adjust the skew and kurtosis of the curves, but the controlling data would be the center/midpoint and width, with defaults for inflection point, and other parameters. I've been searching for quite some time without finding a solution that works as we need it to work. TIA, Rich Hi, You could use a Gamma distribution to get a skewed distribution. But to extend Keith's comment, continuous distributions typically go from minus infinity or zero to positive infinity and, furthermore, the probability of a single point in a continuous distribution is always zero. The only way you are going to get this from a single continuous distribution is via some truncated distribution - essentially Keith's reply. Alternatively, you may get away with a discrete distribution like the Poisson since it very quickly approaches normality but is skewed. A multinomial distribution may also work but that is more assumptions. In either case, you have map the points into the valid space because it is the distribution within the set that is used not the distribution of the data. I do not see the requirement for overlapping curves because the expected distribution of each set should be independent of the data and of the other sets. In that case, you just find the mean and variance of each set to get the degree of overlap you require. The inflection point requirement is very hard to understand as it different meanings such as just crossing or same area under the curve. I don't see any simple solution to that - two normals with the same variance but different means probably would. If the sets are dependent then you need a multivariate solution. Really you probably need a mixture of distributions and/or generate your own function to get something that meets you full requirements. Regards Bruce ___ 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] Generating Bell Curves (was: Using normal() )
On Fri, 25 Apr 2008, David Huard wrote: Other suggestions for bounded bell-shaped functions that reach zero on a finite interval: - Beta distribution: http://en.wikipedia.org/wiki/Beta_distribution - Cubic B-splines:http://www.ibiblio.org/e-notes/Splines/Basis.htm Thanks, David. I'm aware of the Beta distribution, but the cubic B-splines are completely new to me. Certainly something to look into. Rich -- Richard B. Shepard, Ph.D. | IntegrityCredibility Applied Ecosystem Services, Inc.|Innovation http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
I think the use of the term 'vector' in this thread is becoming a bit confusing. An M by N matrix is a vector. (I.e., it is an element of a vector space.) Many people use the terms row vector and column vector to refer to special matrices. What is special is *not* that they are vectors (since all matrices are) but that they are a single row or a single column. Perhaps better terminology would have been row matrix and column matrix. Using this terminology, we clearly expect a row matrix and a column matrix to have transposes. The question is, can their elements be indexed by scalars. The answer in all the proposals, I believe, is yes. I believe we are finding that this answer has some problems. x is a 2 by 2 matrix x[0] is a 1 by 2 matrix x[0][0] is x[0,0] GOOD!! y = x[0] - y is a 1 by 2 matrix y[0][0] is a TypeError BAD!! So I am becoming more and more persuaded that for a matrix ``x``: x[0] should be a 1d array (always!) x[0,:] should be a matrix The rule: use non-scalar indexing to extract submatrices fwiw, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote: In current SVN: In [6]: x[0] Out[6]: matrix([[0, 1, 2]]) I must have misunderstood: I thought the agreement was to provisionally return a 1d array for x[0], while we hashed through the other proposals. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] aligned matrix / ctypes
Hello all,
Attached is code (plus tests) for allocating aligned arrays -- I think
this addresses all the requests in this thread, with regard to
allowing for different kinds of alignment. Thanks Robert and Anne for
your help and suggestions. Hopefully this will be useful.
The core is a function for allocating arrays with totally arbitrary
alignment along each dimension (e.g. you could allocate an 10x20 array
of uint16's where each uint16 is aligned to 4-byte boundaries and each
row of 20 uint16's is aligned to 32-byte boundaries, and the entire
buffer is aligned to a 128-byte boundary.) I've also included helper
functions for two common cases: when you want everything aligned to a
particular multiple (every element, row, etc. as well as the whole
buffer), and when you want an array where the rows (second-fastest
moving index) are so aligned (this was my original use case, for fast
image-blitting).
Zach
def aligned_empty(shape, dtype, dim_alignments, array_alignment):
'''Allocate an empty array with the given shape and dtype, where
the array
buffer starts at a memory address evenly-divisible by
array_alignment, and
where items along each dimension are offset from the first item on
that
dimension by a byte offset that is an integer multiple of the
corresponding
value in the dim_alignments tuple.
Example: To allocate a 20x30 array of floats32s, where individual
data
elements are aligned to 16-bute boundaries, each row is aligned to
a 64-byte
boundary, and the array's buffer starts on a 128-byte boundary, call:
aligned_empty((20,30), numpy.float32, (64, 16), 128)
'''
def aligned_rows_empty(shape, dtype, alignment, order='C'):
'''Return an array where the rows (second-fastest-moving index) are
aligned
to byte boundaries evenly-divisible by 'alignment'. If 'order' is
'C', then
the indexing is such that the fastest-moving index is the last one;
if the
order is 'F', then the fastest-moving index is the first.'''
def aligned_elements_empty(shape, dtype, alignment, order='C'):
'''Return an array where each element is aligned to byte boundaries
evenly-
divisible by 'alignment'.'''
import numpy
def aligned_empty(shape, dtype, dim_alignments, array_alignment):
'''Allocate an empty array with the given shape and dtype, where the array
buffer starts at a memory address evenly-divisible by array_alignment, and
where items along each dimension are offset from the first item on that
dimension by a byte offset that is an integer multiple of the corresponding
value in the dim_alignments tuple.
Example: To allocate a 20x30 array of floats32s, where individual data
elements are aligned to 16-bute boundaries, each row is aligned to a 64-byte
boundary, and the array's buffer starts on a 128-byte boundary, call:
aligned_empty((20,30), numpy.float32, (64, 16), 128)
'''
if len(shape) != len(dim_alignments):
raise ValueError('Alignments must be provided for each dimension.')
dtype = numpy.dtype(dtype)
strides = []
current_size = dtype.itemsize
for width, alignment in zip(shape[::-1], dim_alignments[::-1]):
# build up new strides array in reverse, so that the fastest-moving index
# is the last (C-ish indexing, but not necessarily contiguous)
current_size += (alignment - current_size % alignment) % alignment
strides.append(current_size)
current_size *= width
strides = strides[::-1]
total_bytes = current_size + (array_alignment - 1)
buffer = numpy.empty(total_bytes, dtype=numpy.uint8)
address = buffer.ctypes.data
offset = (array_alignment - address % array_alignment) % array_alignment
return numpy.ndarray(shape=shape, dtype=dtype, buffer=buffer,
strides=strides, offset=offset)
def aligned_rows_empty(shape, dtype, alignment, order='C'):
'''Return an array where the rows (second-fastest-moving index) are aligned
to byte boundaries evenly-divisible by 'alignment'. If 'order' is 'C', then
the indexing is such that the fastest-moving index is the last one; if the
order is 'F', then the fastest-moving index is the first.'''
if len(shape) 2:
raise ValueError('Need at least a 2D array to align rows.')
order = order.upper()
if order not in ('C', 'F'):
raise ValueError(Order must be 'C' or 'F'.)
dim_alignments = [1 for dim in shape]
dim_alignments[-2] = alignment
if order == 'F':
shape = shape[::-1]
return aligned_empty(shape, dtype, dim_alignments, alignment).T
else:
return aligned_empty(shape, dtype, dim_alignments, alignment)
def aligned_elements_empty(shape, dtype, alignment, order='C'):
'''Return an array where each element is aligned to byte boundaries evenly-
divisible by 'alignment'.'''
order = order.upper()
if order not in ('C', 'F'):
raise ValueError(Order must be 'C' or 'F'.)
dim_alignments = [alignment for dim in shape]
if order == 'F':
shape = shape[::-1]
return aligned_empty(shape, dtype,
Re: [Numpy-discussion] numpy release
2008/4/25 Alan G Isaac [EMAIL PROTECTED]: I must have misunderstood: I thought the agreement was to provisionally return a 1d array for x[0], while we hashed through the other proposals. The agreement was: a) That x[0][0] should be equal to x[0,0] and b) That x[0,:] should be equal to x[0] (as for ndarrays) This breaks as little functionality as possible, at the cost of one (instead of two) API changes. We should now discuss the proposals on the table, choose a good one, and implement all the API changes necessary for 1.2 or 2. It's a pity we have to change the API again, but the current situation is not tenable. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On 25/04/2008, Stéfan van der Walt [EMAIL PROTECTED] wrote: 2008/4/25 Alan G Isaac [EMAIL PROTECTED]: I must have misunderstood: I thought the agreement was to provisionally return a 1d array for x[0], while we hashed through the other proposals. The agreement was: a) That x[0][0] should be equal to x[0,0] and b) That x[0,:] should be equal to x[0] (as for ndarrays) This breaks as little functionality as possible, at the cost of one (instead of two) API changes. Hold on. There has definitely been some confusion here. This is not what I thought I was suggesting, or what Alan thought he was suggesting. I do not think special-casing matrices for which one dimension happens to be one is a good idea at all, even temporarily. This is the kind of thing that drives users crazy. My suggested stopgap fix was to make x[0] return a 1D *array*; I feel that this will result in less special-casing. In fact I wasn't aware that anyone had proposed the fix you implemented. Can we change the stopgap solution? We should now discuss the proposals on the table, choose a good one, and implement all the API changes necessary for 1.2 or 2. It's a pity we have to change the API again, but the current situation is not tenable. Yes, well, it really looks unlikely we will be able to agree on what the correct solution is before 1.1, so I would like to have something non-broken for that release. Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Fri, Apr 25, 2008 at 10:04 AM, Alan G Isaac [EMAIL PROTECTED] wrote: I think the use of the term 'vector' in this thread is becoming a bit confusing. An M by N matrix is a vector. (I.e., it is an element of a vector space.) Sure, but the important thing is the multiplication. If it wasn't we could just flatten them all and be done with this discussion. Super bonus, no need for the '*' operator. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] untenable matrix behavior in SVN
2008/4/25 Alan G Isaac [EMAIL PROTECTED]: I must have misunderstood: I thought the agreement was to provisionally return a 1d array for x[0], while we hashed through the other proposals. On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote: The agreement was: a) That x[0][0] should be equal to x[0,0] and b) That x[0,:] should be equal to x[0] (as for ndarrays) 1. This is **not** what I understood as the agreement (and I think the current solution is bad). I certainly did not mean to support the change that as implemented, and it is not clear to me that others did either. 2. These two goals are substantially in conflict for matrices, as we are seeing. 3. The important goal, (goal a., which everyone agrees on), has NOT been accomplished by the current change: x[0][0] raises a TypeError when x is a 1 by N matrix. This breaks as little functionality as possible, at the cost of one (instead of two) API changes. I cannot agree with this assessment. the current situation is not tenable. I agree with this! Better than the SVN behavior would be to raise an error in response to scalar indexing of matrices. I strongly hope that this behavior will not show up in a release! Please return 1d arrays in response to scalar indexing as the provisional arrangement. This is certainly better than the new behavior. Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generating Bell Curves (was: Using normal() )
On 24/04/2008, Rich Shepard [EMAIL PROTECTED] wrote: Thanks to several of you I produced test code using the normal density function, and it does not do what we need. Neither does the Gaussian function using fwhm that I've tried. The latter comes closer, but the ends do not reach y=0 when the inflection point is y=0.5. So, let me ask the collective expertise here how to generate the curves that we need. We need to generate bell-shaped curves given a midpoint, width (where y=0) and inflection point (by default, y=0.5) where y is [0.0, 1.0], and x is usually [0, 100], but can vary. Using the NumPy arange() function to produce the x values (e.g, arange(0, 100, 0.1)), I need a function that will produce the associated y values for a bell-shaped curve. These curves represent the membership functions for fuzzy term sets, and generally adjacent curves overlap where y=0.5. It would be a bonus to be able to adjust the skew and kurtosis of the curves, but the controlling data would be the center/midpoint and width, with defaults for inflection point, and other parameters. I've been searching for quite some time without finding a solution that works as we need it to work. First I should say, please don't call these bell curves! It is confusing people, since that usually means specifically a Gaussian. In fact it seems that you want something more usually called a sigmoid, or just a curve with a particular shape. I would look at http://en.wikipedia.org/wiki/Sigmoid_function In particular, they point out that the integral of any smooth, positive, bump-shaped function will be a sigmoid. So dreaming up an appropriate bump-shaped function is one way to go. Alternatively, tou can look at polynomial fitting - if you want, say, a function that is 1 with derivative zero at 0, 0.5 with derivative -1 at x, and 0 with derivative 0 at 1, you can construct a unique degree-6 polynomial that does exactly that; there's a new tool, KroghInterpolator, in scipy svn that can do that for you. Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
Anne Archibald wrote: Yes, well, it really looks unlikely we will be able to agree on what the correct solution is before 1.1, so I would like to have something non-broken for that release. +1 on that! ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] aligned matrix / ctypes
Robert, Can we check this in somewhere under numpy.core? It seems very useful. Stéfan 2008/4/25 Zachary Pincus [EMAIL PROTECTED]: Hello all, Attached is code (plus tests) for allocating aligned arrays -- I think this addresses all the requests in this thread, with regard to allowing for different kinds of alignment. Thanks Robert and Anne for your help and suggestions. Hopefully this will be useful. The core is a function for allocating arrays with totally arbitrary alignment along each dimension (e.g. you could allocate an 10x20 array of uint16's where each uint16 is aligned to 4-byte boundaries and each row of 20 uint16's is aligned to 32-byte boundaries, and the entire buffer is aligned to a 128-byte boundary.) I've also included helper functions for two common cases: when you want everything aligned to a particular multiple (every element, row, etc. as well as the whole buffer), and when you want an array where the rows (second-fastest moving index) are so aligned (this was my original use case, for fast image-blitting). Zach def aligned_empty(shape, dtype, dim_alignments, array_alignment): '''Allocate an empty array with the given shape and dtype, where the array buffer starts at a memory address evenly-divisible by array_alignment, and where items along each dimension are offset from the first item on that dimension by a byte offset that is an integer multiple of the corresponding value in the dim_alignments tuple. Example: To allocate a 20x30 array of floats32s, where individual data elements are aligned to 16-bute boundaries, each row is aligned to a 64-byte boundary, and the array's buffer starts on a 128-byte boundary, call: aligned_empty((20,30), numpy.float32, (64, 16), 128) ''' def aligned_rows_empty(shape, dtype, alignment, order='C'): '''Return an array where the rows (second-fastest-moving index) are aligned to byte boundaries evenly-divisible by 'alignment'. If 'order' is 'C', then the indexing is such that the fastest-moving index is the last one; if the order is 'F', then the fastest-moving index is the first.''' def aligned_elements_empty(shape, dtype, alignment, order='C'): '''Return an array where each element is aligned to byte boundaries evenly- divisible by 'alignment'.''' ___ 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 release
I was hoping to get NumPy 1.1 tagged today, but it seems very unlikely at this point. Unfortunately, I haven't followed the matrix discussion as closely as I would like, so I can't tell if there is anything so uncontroversial that it would make sense to change for the 1.1.0 release. If there is something that can be unanimously agreed on within the next 24 hours or so, I would be happy to have it included in 1.1. If not, I would rather see us move on to working on 1.2 and releasing 1.1 ASAP. If there is unanimous agreement on a minor fix, we will need document the changes on the release notes. So once an agreement is reached, could someone either send me some text to insert into the release notes or update the document themselves: http://projects.scipy.org/scipy/numpy/milestone/1.1.0 This also might be a good opportunity to start a new thread with a subject line like 1.2 matrices. The discussion about matrices in this thread makes it difficult for me to quickly see what still needs to done before the 1.1 release. And there may also be some members of the community who would be very interested in the matrices discussion, but aren't reading this thread. -- 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
Re: [Numpy-discussion] untenable matrix behavior in SVN
On Fri, 25 Apr 2008, Jarrod Millman apparently wrote: I would like, so I can't tell if there is anything so uncontroversial that it would make sense to change for the 1.1.0 release. I think it is clear from reactions that the revision r5072 to matrix behavior should NOT go into any release. If there is something that can be unanimously agreed on within the next 24 hours or so, I would be happy to have it included in 1.1. I see 3 possibilities (in rank order of preference): 1. return 1d arrays in response to scalar indexing of matrices 2. raise an error on scalar indexing of matrices 3. simply revert the r5072 change. Since there is universal accord that x[0][0] == x[0,0] is desirable, and we will get that with option 1, I think it is the right provisional behavior. I believe that option 1 provides a step in the direction of the ultimate behavior, no matter what that will be. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] untenable matrix behavior in SVN
2008/4/25 Alan G Isaac [EMAIL PROTECTED]: 1. This is **not** what I understood as the agreement (and I think the current solution is bad). Reverted in r5084. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Does Unreasonable Matrix Behavior affect Scipy Sparse
I had b = Ax working where A is sparse using scipy.sparse. I'm now using the latest svn and b = Ax is not working and returns garbage results. Nothing has changed except the latest svn. Any thoughts? Dinesh ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] untenable matrix behavior in SVN
On Fri, 25 Apr 2008, Stéfan van der Walt wrote: workaround would break x[0] == x[0,:] But there is not universal agreement that x[0] == x[0,:] is desirable. In contrast, there *is* universal agreement that x[0][0]==x[0,0] is desirable. Or so I've understood the discussion. As you know, my view is that nonscalar indexing should return submatrices, while scalar indexing should return 1d arrays. Thus I do not see x[0] != x[0,:] as breakage: it is desirable. Indeed, without it, we will have an untenable situation, under all the different proposals. So it is a goner one way or another. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/25 Stéfan van der Walt [EMAIL PROTECTED]: I'm starting to see Chris Barker's point; allowing x[0] is causing more problems than it is worth. On the other hand, how would you index into a vector (as in http://en.wikipedia.org/wiki/Vector_(spatial)) without it? To answer my own question: you wouldn't. Vectors won't exist, everything will be 2D, always. I could go with that. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/24 Jarrod Millman [EMAIL PROTECTED]: On Thu, Apr 24, 2008 at 1:22 PM, David Huard wrote: Assuming we want the next version to : ignore values outside of range and accept and return the bin edges instead of the left edges, here could be the new signature for 1.1: h, edges = histogram(a, bins=10, normed=False, range=None, normed=False, new=False) If new=False, return the histogram and the left edges, with a warning that in the next version, the edges will be returned. If new=True, return the histogram and the edges. If range is given explicitly , raise a warning saying that in the next version, the outliers will be ignored. To ignore outliers, use new=True. If bins is a sequence, raise an error saying that bins should be an integer. To use explicit edges, use new=True. In 1.2, set new=True as the default, and in 2.3, remove new altogether. +1 That sounds fine to me assuming 2.3 is 1.3. Indeed. Done in r5085. I added a bunch of tests, but I'd appreciate if someone could double check before the release. This is not the time to introduce new bugs. Hopefully this is the end of the histogram saga. David -- 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 release
2008/4/25 David Huard [EMAIL PROTECTED]: 2008/4/24 Jarrod Millman [EMAIL PROTECTED]: On Thu, Apr 24, 2008 at 1:22 PM, David Huard wrote: Assuming we want the next version to : ignore values outside of range and accept and return the bin edges instead of the left edges, here could be the new signature for 1.1: h, edges = histogram(a, bins=10, normed=False, range=None, normed=False, new=False) If new=False, return the histogram and the left edges, with a warning that in the next version, the edges will be returned. If new=True, return the histogram and the edges. If range is given explicitly , raise a warning saying that in the next version, the outliers will be ignored. To ignore outliers, use new=True. If bins is a sequence, raise an error saying that bins should be an integer. To use explicit edges, use new=True. In 1.2, set new=True as the default, and in 2.3, remove new altogether. +1 That sounds fine to me assuming 2.3 is 1.3. Indeed. Done in r5085. I added a bunch of tests, but I'd appreciate if someone could double check before the release. This is not the time to introduce new bugs. Hopefully this is the end of the histogram saga. Well, it's not... there is still an issue... give me a couple of minutes to fix it. David -- 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] Does Unreasonable Matrix Behavior affect Scipy Sparse
On Fri, 25 Apr 2008, Dinesh B Vadhia apparently wrote: where A is sparse using scipy.sparse. ... I'm now using the latest svn and b = Ax 1. Please post a small example. 2. Do you have the *very* latest SVN (post r5084)? Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] untenable matrix behavior in SVN
On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote: Reverted in r5084. Thank you. I think we have discovered that there is a basic conflict between two behaviors: x[0] == x[0,:] vs. x[0][0] == x[0,0] To my recollection, everyone has agree that the second behavior is desirable as a *basic expectation* about the behavior of 2d objects. This implies that *eventually* we will have ``x[0][0] == x[0,0]``. But then eventually we MUST eventually have x[0] != x[0,:]. Since a current behavior must disappear eventually, we should make it disappear as soon as possible: before the release. The question is how. I see two simple ways to move forward immediately: 1. scalar indexing of matrices returns a 1d array 2. scalar indexing of matrices raises a TypeError If we raise a TypeError, we lose both behaviors. If we return a 1d array, we retain the behavior that has been seen as desirable (as a *basic expectation* about the behavior of 2d objects). Stefan, do you agree, and if so, would you be willing to have a vote on these two options? Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generating Bell Curves (was: Using normal() )
On Fri, 25 Apr 2008, Robert Kern wrote: In that case, you need to search the literature of your field for precise details on how to construct the curve that you want. Robert, Considering how few of us work in this subject area there's not much in the way of resources. Regardless, for now the working Gaussian code will do quite well. As time permits I'll see what I can find (or create) to produce a curve that reaches zero at the bounds. Many thanks, all, Rich -- Richard B. Shepard, Ph.D. | IntegrityCredibility Applied Ecosystem Services, Inc.|Innovation http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] untenable matrix behavior in SVN
On Fri, Apr 25, 2008 at 12:02 PM, Alan G Isaac [EMAIL PROTECTED] wrote: On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote: Reverted in r5084. Thank you. I think we have discovered that there is a basic conflict between two behaviors: x[0] == x[0,:] vs. x[0][0] == x[0,0] To my recollection, everyone has agree that the second behavior is desirable as a *basic expectation* about the behavior of 2d objects. This implies that *eventually* we will have ``x[0][0] == x[0,0]``. But then eventually we MUST eventually have x[0] != x[0,:]. Choices: 1) x[0] equiv x[0:1,:] -- current behavior 2) x[0] equiv x[0,:] -- array behavior, gives x[0][0] == x[0,0] These are incompatible. I think 1) is more convenient in the matrix domain and should be kept, while 2) should be given up. What is the reason for wanting 2)? Maybe we could overload the () operator so that x(0) gives 2)? Or vice versa. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] untenable matrix behavior in SVN
On 25/04/2008, Charles R Harris [EMAIL PROTECTED] wrote: On Fri, Apr 25, 2008 at 12:02 PM, Alan G Isaac [EMAIL PROTECTED] wrote: I think we have discovered that there is a basic conflict between two behaviors: x[0] == x[0,:] vs. x[0][0] == x[0,0] To my recollection, everyone has agree that the second behavior is desirable as a *basic expectation* about the behavior of 2d objects. This implies that *eventually* we will have ``x[0][0] == x[0,0]``. But then eventually we MUST eventually have x[0] != x[0,:]. Choices: 1) x[0] equiv x[0:1,:] -- current behavior 2) x[0] equiv x[0,:] -- array behavior, gives x[0][0] == x[0,0] These are incompatible. I think 1) is more convenient in the matrix domain and should be kept, while 2) should be given up. What is the reason for wanting 2)? Maybe we could overload the () operator so that x(0) gives 2)? Or vice versa. We are currently operating in a fog of abstraction, trying to decide which operations are more natural or more in correspondence with our imagined idea of a user. We're not getting anywhere. Let's start writing up (perhaps on the matrix indexing wiki page) plausible use cases for scalar indexing, and how they would look under each proposal. For example: * Iterating over the rows of a matrix: # array-return proposal; x is a scalar for row in M: if np.all(row==0): raise ValueError # exception-raising proposal for i in xrange(M.shape[0]): if np.all(M[i,:]==0): raise ValueError Other applications? Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generating Bell Curves (was: Using normal() )
On Fri, 25 Apr 2008, Bruce Southey wrote: Just use a truncated distribution as these are well known: http://en.wikipedia.org/wiki/Truncated_distribution http://en.wikipedia.org/wiki/Truncated_normal_distribution Bruce, I considered the truncated normal distribution, but having the tails of the Gaussian distribution above zero is more acceptable. Thanks very much for the suggestion, Rich -- Richard B. Shepard, Ph.D. | IntegrityCredibility Applied Ecosystem Services, Inc.|Innovation http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generating Bell Curves (was: Using normal() )
On Fri, 25 Apr 2008, Charles R Harris wrote: You can use something like f(x) = (1-x**2)**2 , which has inflection points and vanishes at +/- 1. Any of the B-splines will also do the trick. Chuck, Thank you. I need to make some time to understand the B-splines to use them appropriately. Unfortunately, my mathematical statistics learning was many years in the past ... but we had moved ahead of writing on clay tablets by that time. Not needing to retain that knowledge for many years means it was replaced by more pressing current knowledge. The B-splines do look promising, though. Rich -- Richard B. Shepard, Ph.D. | IntegrityCredibility Applied Ecosystem Services, Inc.|Innovation http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] untenable matrix behavior in SVN
Alan G Isaac wrote: Please return 1d arrays in response to scalar indexing as the provisional arrangement. +1 (for the provisional solution) This has clarified it a bit for me. The current situation allows one to create row vectors and column vectors by generating matrices (in various ways) that happen to be shape (1,n) or (n,1). These objects behave as we all want in arithmetic operations (*, **). So what's missing: * The ability to index one of these vector objects by a single index, and get a scalar as a result. * If I'm not mistaken (and I probably am) -- that is the crux of this entire conversation. Do we want that? I would say yes, it's a pretty natural and common thing to want. Note that with the current version of matrix (numpy 1.1.0rc1), you can index a (n,1) matrix with a scalar, and get a (1,1) matrix, but you get an exception if you try to index a (1,n) matrix with a scalar: rv matrix([[3, 4, 5]]) rv[1] Traceback (most recent call last): File stdin, line 1, in module File /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/defmatrix.py, line 228, in __getitem__ out = N.ndarray.__getitem__(self, index) IndexError: index out of bounds I know why that's happening, but I think it's a demonstration of why we might want some sort of vector object, for a cleaner API. How do we achieve this? One possibility is to special case (n,1) and (1,n) matrices, but I think there is consensus that that is a BAD IDEA (tm) Which leaves us with needing a vector object -- which acts a lot like a 1-d array, except that it acts like a (n,1) or (1,n) matrix with * and **, and may get printed differently. I think there are two ways to accomplish this: (1) RowVector or ColumnVector objects that are essentially 1-d ndarrays, with a few methods overridden. (2) A Vector object that is a matrix of either (n,1) or (1,n) in shape, with a couple methods overridden. I think the difference is an implementation detail. They should behave about the same either way. In either case, we should probably have factory functions for these objects: RowVector() and ColumnVector() By the way, I think this brings us closer to the goal of matrices acting as much like arrays as possible -- when you index into a 2-d array: A[:,i], you get a 1-d array. These vectors would act a lot like 1-d arrays, so that would be more similar than the current situation. It also might be nice to have iterators over rows and columns, like: for row in M.rows: ... and for col in M.columns: ... We can get the rows as the default iterator, but it feels nice and symmetric to be able to iterate over columns too (though I have no idea how useful that would really be) Stéfan van der Walt wrote: The whole idea of matrices was that you always work with 2-dimensional arrays, even when you just extract a row. Unless you have a proper hierarchical container (as illustrated in the other patch I sent), returning a 1D array breaks at least some expectation. I agree -- stopgap is OK (but having people do M.A[i] is a fine stopgap too), but if we really want this, we need some sort of vector object. If that's what the matrix users want, though, then we should change it. I still want to see some linear algebra examples -- that's what matrices are for. We can iterate over 2-d arrays and get 1-d arrays just fine now, if that's what you want. Unless we agree on something, and soon, that won't happen. Your workaround would break x[0] == x[0,:], so we're just swapping one set of broken functionality for another. Alan G Isaac wrote: But then we MUST eventually have x[0] != x[0,:]. I don't think so -- I think a Vector object would allow both of: M[i,j] == M[i][j] and M[i] == M[i,:] however, M[i] != M[:,i] -- M[i] can only mean one thing, and this doesn't hold for arrays, either. and (if we do the iterators): M.rows[i] == M[i,:] M.columns[i] == M[:,i] You can get rows a bit more conveniently than columns, which is really just an accident of how C arranges memory, but why not? Again, to make this pure we'd disallow M[i], but practicality beats purity, after all. how would you index into a vector (as in http://en.wikipedia.org/wiki/Vector_(spatial)) without it? Right -- which is why a 1-d vector object has its uses. Alan G Isaac wrote: Since a current behavior must disappear eventually, we should make it disappear as soon as possible: before the release. The question is how. I see two simple ways to move forward immediately: 1. scalar indexing of matrices returns a 1d array 2. scalar indexing of matrices raises a TypeError I don't agree -- what we have is what we have, not changing it will not break any existing code, so we should only make a change if it moves us closer to what we want in the future -- it does seem that most folks do want M[i] to return some sort of 1-d object, so I'm fine with (1). I'm
Re: [Numpy-discussion] OSX installer: please test
David Cournapeau wrote: To get to your point: hdiutil is the command you are looking for. yup. Here's an example: hdiutil create -srcfolder YourDir -volname A Name -ov Something.dmg It will build a disk image from the directory: YourDir -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 [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] untenable matrix behavior in SVN
On Fri, 25 Apr 2008, Christopher Barker apparently wrote: I think a Vector object would allow both of: M[i,j] == M[i][j] and M[i] == M[i,:] The problem is that it would be a crime to give up the natural production of submatrices. The NATURAL RULE is: to get a submatrix, use nonscalar indices. We should *not* give up that x[0,:] is a sub*matrix* whose first element is x[0,0] and equivalently x[0][0]. *This* is why we must have x[0]!=x[0,:] if we want, as we do, that x[0][0]==x[0,0]. Note that the idea for attributes ``rows`` and ``columns`` is contained on the discussion page: URL:http://www.scipy.org/MatrixIndexing I claim that it is natural for these attributes to yield properly shaped *matrices*. Once we have these attributes, it is difficult to see what we gain by introducing the complication of a separate vector class. I still see no real gain from a separate vector class (or row and column vector classes). Everything that has been proposed to do with these is achievable with the corresponding matrices with one exception: scalar indexing - element so that x[0][0]==x[0,0]. But this outcome is achieved MUCH more simply by letting x[0] be a 1d array. Anyway, I am glad you agree that letting ``x[0]`` be a 1d array is the proper provisional solution. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
Thanks Chuck, I didn't know there were other tests for histogram outside of test_function_base. The error is now raised only if bins are passed explicitly and normed=True. David 2008/4/25 Charles R Harris [EMAIL PROTECTED]: On Fri, Apr 25, 2008 at 12:55 PM, Jarrod Millman [EMAIL PROTECTED] wrote: On Fri, Apr 25, 2008 at 12:55 PM, David Huard [EMAIL PROTECTED] wrote: Done in r5085. I added a bunch of tests, but I'd appreciate if someone could double check before the release. This is not the time to introduce new bugs. Hopefully this is the end of the histogram saga. This one? ERROR: Ticket #632 -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/numpy/core/tests/test_regression.py, line 812, in check_hist_bins_as_list hist,edges = np.histogram([1,2,3,4],[1,2]) File /usr/lib/python2.5/site-packages/numpy/lib/function_base.py, line 184, in histogram raise ValueError, 'Use new=True to pass bin edges explicitly.' ValueError: Use new=True to pass bin edges explicitly. Chuck ___ 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] untenable matrix behavior in SVN
On Fri, Apr 25, 2008 at 2:57 PM, Alan G Isaac [EMAIL PROTECTED] wrote: On Fri, 25 Apr 2008, Christopher Barker apparently wrote: I think a Vector object would allow both of: M[i,j] == M[i][j] and M[i] == M[i,:] The problem is that it would be a crime to give up the natural production of submatrices. The NATURAL RULE is: to get a submatrix, use nonscalar indices. We should *not* give up that x[0,:] is a sub*matrix* whose first element is x[0,0] and equivalently x[0][0]. *This* is why we must have x[0]!=x[0,:] if we want, as we do, that x[0][0]==x[0,0]. I would give it up and let x(0) be a submatrix, the normal indexing is then exactly like an array. True, the result of x(0) can't be used as an lvalue (only getitem equivalence), but otherwise it should work fine. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Does Unreasonable Matrix Behavior affectScipy Sparse
On Fri, Apr 25, 2008 at 2:46 PM, Dinesh B Vadhia [EMAIL PROTECTED] wrote: Alan I posted this on the scipy list: I have a working program with b=Ax, where A is a large sparse matrix. However, I need the int8 support in the sparse library to utilize much larger matrices. I managed to get hold of a numpy svn 5066 and scipy svn 4167 build, and b=Ax now returns garbage results. Nothing was changed in the program except replacing getrow with todense() and I checked these to make sure the right rows were being picked up. Wish I could point out where exactly the problem lies but there was no Traceback just the wrong results but it can safely be assumed it is with the numpy/scipy matrix support. Any ideas? Dinesh, what is the svn revision you are using? 'Latest' doen't tell us much because it changes all the time. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] untenable matrix behavior in SVN
On Fri, 25 Apr 2008, Christopher Barker apparently wrote: I think a Vector object would allow both of: M[i,j] == M[i][j] and M[i] == M[i,:] On Fri, Apr 25, 2008 at 2:57 PM, Alan G Isaac [EMAIL PROTECTED] wrote: The problem is that it would be a crime to give up the natural production of submatrices. The NATURAL RULE is: to get a submatrix, use nonscalar indices. We should not give up that x[0,:] is a sub*matrix* whose first element is x[0,0] and equivalently x[0][0]. This is why we must have x[0]!=x[0,:] if we want, as we do, that x[0][0]==x[0,0]. On Fri, 25 Apr 2008, Charles R Harris apparently wrote: I would give it up and let x(0) be a submatrix, the normal indexing is then exactly like an array. True, the result of x(0) can't be used as an lvalue (only getitem equivalence), but otherwise it should work fine. The it here is ambiguous. Which do you want to give up? - x[0][0]==x[0,0] ? the argument has been that this is a fundamental expectations for 2d array-like objects, and I think that argument is right - x[0]==x[0,:] ? I believe you mean we should give this up, and if so, I strongly agree. As you know. Enforcing this is proving untenable and costly. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Does Unreasonable Matrix Behavior affectScipy Sparse
1. Please post a small example. 2. Do you have the very latest SVN (post r5084)? On Fri, 25 Apr 2008, Dinesh B Vadhia apparently wrote: I have a working program with b=Ax, where A is a large sparse matrix. However, I need the int8 support in the sparse library to utilize much larger matrices. I managed to get hold of a numpy svn 5066 and scipy svn 4167 build, and b=Ax now returns garbage results. Nothing was changed in the program except replacing getrow with .todense() and I checked these to make sure the right rows were being picked up. Wish I could point out where exactly the problem lies but there was no Traceback just the wrong results but it can safely be assumed it is with the numpy/scipy matrix support. You need to post a small example (actual code) that generates the error. But first update NumPy from SVN and confirm that th problem still exists. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generating Bell Curves (was: Using normal() )
On Fri, Apr 25, 2008 at 01:41:14PM -0500, Robert Kern wrote: As Anne notes, bell-shaped curve, while seemingly generic, usually specifies Gaussians, and Gaussians do not have the properties you need. There are any number of curves which we could (and have) suggested as looking bell-shaped, That's strange. In my field bell-shaped curves means any curve that is centered on one specific point, stricly monotonous for x0 and x0, positiv, and with a finite maximum. For instance a Lorentzian is a bell-shaped curve. This shows that you can easily get strong miss-comprehension between fields. Cheers, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generating Bell Curves (was: Using normal() )
On Fri, Apr 25, 2008 at 1:25 PM, Rich Shepard [EMAIL PROTECTED] wrote: On Fri, 25 Apr 2008, Charles R Harris wrote: You can use something like f(x) = (1-x**2)**2 , which has inflection points and vanishes at +/- 1. Any of the B-splines will also do the trick. Chuck, Thank you. I need to make some time to understand the B-splines to use them appropriately. Unfortunately, my mathematical statistics learning was many years in the past ... but we had moved ahead of writing on clay tablets by that time. Not needing to retain that knowledge for many years means it was replaced by more pressing current knowledge. The B-splines do look promising, though. Here's a B-spline approximation to a Gaussian: http://www.doc.ic.ac.uk/~dfg/AndysSplineTutorial/BSplines.html Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generating Bell Curves (was: Using normal() )
Another suggestion from machine learning stuff to throw into the mix: A soft step function that we use often is y = e^(ax) / ( 1 + e^(ax)). It has the nice property that the result y is always in (0,1). If you invert this, you get x = -(1/a)*log(y - 1); this maps (0,1) to the whole real line, and the a parameter controls how sharp that mapping is. Now use that as the input to a Gaussian, and you can get a soft truncation at (0,1). Additionally, you can do this twice to have more control over the shape of the resulting distribution. I suspect the resulting kurtosis/skew factors would be calculable. This has the advantage of giving you a calculable pdf (just normalize the resulting distribution using the inverse det-of-Jacobian factor) without too much hassle. Furthermore, it should be easy to fit the parameters to data without too much difficulty (though I haven't tried). Just a thought, though I've never worked with all this much so I can't say for sure how well it would work. --Hoyt On Fri, Apr 25, 2008 at 4:39 PM, Charles R Harris [EMAIL PROTECTED] wrote: On Fri, Apr 25, 2008 at 1:25 PM, Rich Shepard [EMAIL PROTECTED] wrote: On Fri, 25 Apr 2008, Charles R Harris wrote: You can use something like f(x) = (1-x**2)**2 , which has inflection points and vanishes at +/- 1. Any of the B-splines will also do the trick. Chuck, Thank you. I need to make some time to understand the B-splines to use them appropriately. Unfortunately, my mathematical statistics learning was many years in the past ... but we had moved ahead of writing on clay tablets by that time. Not needing to retain that knowledge for many years means it was replaced by more pressing current knowledge. The B-splines do look promising, though. Here's a B-spline approximation to a Gaussian: http://www.doc.ic.ac.uk/~dfg/AndysSplineTutorial/BSplines.html Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- +++ Hoyt Koepke UBC Department of Computer Science http://www.cs.ubc.ca/~hoytak/ [EMAIL PROTECTED] +++ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] prerelease proposal for matrix behavior
OK, we are not converging in time for the release. So can we at least raise a TypeError on scalar indexing of matrices, so that we remain free to choose the ultimate behavior? Those who have spoke up have generally favored letting x[0] return a 1d array, if I count correctly. And I think that is the right provisional behavior. (As well as ultimate.) But many have not spoken up. So let's at least signal that this is an area of change. Right? Thank you, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 2D array to 3D
Hi All. Is there a easy way to insert 1D(j) array into another 2D array(B:jxk) and conver B to B:ixjxk ? ex:) from numpy import * a=arange(4) a array([0, 1, 2, 3]) b=arange(9) b.shape=3,3 b array([[0, 1, 2], [3, 4, 5], [6, 7, 8]]) I just wanna insert A into B B:1x3x3, [[[ 0, 1, 2, 3], [ 4, 5, 6, 7], [ 8, 9, 10, 11]] B:2x3x3, [[[ 0, 1, 2, 3], [ 4, 5, 6, 7], [ 8, 9, 10, 11]] [[ 0, 1, 2, 3], [ 4, 5, 6, 7], [ 8, 9, 10, 11]]] B:3x3x3, [[[ 0, 1, 2, 3], [ 4, 5, 6, 7], [ 8, 9, 10, 11]] [[ 0, 1, 2, 3], [ 4, 5, 6, 7], [ 8, 9, 10, 11]] [[ 0, 1, 2, 3], [ 4, 5, 6, 7], [ 8, 9, 10, 11]]] Thanks for your help ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] prerelease proposal for matrix behavior
On Fri, Apr 25, 2008 at 6:38 PM, Alan G Isaac [EMAIL PROTECTED] wrote: OK, we are not converging in time for the release. So can we at least raise a TypeError on scalar indexing of matrices, so that we remain free to choose the ultimate behavior? Those who have spoke up have generally favored letting x[0] return a 1d array, if I count correctly. And I think that is the right provisional behavior. (As well as ultimate.) But many have not spoken up. That would be the most compatible with arrays, but won't it break a lot of code? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] prerelease proposal for matrix behavior
Alan G Isaac wrote: OK, we are not converging in time for the release. So can we at least raise a TypeError on scalar indexing of matrices, so that we remain free to choose the ultimate behavior? I think this is wise for the time being. At this point, I'm leaning in the direction of the RowVector / ColumnVector approach (even if these are not really advertised and just used during indexing). -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] prerelease proposal for matrix behavior
On Sat, Apr 26, 2008 at 10:27 AM, Charles R Harris [EMAIL PROTECTED] wrote: On Fri, Apr 25, 2008 at 6:38 PM, Alan G Isaac [EMAIL PROTECTED] wrote: OK, we are not converging in time for the release. So can we at least raise a TypeError on scalar indexing of matrices, so that we remain free to choose the ultimate behavior? Those who have spoke up have generally favored letting x[0] return a 1d array, if I count correctly. And I think that is the right provisional behavior. (As well as ultimate.) But many have not spoken up. That would be the most compatible with arrays, but won't it break a lot of code? Any change to the behavior of x[0] for matrices is going to break a lot of code. It actually seems like a good idea to me to make it an error for a while -- or maybe some kind of settable option -- to help people figure out where they need to fix their code. Better to get an error immediately. --bb ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] OSX installer: please test
There is also a gui, Disk Utility.app which is what I used for the installer. Chris On Fri, Apr 25, 2008 at 2:17 AM, Sebastian Haase [EMAIL PROTECTED] wrote: OT: How do you make a dmg ? Is there a (simple) command line tool for this ? Thanks, Sebastian Haase On Fri, Apr 25, 2008 at 1:35 PM, Christopher Barker [EMAIL PROTECTED] wrote: David Cournapeau wrote: To get to your point: hdiutil is the command you are looking for. yup. Here's an example: hdiutil create -srcfolder YourDir -volname A Name -ov Something.dmg It will build a disk image from the directory: YourDir -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 [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- Christopher Burns 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] Movement of ma breaks matplotlib
Hi, In the upcoming release of numpy. numpy.core.ma ceases to exist. One must use numpy.ma (for the new interface) or numpy.oldnumeric.ma (for the old interface). This has the unfortunate effect of breaking matplotlib(which does from numpy.core.ma import *) - I cannot even import pylab with a stock matplotlib (0.90.1) and an SVN numpy. Is this an intended effect? Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Movement of ma breaks matplotlib
On Fri, Apr 25, 2008 at 11:19 PM, Anne Archibald [EMAIL PROTECTED] wrote: Hi, In the upcoming release of numpy. numpy.core.ma ceases to exist. One must use numpy.ma (for the new interface) or numpy.oldnumeric.ma (for the old interface). This has the unfortunate effect of breaking matplotlib(which does from numpy.core.ma import *) - I cannot even import pylab with a stock matplotlib (0.90.1) and an SVN numpy. Is this an intended effect? IIRC, there was something about this on the MPL mailing list. I think you need to go to a later version, or something like that. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
