Re: [Numpy-discussion] matrix wart
On Thu, Feb 21, 2008 at 07:10:24PM -0500, Alan G Isaac wrote:
On Thu, Feb 21, 2008 at 12:08:32PM -0500, Alan G Isaac wrote:
a matrix behavior that I find bothersome and unnatural::
M = N.mat('1 2;3 4')
M[0]
matrix([[1, 2]])
M[0][0]
matrix([[1, 2]])
On Fri, 22 Feb 2008, Stefan van der Walt apparently wrote:
This is exactly what I would expect for matrices: M[0] is
the first row of the matrix.
Define what first row means!
There is no standard definition that says this is means the
**submatrix** that can be created from the first row.
Someone once pointed out on this list that one might
consider a matrix to be a container of 1d vectors. For NumPy,
however, it is natural that it be a container of 1d arrays.
(See the discussion for the distinction.)
Could you explain to me how you'd like this to be fixed? If the
matrix becomes a container of 1-d arrays, then you can no longer
expect
x[:,0]
to return a column vector -- which was one of the reasons the matrix
class was created. While not entirely consistent, one workaround
would be to detect when a matrix is a vector, and then do 1-d-like
indexing on it.
You expect this matrix behavior only from experience with it,
which is why I expect it too, while hating it.
No, really, I don't ever use the matrix class :) But it is not like
the behaviour is set in stone, so I would spend less time hating and
more time patching.
The example really speaks for itself. Since Konrad is an extremely
experienced user/developer, his reaction should speak volumes.
Of course, I meant no disrespect to Konrad. I'm just trying to
understand the best way to address your concern.
Regards
Stefan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] change memmap.sync function
On Thu, Feb 21, 2008 at 04:17:26PM -0800, Christopher Burns wrote: Would anyone oppose deprecating the memmap.sync function and replacing it with memmap.flush? This would match python's mmap module, and I think be more intuitive. I made the change in http://projects.scipy.org/scipy/numpy/changeset/4817 If anyone objects, please revert. Chris, hope you don't mind that I went ahead so long -- I committed before noticing that you were working on the module earlier. Then again, you guys are probably all in bed by now! Cheers Stefan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Matching 0-d arrays and NumPy scalars
A Friday 22 February 2008, Stefan van der Walt escrigué: Hi Travis, On Wed, Feb 20, 2008 at 10:14:07PM -0600, Travis E. Oliphant wrote: In writing some generic code, I've encountered situations where it would reduce code complexity to allow NumPy scalars to be indexed in the same number of limited ways, that 0-d arrays support. For example, 0-d arrays can be indexed with * Boolean masks I've tried to use this before, but an IndexError (0-d arrays can't be indexed) is raised. Yes, that's true, and what's more, you can't pass a slice to a 0-d array, which is certainly problematic. I think this should be fixed. * Ellipses x[...] and x[..., newaxis] This, especially, seems like it could be very useful. Well, if you want to create a x[..., newaxis], you can always use array([x]), which also works with scalars (and python scalars too), although the later does create a copy :-/ Could I ask that we also consider implementing len() for 0-d arrays? numpy.asarray returns those as-is, and I would like to be able to handle them just as I do any other 1-dimensional array. I don't know if a length of 1 would be valid, given a shape of (), but there must be some consistent way of handling them. If 0-d arrays are going to be indexable, then +1 for len(0-d) returning 1. Cheers, -- 0,0 Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data - ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] ufunc for user-defined type
Now that I have my user-defined type, I want to add some funcs. According to the numpy book, I need to use: PyUFunc_RegisterLoopForType The book says I first need a ufunc. The only way I see to create one is PyUFunc_FromFuncAndData. Is the the correct procedure? I wonder, because PyUFunc_FromFuncAndData requires 'type', and 'type' is char, but user-defined types start at 256, which doesn't fit in a char, which gives a compile warning. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
On Thu, Feb 21, 2008 at 12:08:32PM -0500, Alan G Isaac
wrote:
a matrix behavior that I find bothersome and unnatural::
M = N.mat('1 2;3 4')
M[0]
matrix([[1, 2]])
M[0][0]
matrix([[1, 2]])
On Fri, 22 Feb 2008, Stefan van der Walt apparently wrote:
Could you explain to me how you'd like this to be fixed? If the
matrix becomes a container of 1-d arrays, then you can no longer
expect x[:,0] to return a column vector -- which was one
of the reasons the matrix class was created. While not
entirely consistent, one workaround would be to detect
when a matrix is a vector, and then do 1-d-like indexing
on it.
Letting M be a matrix and A=M.A, and i and j are integers.
I would want two principles to be honored.
1. ordinary Python indexing produces unsurprising results,
so that e.g. M[0][0] returns the first element of the matrix
2. indexing that produces a 2-d array when applied to A
will produce the equivalent matrix when applied to M
There is some tension between these two requirements,
and they do not address your specific example.
Various reconciliations can be imagined.
I believe a nice one can be achieved with
a truly minimal change, as follows.
Let M[i] return a 1d array. (Unsurprising!)
This is a change: a matrix becomes a container
of arrays (e.g., when iterating).
Let M[:,i] and M[i,:] behave as now.
In addition, as a consistency measure, one might
ask that M[i,j] return a 1 x 1 matrix. (This is
of secondary importance, but it follows the
principle that the use of multiple indexes
produces matrices.)
Right now I'm operating on caffeine instead of sleep,
but that looks right ...
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
Konrad Hinsen wrote: On 22.02.2008, at 01:10, Alan G Isaac wrote: Someone once pointed out on this list that one might consider a matrix to be a container of 1d vectors. For NumPy, however, it is natural that it be a container of 1d arrays. (See the discussion for the distinction.) If I were to design a Pythonic implementation of the mathematical concept of a matrix, I'd implement three classes: Matrix, ColumnVector, and RowVector. It would work like this: m = Matrix([[1, 2], [3, 4]]) m[0, :] -- ColumnVector([1, 3]) m[:, 0] -- RowVector([1, 2]) These seem backward to me.I would think that m[0,:] would be the RowVector([1,2]) and m[:,0] be the ColumnVector([1,3]). m[0,0] -- 1 # scalar m.shape -- (2, 2) m[0].shape -- (2,) What is m[0] in this case? The same as m[0, :]? However, the matrix implementation in Numeric was inspired by Matlab, where everything is a matrix. But as I said before, Python is not Matlab. It should be kept in mind, however, that Matlab's matrix object is used successfully by a lot of people and should not be dismissed as irrelevant. I would like to see an improved Matrix object as a built-in type (for 1.1). I am aware of two implementations that could be referred to in creating it: CVXOPT's matrix object and NumPy's matrix object. There may be others as well. If somebody has strong feelings about this sufficient to write a matrix built-in, then the door is wide open. Best, -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
Could you explain to me how you'd like this to be fixed? If the matrix becomes a container of 1-d arrays, then you can no longer expect x[:,0] to return a column vector -- which was one of the reasons the matrix class was created. While not entirely consistent, one workaround would be to detect when a matrix is a vector, and then do 1-d-like indexing on it. Letting M be a matrix and A=M.A, and i and j are integers. I would want two principles to be honored. 1. ordinary Python indexing produces unsurprising results, so that e.g. M[0][0] returns the first element of the matrix 2. indexing that produces a 2-d array when applied to A will produce the equivalent matrix when applied to M There is some tension between these two requirements, and they do not address your specific example. Various reconciliations can be imagined. I believe a nice one can be achieved with a truly minimal change, as follows. Let M[i] return a 1d array. (Unsurprising!) This is a change: a matrix becomes a container This is a concrete proposal and I don't immediately have a problem with it (other than it will break code and so must go in to 1.1). Let M[:,i] and M[i,:] behave as now. Some would expect M[i,:] and M[i] to be the same thing, but I would be willing to squelsh those expectations if many can agree that M[i] should return an array. In addition, as a consistency measure, one might ask that M[i,j] return a 1 x 1 matrix. (This is of secondary importance, but it follows the principle that the use of multiple indexes produces matrices.) I'm pretty sure that wasn't the original principle, but again this is not unreasonable. Right now I'm operating on caffeine instead of sleep, but that looks right ... Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
On Fri, 22 Feb 2008, Stefan van der Walt apparently wrote: This is exactly what I would expect for matrices: M[0] is the first row of the matrix. Define what first row means! Konrad has shown that do get it right you really have to introduce three separate things (matrices, row vectors, and column vectors). This is a fine direction to proceed in, but it does complicate things as well. The current implementation has the advantage that row vectors are just 1xN matrices and column vectors are Nx1 matrices, so there is only 1 kind of thing: matrices. The expectation that M[0][0] and M[0,0] return the same thing stems from believing that all objects using [] syntax are just containers. (Think of a dictionary with keys, '0', and '(0,0)' for an example). The matrix object is not a container object. A NumPy array, however, is. They have different behaviors, on purpose. If you don't like the matrix object, then just use the NumPy array. There are situations, however, when the matrix object is very useful. I use it in limited fashion to make expressions easier to read. Imagine if a 2d array behaved this way. Ugh! Note that it too is 2d; you could have the same expectation based on its 2d-ness. Why don't you? The 2d-ness is not the point. The point is that a matrix object is a matrix object and *not* a generic container. Nobody has objected to returning matrices when getitem is fed multiple arguments: these are naturally interpreted as requests for submatrices. M[0][0] and M[:1,:1] are very different kinds of requests: the first should return the 0,0 element but does not, while M[0,0] does! Bizarre! How to guess?? If you teach, do your students expect this behavior? Mine don't! Again, stop believing that M[0][0] and M[0,0] should return the same thing. There is nothing in Python that requires this. As far as I know, the matrix object is consistent. It may not behave as you, or people that you teach, would expect, but it does have reasonable behavior.Expectations are generally learned based on previous experience. Our different experiences will always lead to different expectations. What somebody expects for a matrix behavior will depend on how they were taught what it means to be a matrix. This is a wart. I disagree. It's not a wart, it is intentional. The example really speaks for itself. Since Konrad is an extremely experienced user/developer, his reaction should speak volumes. I'm not as convinced by this kind of argument. I respect Konrad a great deal and am always interested to hear his opinion, and make use of all of the code that he shares with us. His example has been an important part of my Python education. However, we do approach problems differently (probably again based on previous experiences) which leads us to promote different solutions.I also see this in the wider Python community where there is a diversity of user/developers who promote different approaches as well (e.g. the PIL vs NumPy concept of Images comes to mind as well). I've heard many differing points of view on the Matrix object. Stefan's comment is most relevant: the Matrix object can be changed (in 1.1), especially because we are keen on merging CVXOPT's matrix object with NumPy's and making it a builtin type. -Travis O. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
On Fri, 22 Feb 2008, Travis E. Oliphant apparently wrote: The point is that a matrix object is a matrix object and not a generic container. I see the point a bit differently: there are costs and benefits to the abandonment of a specific and natural behavior of containers. (The kind of behavior that arrays have.) The costs outweigh the benefits. stop believing that M[0][0] and M[0,0] should return the same thing. There is nothing in Python that requires this. I never suggested there is. My question how to guess? does not imply that. My point is: the matrix object could have more intuitive behavior with no loss of functionality. Or so it seems to me. See my other post. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
Alan G Isaac wrote: stop believing that M[0][0] and M[0,0] should return the same thing. There is nothing in Python that requires this. I never suggested there is. My question how to guess? does not imply that. My point is: the matrix object could have more intuitive behavior with no loss of functionality. Do I understand correctly, that by intuitive you mean based on experience with lists, and NumPy arrays?I agree, it is very valuable to be able to use previous understanding to navigate a new thing. That's a big part of why I could see changing the matrix object in 1.1 to behave as you described in your previous post: where M[i] returned a 1-d array and matrices were returned with 2-d (slice-involved) indexing (I would not mind M[0,0] to still return a scalar, however). -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ufunc for user-defined type
Neal Becker wrote: Now that I have my user-defined type, I want to add some funcs. According to the numpy book, I need to use: PyUFunc_RegisterLoopForType The book says I first need a ufunc. The only way I see to create one is PyUFunc_FromFuncAndData. Is the the correct procedure? You'll have to do some digging because the API allowing low-level loops for user-defined types is not well tested or vetted. Also, don't be surprised if you uncover some bugs. The concept is that you create the UFunc with the built-in types using PyUFunc_FromFuncAndData and then you add loops for the user-defined type using RegisterLoopForType. So, you have the basic procedure down. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
On Fri, 22 Feb 2008, Travis E. Oliphant apparently wrote: Do I understand correctly, that by intuitive you mean based on experience with lists, and NumPy arrays? Yes. In particular, array behavior is quite lovely and almost never surprising, so matrices should deviate from it only when there is an adequate payoff and, ideally, an easily stated principle. Thanks! Alan PS If you choose to implement such changes, I would find M[0,0] returning a 1×1 matrix to be more consistent, but to be clear, for me this is *very* much a secondary issue. Not even in the same ballpark. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
Travis E. Oliphant wrote: to behave as you described in your previous post: where M[i] returned a 1-d array My thoughts on this: As Konrad suggested, row vectors and column vectors are different beasts ,and both need to be easily and intuitively available. M[i] returning a 1-d array breaks this -- that's what raw numpy arrays do, and I like it, but it's not so natural for linear algebra. If we really want to support matrixes, then no, M[i] should not return a 1-d array -- what is a 1-d array mean in the matrix/linear algebra context? It makes me think that M[i] should not even be possible, as you would always want one of: row vector: M[i,:] column vector: M[:,i] element: M[i,j] I do like the idea of a row/column vectors being different objects than matrices, then you could naturally index the elements from them. If you really want a 1-d array, you can always do: M.A[i] What if you want to naturally iterate through all the rows, or all the columns? what about: for row in M.rows for column in M.columns M.rows and M.columns would be iterators. -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
[Numpy-discussion] cmp_arg_types bug?
cmp_arg_types(int *arg1, int *arg2, int n)
{
while (n--) {
if (PyArray_EquivTypenums(*arg1, *arg2)) continue;
if (PyArray_CanCastSafely(*arg1, *arg2))
return -1;
return 1;
}
return 0;
}
IIUC, if can cast (arg1, arg2), we never compare other args, just return -1.
Shouldn't this be:
cmp_arg_types(int *arg1, int *arg2, int n)
{
while (n--) {
if (PyArray_EquivTypenums(*arg1, *arg2) or
(PyArray_CanCastSafely(*arg1, *arg2))
continue;
return 1;
}
return 0;
}
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] cmp_arg_types bug?
Neal Becker wrote:
cmp_arg_types(int *arg1, int *arg2, int n)
{
while (n--) {
if (PyArray_EquivTypenums(*arg1, *arg2)) continue;
if (PyArray_CanCastSafely(*arg1, *arg2))
return -1;
return 1;
}
return 0;
}
IIUC, if can cast (arg1, arg2), we never compare other args, just return
-1.
Shouldn't this be:
cmp_arg_types(int *arg1, int *arg2, int n)
{
while (n--) {
if (PyArray_EquivTypenums(*arg1, *arg2) or
(PyArray_CanCastSafely(*arg1, *arg2))
continue;
return 1;
}
return 0;
}
Oh, better make that:
static int
cmp_arg_types(int *arg1, int *arg2, int n)
{
for (;n 0; n--, ++arg1, ++arg2) {
if (PyArray_EquivTypenums(*arg1, *arg2) ||
PyArray_CanCastSafely(*arg1, *arg2))
continue;
return 1;
}
return 0;
}
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
Alan G Isaac wrote: I propose that the user-friendly question is: why deviate needlessly from array behavior? (Needlessly means: no increase in functionality.) On Fri, 22 Feb 2008, Christopher Barker apparently wrote: because that's the whole point of a Matrix object in the first place. Do you really believe that? As phrased?? (Out of curiosity: do you use matrices?) On Fri, 22 Feb 2008, Christopher Barker apparently wrote: Functionally, you can do everything you need to do with numpy arrays. That is a pretty narrow concept of functionality, which excludes all user convenience aspects. I do not understand why you are introducing it; it seems irrelevant. If you push this line of reasoning, you should just tell me I can do it all in C. On Fri, 22 Feb 2008, Christopher Barker apparently wrote: The only reason there is a matrix class is to create a more natural, and readable way to do linear algebra. That's why the current version always returns matrices -- people don't want to have to keep converting back to matrices from arrays. You are begging the question. Of course we want to be able to conveniently extract submatrices and build new matrices. Nobody has challenged that or proposed otherwise. Or are you complaining that you would have to type M[i,:] instead of M[i]? (No, that cannot be; you were proposing that M[i] be an error...) Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] user-defined types mixed arithmetic
I have 2 user-defined types, and simple arithmetic working for the cases I registered with PyUFunc_RegisterLoopForType. I'd like to use automatic conversion to do mixed arithmetic between these 2 types. I did PyArray_RegisterCastFunc, and it seems this allows explicit conversion: a array([(0,0), (1,0), (2,0), (3,0), (4,0), (5,0), (6,0), (7,0), (8,0), (9,0)], dtype=cmplx_int32) b array([(0,0), (1,0), (2,0), (3,0), (4,0), (5,0), (6,0), (7,0), (8,0), (9,0)], dtype=cmplx_int64) array (a,dtype=b.dtype) array([(0,0), (1,0), (2,0), (3,0), (4,0), (5,0), (6,0), (7,0), (8,0), (9,0)], dtype=cmplx_int64) But mixed mode arithmetic gives: a+b TypeError: function not supported for these types, and can't coerce safely to supported types I've been trying to understand this 'coerce' without much luck. Any clues what I need to do here? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Matching 0-d arrays and NumPy scalars
Travis, after reading all the post on this thread, my comments Fist of all, I'm definitelly +1 on your suggestion. Below my rationale. * I believe numpy scalars should provide all possible features needed to smooth the difference between mutable, indexable 0-d arrays and inmutable, non-indexable builtin Python numeric types. * Given that in the context of generic multi-dimensional array processing a 0-d array are more natural and useful concept that a Python 'int' and 'float', I really think that numpy scalars shoud follow as much as possible the behavior of 0-d arrays (of course, retaining inmutability). * Numpy scalars already have (thanks for that!) a very, very similar API to ndarrays. You can as for 'size', 'shape', etc ( BTW, why scalar.fill(x) does not generate any error). Why do not add indexing as well? * However, I'm not sure about the proposal of supporting len(), I'm -0 on this point. Anyway, if this is added, then 0-d arrays should also have to support it. And then... len(scalar) or len(0-d-array) is going to return 0 (zero)? Regards. On 2/21/08, Travis E. Oliphant [EMAIL PROTECTED] wrote: In writing some generic code, I've encountered situations where it would reduce code complexity to allow NumPy scalars to be indexed in the same number of limited ways, that 0-d arrays support. For example, 0-d arrays can be indexed with * Boolean masks * Ellipses x[...] and x[..., newaxis] * Empty tuple x[()] I think that numpy scalars should also be indexable in these particular cases as well (read-only of course, i.e. no setting of the value would be possible). This is an easy change to implement, and I don't think it would cause any backward compatibility issues. Any opinions from the list? Best regards, -Travis O. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Faster array version of ndindex
Could you provide more details about this to the ticket I created based on your email: http://projects.scipy.org/scipy/numpy/ticket/636 Thanks, On Thu, Dec 13, 2007 at 3:33 PM, Jonathan Taylor [EMAIL PROTECTED] wrote: I was needing an array representation of ndindex since ndindex only gives an iterator but array(list(ndindex)) takes too long. There is prob some obvious way to do this I am missing but if not feel free to include this code which is much faster. In [252]: time a=np.array(list(np.ndindex(10,10,10,10,10,10))) CPU times: user 11.61 s, sys: 0.09 s, total: 11.70 s Wall time: 11.82 In [253]: time a=ndtuples(10,10,10,10,10,10) CPU times: user 0.32 s, sys: 0.21 s, total: 0.53 s Wall time: 0.60 def ndtuples(*dims): Fast implementation of array(list(ndindex(*dims))). # Need a list because we will go through it in reverse popping # off the size of the last dimension. dims = list(dims) # N will keep track of the current length of the indices. N = dims.pop() # At the beginning the current list of indices just ranges over the # last dimension. cur = np.arange(N) cur = cur[:,np.newaxis] while dims != []: d = dims.pop() # This repeats the current set of indices d times. # e.g. [0,1,2] - [0,1,2,0,1,2,...,0,1,2] cur = np.kron(np.ones((d,1)),cur) # This ranges over the new dimension and 'stretches' it by N. # e.g. [0,1,2] - [0,0,...,0,1,1,...,1,2,2,...,2] front = np.arange(d).repeat(N)[:,np.newaxis] # This puts these two together. cur = np.column_stack((front,cur)) N *= d return cur ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- 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] numpy 1:1.0.4: numpy.average() returns the wrong result with weights
Hi, more details in this bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467095 The bug report offers a fix for this problem. It seems to me this is not fixed even in the latest svn. Thanks, Ondrej ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Problems installing numpy on Mac OS 10.4
I'm trying to install numpy 1.0.4 on my Intel MacBook Pro with Mac OS 10.4
and running Python 2.5. When I run python setup.py build I get the
errors below. Is this a compatibility issue?:
Running from numpy source directory.
non-existing path in 'numpy/distutils': 'site.cfg'
F2PY Version 2_4422
blas_opt_info:
FOUND:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
extra_compile_args = ['-faltivec',
'-I/System/Library/Frameworks/vecLib.framework/Headers']
lapack_opt_info:
FOUND:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
extra_compile_args = ['-faltivec']
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands
--compiler options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands
--fcompiler options
running build_src
building py_modules sources
building extension numpy.core.multiarray sources
Generating build/src.macosx-10.3-fat-2.5/numpy/core/config.h
customize NAGFCompiler
Could not locate executable f95
customize AbsoftFCompiler
Could not locate executable f90
Could not locate executable f77
customize IBMFCompiler
Could not locate executable xlf90
Could not locate executable xlf
customize IntelFCompiler
Could not locate executable ifort
Could not locate executable ifc
customize GnuFCompiler
Could not locate executable g77
customize Gnu95FCompiler
Could not locate executable gfortran
customize G95FCompiler
Could not locate executable g95
SystemError: Failed to test configuration. See previous error messages for
more information.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems installing numpy on Mac OS 10.4
On Fri, Feb 22, 2008 at 6:57 PM, Alex Donaldson [EMAIL PROTECTED] wrote: I'm trying to install numpy 1.0.4 on my Intel MacBook Pro with Mac OS 10.4 and running Python 2.5. When I run python setup.py build I get the errors below. Is this a compatibility issue?: I don't know. Please provide the entire output. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy 1:1.0.4: numpy.average() returns the wrong result with weights
Ondrej Certik wrote: Hi, more details in this bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467095 The bug report offers a fix for this problem. It seems to me this is not fixed even in the latest svn. Is there a ticket on the NumPy trac for this? We won't see it if there isn't. Thanks for pointing us to the bug. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy 1:1.0.4: numpy.average() returns the wrong result with weights
On Sat, Feb 23, 2008 at 2:10 AM, Travis E. Oliphant [EMAIL PROTECTED] wrote: Ondrej Certik wrote: Hi, more details in this bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467095 The bug report offers a fix for this problem. It seems to me this is not fixed even in the latest svn. Is there a ticket on the NumPy trac for this? We won't see it if there isn't. Thanks for pointing us to the bug. I'll add it. I registered on the trac, as required, but I am still denied, when filling my username and password when logging in. How can I create an account? Ondrej ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy 1:1.0.4: numpy.average() returns the wrong result with weights
Ondrej Certik wrote: On Sat, Feb 23, 2008 at 2:10 AM, Travis E. Oliphant [EMAIL PROTECTED] wrote: Ondrej Certik wrote: Hi, more details in this bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467095 The bug report offers a fix for this problem. It seems to me this is not fixed even in the latest svn. Is there a ticket on the NumPy trac for this? We won't see it if there isn't. Thanks for pointing us to the bug. I'll add it. I registered on the trac, as required, but I am still denied, when filling my username and password when logging in. How can I create an account? That should have done it. When you say you are denied, exactly what happens? I've run into times when I've logged in and I get the unaltered front page again. Logging in again usually works. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems installing numpy on Mac OS 10.4
Running from numpy source directory.
non-existing path in 'numpy/distutils': 'site.cfg'
F2PY Version 2_4422
blas_opt_info:
FOUND:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
extra_compile_args = ['-faltivec',
'-I/System/Library/Frameworks/vecLib.framework/Headers']
lapack_opt_info:
FOUND:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
extra_compile_args = ['-faltivec']
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands
--compiler options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands
--fcompiler options
running build_src
building py_modules sources
building extension numpy.core.multiarray sources
Generating build/src.macosx-10.3-fat-2.5/numpy/core/config.h
customize NAGFCompiler
Could not locate executable f95
customize AbsoftFCompiler
Could not locate executable f90
Could not locate executable f77
customize IBMFCompiler
Could not locate executable xlf90
Could not locate executable xlf
customize IntelFCompiler
Could not locate executable ifort
Could not locate executable ifc
customize GnuFCompiler
Could not locate executable g77
customize Gnu95FCompiler
Could not locate executable gfortran
customize G95FCompiler
Could not locate executable g95
don't know how to compile Fortran code on platform 'posix'
C compiler: gcc -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk
-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd
-fno-common -dynamic -DNDEBUG -g -O3
compile options:
'-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-Inumpy/core/src -Inumpy/core/include
-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c'
gcc: _configtest.c
sh: line 1: gcc: command not found
sh: line 1: gcc: command not found
failure.
removing: _configtest.c _configtest.o
Traceback (most recent call last):
File setup.py, line 89, in module
setup_package()
File setup.py, line 82, in setup_package
configuration=configuration )
File /Users/donaldsona/Desktop/numpy-1.0.4/numpy/distutils/core.py,
line 176, in setup
return old_setup(**new_attr)
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/
core.py,
line 151, in setup
dist.run_commands()
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/
dist.py,
line 974, in run_commands
self.run_command(cmd)
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/
dist.py,
line 994, in run_command
cmd_obj.run()
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/
command/build.py,
line 112, in run
self.run_command(cmd_name)
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/
cmd.py,
line 333, in run_command
self.distribution.run_command(command)
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/
dist.py,
line 994, in run_command
cmd_obj.run()
File
/Users/donaldsona/Desktop/numpy-1.0.4/numpy/distutils/command/build_src.py,
line 130, in run
self.build_sources()
File
/Users/donaldsona/Desktop/numpy-1.0.4/numpy/distutils/command/build_src.py,
line 147, in build_sources
self.build_extension_sources(ext)
File
/Users/donaldsona/Desktop/numpy-1.0.4/numpy/distutils/command/build_src.py,
line 250, in build_extension_sources
sources = self.generate_sources(sources, ext)
File
/Users/donaldsona/Desktop/numpy-1.0.4/numpy/distutils/command/build_src.py,
line 307, in generate_sources
source = func(extension, build_dir)
File numpy/core/setup.py, line 53, in generate_config_h
raise SystemError,Failed to test configuration. \
SystemError: Failed to test configuration. See previous error messages for more
information.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems installing numpy on Mac OS 10.4
Alex Donaldson wrote: compile options: '-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -Inumpy/core/src -Inumpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c' gcc: _configtest.c sh: line 1: gcc: command not found This is your problem. You need to install the Developer Tools. I believe they are included on your OS X 10.4 installation DVD. Alternatively, you can download them from Apple: http://developer.apple.com/tools/download/ You will need Xcode 2.5. You will need to register (for free) to be part of the Apple Developer Connection. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix wart
Alan G Isaac wrote: On Fri, 22 Feb 2008, Christopher Barker apparently wrote: because that's the whole point of a Matrix object in the first place. Do you really believe that? As phrased?? yes -- the matrix object is about style, not functionality -- not that style isn't important (Out of curiosity: do you use matrices?) No. In fact, that's one of the reasons I was overjoyed to find Numeric after using Matlab for along time -- I hardly ever need linear algebra, what I need is n-d arrays. So, yes, I should just shut up and leave the discussion to those that really want to use them. I will note, however, that in reading this list for years, I haven't found that many people really do want matrices -- they are asked for a lot by Matlab converts, then often the users find that they can more easily do what they want with arrays after all. Maybe that's because the Matrix API needs improvement, so I guess what we really need is someone that really wants them to champion the cause. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy 1:1.0.4: numpy.average() returns the wrong result with weights
On 22/02/2008, Travis E. Oliphant [EMAIL PROTECTED] wrote: Is there a ticket on the NumPy trac for this? We won't see it if there isn't. Thanks for pointing us to the bug. It appears to be fixed in SVN (that was quick!). But the Debian bug report also points out a peculiar unnecessary use of eval; the code is also slower and uses more memory than it has to. Attached is a patch to cure that. Anne Index: numpy/lib/function_base.py === --- numpy/lib/function_base.py (revision 4819) +++ numpy/lib/function_base.py (working copy) @@ -378,9 +378,9 @@ ni = len(ash) r = [newaxis]*ni r[axis] = slice(None, None, 1) -w1 = eval(w[+repr(tuple(r))+]*ones(ash, float)) -n = add.reduce(a*w1, axis) -d = add.reduce(w1, axis) +r = tuple(r) +n = add.reduce(a*w[r], axis) +d = add.reduce(w, axis) else: raise ValueError, 'averaging weights have wrong shape' ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
