Re: [Numpy-discussion] matrix multiply
On Sun, 6 Apr 2008, Charles R Harris wrote: The boolean algebra is a field and the correct addition is xor, which is the same as addition modulo 2. This makes all matrices with determinant 1 invertible. This isn't the current convention, however, as it was when Caratheodory was writing on measures and rings of sets were actually rings and the symmetric difference was used instead of union. I am not sure what you are suggesting for matrix behavior, nor what correct means here. Comment: Standard *boolean algebra* axioms include distributivity, but 1 xor (0 and 0) = 1 xor 0 = 1 (1 xor 0) and (1 xor 0) = 1 and 1 = 1 So I guess (?) what you are saying is something like: if we have a boolen algebra with operators 'and' and 'or', we can generate a boolean ring with operations 'xor' and 'and'. When we do so, the '+' is traditionally used for the 'xor' operation. But where in the modern literature on boolean matrices is '+' given this interpretation? IANAM,* Alan Isaac * IANAM = I am not a mathematician. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix multiply
On Sun, 6 Apr 2008, Anne Archibald apparently wrote: I am not aware of any algorithm for finding inverses, or even determining which matrices are invertible, in the peculiar Boolean arithmetic we use. Again, it is *not* peculiar, it is very standard for boolean matrices. And with this behavior, a nonnegative integer power has an obvious graph theoretic interpretation. Such boolean matrices are obviously invertible if they are orthogonal. It turn out this is a necessary condition as well. [1]_ Orthogonality is obviously easy to test. Cheers, Alan Isaac .. [1] Luce, D., 1952, A Note on Boolean Matrix Theory, Proceeding of the Am. Math. Soc 3(3), p.382-8. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix multiply
On Sun, 6 Apr 2008, Charles R Harris apparently wrote: I prefer the modern usage myself as it is closer to the accepted logic operations, but applying algebraic manipulations like powers and matrix inverses in that context leads to strange results. I have not really thought much about inverses, but nonnegative integer powers have a natural interpretation in graph theory (with the boolean algebra operations, not the boolean ring operations). This is exactly what I was requesting be preserved. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix multiply
On Sun, 6 Apr 2008, Charles R Harris apparently wrote: You mean as edges in a directed graph? Yes. Naturally a boolean matrix is not the most compact representation of a directed graph, especially a sparse one. However it can be convenient. If B is a boolean matrix such that Bij=1 if there is and edge from i to j, then B**2 has unit entries where there is a path of length 2 from i to j. The transitive closure is similarly easy to represent (as a matrix power). Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote: I really thing numpy should be as thin as possible, so that you can really say that it is only an array manipulation package. This will also make it easier to sell as a core package for developpers who do not care about calculator features. I'm a user rather than a developer, but I wonder: is this true? 1. Even as a user, I agree that what I really want from NumPy is a core array manipulation package (including matrices). BUT as long as this is the core of NumPy, will a developer care if other features are available? 2. Even if the answer to 1. is yes, could the build/installation process include an option not to build/install anything but the core array functionality? 3. It seems to me that pushing things out into SciPy remains a problem: a basic NumPy is easy to build on any platform, but SciPy still seems to generate many questions. 4. One reason this keeps coming up is that he NumPy/SciPy split is rather too crude. If the split were instead something like NumPy/SciPyBasic/SciPyFull/SciPyFull+Kits where SciPyBasic contained only pure Python code (no extensions), perhaps the desired location would be more obvious and some of this recurrent discussion would go away. fwiw, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] newbie doubt about dot()
On Tue, 1 Apr 2008, harryos apparently wrote: i need to calculate wk=uk o (L-Psi) where uk=a vector of size (1 X N^2) o =scalar product l,Psi=vectors of (N^2 X 1) i have an ndarray U of shape(M X N^2)where uk is one of the rows , and L of shape (M X N^2) where l.transpose() is one of the rows, Your explanation is not fully clear to me, but perhaps the following will help. #dummy values rows = 2 cols = 3*3 U = numpy.ones((rows,cols)) + [[0],[1]] L = numpy.random.random((rows,cols)) - 0.5 Psi = numpy.ones((cols,1)) #computation numpy.dot(U,L.transpose() - Psi) hth, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] greedy loadtxt
On Thu, 27 Mar 2008, lorenzo bolla apparently wrote: I realized that numpy.loadtxt do not read the last character of an input file. This is annoying if the input file do not end with a newline. I believe Robert fixed this; update from the SVN repository. hth, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] accumarray
On Wed, Mar 26, 2008 at 5:20 PM, Gabriel J.L. Beckers [EMAIL PROTECTED] wrote: Does numpy have something like Matlab's accumarray? http://www.mathworks.com/access/helpdesk/help/techdoc/ref/accumarray.html On Wed, 26 Mar 2008, Robert Kern apparently wrote: No. But of course you can do things like (1d example) vals[subs==2].sum() Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Sat, 22 Mar 2008, Stéfan van der Walt apparently wrote: maybe you can post a link as a reminder URL:http://projects.scipy.org/pipermail/numpy-discussion/2008-February/031548.html In the matrix world, everything has a minimum dimension of 2, so I don't see how you can contain ndarrays in a matrix. Are you trying to suggest that in most matrix programming languages if you extract a row you will then need to use two indices to extract an element of that row? This does not match my experience. I would ask you to justify that by listing the languages you have in mind. Additionally, you surely see how you can do this. But as someone who does not use matrices much, you have an *abstract* objection to allowing this desirable functionality. (As far as I can tell, this objection is grounded in how you have chosen to think about matrices as mathematical objects, but nothing in the math implies your objection.) Provocatively, I might boil your position down to simply asserting that the only thing I should be able to get out of a matrix is a submatrix, and then being willing to break some nice ndarray behavior that would be expected by most new matrix users for no reason other than to enforce your arbitrary assertion. Since you offer NO MORE than an unfounded assertion, there is really no reason to stop me from e.g. getting the i,j-th element of a matrix as M[i][j]. Instead you want to just break this (which is the current status). Remember, you will still be able to extract the first row of a matrix ``M`` as a **submatrix** using ``M[0,:]``. No functionality would be lost under my proposed change. In short, the behavior change I have requested will - mean that habits formed using ndarrays transfer naturally to the use of matrices - increase functionality without removing any functionality Breaking the nice behavior of ndarrays should have a really strong justification. No real justification has been given for breaking e.g. the ability to use M[i] to get the i-th row as an array or M[i][j] to get the i,j-th element. Oddly, the weak justifications that have been offered have been offered by people who make little or no use of matrices. This behavior has been broken arbitrarily. The breakage removes useful functionality, adds no new functionality, needlessly decreases similarities between matrices and ndarrays, and thereby surprises new users (e.g., my students) for no good reason. As a final observation, I will note that status quo bias of course works against making this change, but making this desirable change by 1.1 will be easier than making it later. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Fri, 21 Mar 2008, Nadav Horesh apparently wrote: I would like to see a unification of matrices and arrays. I often do calculation which involve both array processing and linear algebra, and the current solution of having function like dot and inv is not aesthetic. Switching between array and matrix types (or using .A attribute of a matrix) is not convinient either. Use ``asmatrix``. (Does not copy.) After that the only needed unification I have encountered is that iteration over a matrix should return arrays (not matrices). I believe this is under consideration for 1.1. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Fri, 21 Mar 2008, Stéfan van der Walt apparently wrote: The last I remember, we considered adding RowVector, ColumnVector and letting slices out of a matrix either be one of those or a matrix itself. There was a subsequent discussion. I simply don't see a Matrix as a container of ndarrays That is hardly an argument. Remember, any indexing that when applied to an 2d array would produce a 2d array will when applied to a matrix still produce a matrix. This is really just principle of least surprise. Or, if you want a complementary way of looking at it, it is keeping as much of the natural behavior of the ndarray as possible while adding convenient submatrices, matrix multiplication, and inverse. Cheers, Alan Isaac PS Are you a *user* of matrices? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Sat, 22 Mar 2008, Nadav Horesh apparently wrote: A*v ... ValueError: objects are not aligned This is just how I want matrices to act! If A is m׳n, then v should be n׳1 for A*v to be defined. Anything else is trouble waiting to happen. But it seems that Charles's proposal would make life more convenient for you... Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] new question - summing a list of arrays
On Tue, 18 Mar 2008, Chris Withers apparently wrote: Say I have an aribtary number of arrays: arrays = [array([1,2,3]),array([4,5,6]),array([7,8,9])] How can I sum these all together? Try N.sum(arrays,axis=0). But must they be in a list? An array of arrays (i.e., 2d array) is easy to sum. My only solution so far is this: sum = arrays[0] for a in arrays[1:]: sum += a ...which is ugly :-S And changes the first array! Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] newbie question - summing a list of arrays
On Tue, 18 Mar 2008, Chris Withers apparently wrote: Where are the docs for sum? Again: http://www.scipy.org/Numpy_Example_List_With_Doc Really, as a new NumPy user you should just keep this page open in your browser. Also, help(N.sum), of course. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] how to build a series of arrays as I go?
On Mon, 17 Mar 2008, Chris Withers apparently wrote: woefully inadequate state of the currently available free documentation 1. http://www.scipy.org/Numpy_Example_List_With_Doc 2. write some Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] how to build a series of arrays as I go?
Alan suggested: 1. http://www.scipy.org/Numpy_Example_List_With_Doc On Mon, 17 Mar 2008, Chris Withers apparently wrote: Yeah, read that, wood, trees, can't tell the... Oh, then you might want http://www.scipy.org/Tentative_NumPy_Tutorial or the other stuff at http://www.scipy.org/Documentation All in all, I've found the resources quite good. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Transforming an array of numbers to an array of formatted strings
On Thu, 13 Mar 2008, Alexander Michael apparently wrote: I want to format an array of numbers as strings. To what end? Note that tofile has a format option. And for 1d array ``x`` you can always do:: strdata = list( fmt%xi for xi in x) Nice because the counter name does not bleed into your program. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Transforming an array of numbers to an array of formatted strings
2008/3/13, Alan G Isaac [EMAIL PROTECTED]: strdata = list( fmt%xi for xi in x) Nice because the counter name does not bleed into your program. On Thu, 13 Mar 2008, David Huard apparently wrote: ['S%03d'%i for i in int_data] The difference is that the counter bleeds from the list comprehension. I find that obnoxious. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] fromiter + dtype='S' - Python crash
On Thu, 13 Mar 2008, Alexander Michael apparently wrote: I wasn't sure if there was a magic numpy method to do the loop quickly (as the destination array is created beforehand) without creating a temporary Python list, but I guess not. The generator/list-comprehension is likely better than my prototype. Looks like I misunderstood your question: you want an **array** of strings? In principle you should be able to use ``fromiter``, I believe, but it does not work. BUG? (Crasher.) Cheers, Alan Isaac import numpy as N x = [1,2,3] fmt=%03d N.array([fmt%xi for xi in x],dtype='S') array(['001', '002', '003'], dtype='|S3') N.fromiter([xi for xi in x],dtype='float') array([ 1., 2., 3.]) N.fromiter([xi for xi in x],dtype='S') Python crashes. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] fromfunction() bug?
This is how I would hope ``fromfunction`` would work and it matches the docs. (See below.) You can fix the example ... Cheers, Alan Isaac help(N.fromfunction) Help on function fromfunction in module numpy.core.numeric: fromfunction(function, shape, **kwargs) Returns an array constructed by calling a function on a tuple of number grids. The function should accept as many arguments as the length of shape and work on array inputs. The shape argument is a sequence of numbers indicating the length of the desired output for each axis. The function can also accept keyword arguments (except dtype), which will be passed through fromfunction to the function itself. The dtype argument (default float) determines the data-type of the index grid passed to the function. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] preparing to tag NumPy 1.0.5 on Wednesday
Alan G Isaac wrote: I never got a response to this: URL:http://projects.scipy.org/pipermail/scipy-dev/2008-February/008424.html (Two different types claim to be numpy.int32.) On Mon, 03 Mar 2008, Travis E. Oliphant apparently wrote: It's not a bug :-) There are two c-level types that are both 32-bit (on 32-bit systems). OK, but at the user-level it is confusing to have two different types claim the same type name. This produced a fairly obscure program error for Dmitrey. (Not that I am generally a fan of type checking, but still, it was pretty surprising ...) Thanks, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] loadtxt broken if file does not end in newline
On Wed, 27 Feb 2008, Robert Kern apparently wrote: Fixed in r4827. On Wed, Feb 27, 2008 at 6:31 PM, Christopher Barker wrote: For the record, this is the fixed version: comment_start = line.find(comments) if comment_start 0: line = line[:comments_start].strip() else: line = line.strip() Three problems. 1. I do not see this change here: URL:http://svn.scipy.org/svn/numpy/trunk/numpy/core/numeric.py Am I looking in the wrong place? 2. Can I assume this was not cut and past? Otherwise, I see two problems. 2a. comment_start vs. comments_start (spelling) 2b. 0 instead of =0 (e.g., #try me! would not be skipped) So I think the desired lines are actually:: comment_start = line.find(comments) if comment_start = 0: line = line[:comment_start].strip() else: line = line.strip() return line Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Handling of numpy.power(0, something)
On Wed, 27 Feb 2008, Stuart Brorson apparently wrote: ** 0^0: This is problematic. Accessible discussion: URL:http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power Cheers, Alan Isaac ___ 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
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
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
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
Re: [Numpy-discussion] Matching 0-d arrays and NumPy scalars
On Thu, 21 Feb 2008, Konrad Hinsen apparently wrote:
What I see as more fundamental is the behaviour of Python container
objects (lists, sets, etc.). If you add an object to a container and
then access it as an element of the container, you get the original
object (or something that behaves like the original object) without
any trace of the container itself.
I am not a CS type, but your statement seems related to
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]])
I do not think anyone has really defended this behavior,
*but* the reply to me when I suggested that a matrix
contains arrays and we should see that in its behavior
was that, no, a matrix is a container of matrices so this is
what you get.
So a possible problem with your phrasing of the argument
(from a non-CS, user point of view)
is that it fails to address what is actually contained
(as opposed to what you might wish were contained).
Apologies if this proves OT.
Cheers,
Alan Isaac
___
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
On Thu, 21 Feb 2008, Konrad Hinsen apparently wrote: A float64 array is thus a container of float64 values. Well ... ok:: x = N.array([1,2],dtype='float') x0 = x[0] type(x0) type 'numpy.float64' So a float64 value is whatever a numpy.float64 is, and that is part of what is under discussion. So it seems to me. If so, then expected behavior and use cases seem relevant. Alan PS I agree that the posted matrix behavior is weird. For this and other reasons I think it hurts the matrix object, and I have requested that it change ... ___ 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:
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.)
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?
You expect this matrix behavior only from experience with
it, which is why I expect it too, while hating it. It is
not what new users will expect and also not desirable.
As Konrad noted, it is very odd behavior to treat a matrix
as a container of matrices. You can only expect this
behavior by learning to expect it (by use), which is
undesirable.
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!
This is a wart.
The example really speaks for itself. Since Konrad is an
extremely experienced user/developer, his reaction should
speak volumes.
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in numpy.histogram?
On Wed, 20 Feb 2008, John Hunter apparently wrote: File /home/titan/johnh/dev/lib/python2.4/site-packages/numpy/lib/function_base.py, line 155, in histogram if(any(bins[1:]-bins[:-1] 0)): NameError: global name 'any' is not defined ``any`` was introduced in Python 2.5, so you need ``np.any`` here. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] import issue with new Python
On Fri, 15 Feb 2008, Dinesh B Vadhia apparently wrote: I upgraded to Python 2.5.2c1 today, and got the following error for: import numpy import scipy Traceback (most recent call last): File C:\ ... .py, line 19, in module import scipy ImportError: No module named scipy I'm using Numpy 1.0.4 and Scipy 0.6. Any ideas? If you are an Windows, check Lib\site-packages and see if there are there: looks like not. If you did a side-by-side install, you'll have to reinstall SciPy and NumPy on your new Python. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] searchsorted bug
Problem also with Windows P3 binaries. fwiw, Alan Isaac Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import numpy numpy.__version__ '1.0.4' A = numpy.array(['a','aa','b']) B = numpy.array(['d','e']) A.searchsorted(B) array([3, 0]) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix - ndarray bug
On Thu, 31 Jan 2008, dmitrey apparently wrote: already fixed in more recent versions? Yes, at least it's fixed in my 1.0.4. By the way, do you know about the ``A`` attribute of matrices? Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] pre-initialized arrays
On Fri, 4 Jan 2008, Stuart Brorson apparently wrote: I realize NumPy != Matlab, but I'd wager that most users would think that this is the natural behavior. I would not find it natural that elements of my float array could be assigned complex values. How could it be a fixed chunk of memory and do such things, unless it would always waste enough memory to hold the biggest possible subsequent data type? Cheers, Alan Isaac (user) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
On Thu, 3 Jan 2008, Charles R Harris apparently wrote: Isn't it trivially true that all elements of an empty array are close to any number? Sure, but might not one expect a ValueError due to shape mismatch? (Doesn't allclose usually use normal broadcasting rules?) Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
On Thu, 3 Jan 2008, Charles R Harris apparently wrote: Isn't it trivially true that all elements of an empty array are close to any number? On Thu, 3 Jan 2008, Alan G Isaac apparently wrote: Sure, but might not one expect a ValueError due to shape mismatch? (Doesn't allclose usually use normal broadcasting rules?) Ooops, forgot that was a scalar, so it was normal: a*b array([], dtype=int32) Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] how do I list all combinations
On Wed, 26 Dec 2007, Mathew Yeates apparently wrote: r1=[dog,cat] r2=[1,2] I want to return [[dog,1],[dog,2],[cat,1],[cat,2]] This is a Cartesian product. Sage has ``cartesian_product_iterator`` for this. Also URL:http://www.sagemath.org/doc/html/ref/module-sage.combinat.cartesian-product.html Here is a Cookbook implementation. URL:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302478 The generator may be adequate to your needs. Here is a recursive implementation that does not use multi-dimensional indexing: def set_product(*sets): last_set = sets[-1] drop_last = sets[:-1] if drop_last: result = set( x+(y,) for x in set_product(*drop_last) for y in last_set ) else: result = set( (y,) for y in last_set ) return result Sorry for a late reply. I'm catching up on email... Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy installed but can' use
On Sat, 29 Dec 2007, dikshie apparently wrote: so import numpy and from numpy import * are different ? http://docs.python.org/tut/node8.html hth, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] new P3 binaries for NumPy 1.0.4 and SciPy 0.6.0
On Thu, 20 Dec 2007, Jarrod Millman apparently wrote: If you are having problems with NumPy and SciPy on Pentium III machines running Windows, please try the newly released binaries: I used the Python 2.5 binaries (.exe) on my home P3 and all seems well in use. I got no failures of numpy.test() but some warnings and failures from scipy.test(). The failures are listed below. Comment: finding the SciPy binaries is not obvious, since they do not show here URL:http://www.scipy.org/Download#head-312ad78cdf85a9ca6fa17a266752069d23f785d1 Thank you! Alan Isaac == FAIL: check_syevr (scipy.lib.tests.test_lapack.test_flapack_float) -- Traceback (most recent call last): File C:\Python25\lib\site-packages\scipy\lib\lapack\tests\esv_tests.py, line 41, in check_syevr assert_array_almost_equal(w,exact_w) File C:\Python25\Lib\site-packages\numpy\testing\utils.py, line 232, in assert_array_almost_equa l header='Arrays are not almost equal') File C:\Python25\Lib\site-packages\numpy\testing\utils.py, line 217, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 33.33%) x: array([-0.66992444, 0.48769444, 9.18222618], dtype=float32) y: array([-0.66992434, 0.48769389, 9.18223045]) == FAIL: check_syevr_irange (scipy.lib.tests.test_lapack.test_flapack_float) -- Traceback (most recent call last): File C:\Python25\lib\site-packages\scipy\lib\lapack\tests\esv_tests.py, line 66, in check_syevr_ irange assert_array_almost_equal(w,exact_w[rslice]) File C:\Python25\Lib\site-packages\numpy\testing\utils.py, line 232, in assert_array_almost_equa l header='Arrays are not almost equal') File C:\Python25\Lib\site-packages\numpy\testing\utils.py, line 217, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 33.33%) x: array([-0.66992444, 0.48769444, 9.18222618], dtype=float32) y: array([-0.66992434, 0.48769389, 9.18223045]) == FAIL: check_bicg (scipy.linalg.tests.test_iterative.test_iterative_solvers) -- Traceback (most recent call last): File C:\Python25\lib\site-packages\scipy\linalg\tests\test_iterative.py, line 57, in check_bicg assert norm(dot(self.A, x) - self.b) 5*self.tol AssertionError == FAIL: check_bicgstab (scipy.linalg.tests.test_iterative.test_iterative_solvers) -- Traceback (most recent call last): File C:\Python25\lib\site-packages\scipy\linalg\tests\test_iterative.py, line 69, in check_bicgs tab assert norm(dot(self.A, x) - self.b) 5*self.tol AssertionError == FAIL: check_cgs (scipy.linalg.tests.test_iterative.test_iterative_solvers) -- Traceback (most recent call last): File C:\Python25\lib\site-packages\scipy\linalg\tests\test_iterative.py, line 63, in check_cgs assert norm(dot(self.A, x) - self.b) 5*self.tol AssertionError == FAIL: test_fromimage (scipy.misc.tests.test_pilutil.test_pilutil) -- Traceback (most recent call last): File C:\Python25\lib\site-packages\scipy\misc\tests\test_pilutil.py, line 34, in test_fromimage assert img.min() = imin AssertionError == FAIL: test_imresize (scipy.misc.tests.test_pilutil.test_pilutil) -- Traceback (most recent call last): File C:\Python25\lib\site-packages\scipy\misc\tests\test_pilutil.py, line 18, in test_imresize assert_equal(im1.shape,(11,22)) File C:\Python25\Lib\site-packages\numpy\testing\utils.py, line 137, in assert_equal assert_equal(len(actual),len(desired),err_msg,verbose) File C:\Python25\Lib\site-packages\numpy\testing\utils.py, line 145, in assert_equal assert desired == actual, msg AssertionError: Items are not equal: ACTUAL: 0 DESIRED: 2 -- Ran 1719 tests in 73.656s FAILED (failures=7) unittest._TextTestResult run=1719 errors=0 failures=7 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-user] maskedarray
On Wed, 12 Dec 2007, Travis E. Oliphant apparently wrote:
2) The matrix object made a C-subclass (for speed).
This will probably be the last chance for such a change,
so I again hope that consideration will be given to *one*
change in the matrix object:
iteration over a matrix should return arrays
(instead of matrices).
So if A is a matrix,
A[1] should be an array,
but A[1,:] should be a matrix.
Obviously this is an argument from design rather
than from functionality. Current behavior is not natural.
E.g., it makes it awkward to iterate over all elements in
the natural way, which I claim is::
for row in A:
for element in row:
print element
This example is just meant to illustrate in a simple way
what is odd about the current behavior. (It is not meant
to be an argument nor to suggest that the current absence
simple ways to do the same thing---e.g., using A.A.)
Whenever I am working with matrices, I notice some aspect of
this oddity, and it is annoying when so much else is quite
aesthetic.
Cheers,
Alan Isaac
PS For those who do not know, here is an example of the
current behavior. (The following prints 2 matrices instead
of 4 elements.)
A = N.mat('1 2;3 4')
for row in A:
... for element in row:
... print element
...
[[1 2]]
[[3 4]]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Changing the distributed binary for numpy 1.0.4 for windows ?
This may be a naive question, but just to be sure... If troubles building without SSE2 support on an SSE2 processor are the problem, withould the problem be addressed by purchasing an old PIII like URL:http://cgi.ebay.com/Dell-OptiPlex-GX110-Pentium-III-1GHz-40GB-256MB-DVD-XP_W0QQitemZ130180707038QQihZ003QQcategoryZ140070QQcmdZViewItem or URL:http://cgi.ebay.com/Dell-Precision-210-Pentium-III-Dual-500MHz-512MB-30GB_W0QQitemZ130181576949QQihZ003QQcategoryZ51225QQcmdZViewItem If so I'd be happy to contribute part of the purchase price, and I assume others would too. What's more, I *have* an old PIII at home. (Doesn't everybody?) Unfortunately, I have almost no experience with compiled languages. However if it would be useful, I'd be happy to try to build on my home machine (after this Friday). I would have to ask a lot of questions... Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] multinomial question
Alan G Isaac wrote: I would think that multinomial(1,prob,size=ntrials).sum(axis=0) would be equivalent to multinomial(ntrials,prob) but the first gives a surprising result. (See below.) Explanation? On Wed, 05 Dec 2007, Robert Kern apparently wrote: Pretty much anyone who derives their binomial distribution algorithm from http://www.unc.edu/~gfish/fcmc.html is also wrong. SVN now has a bound such that CDF(bound) is within 1e-16 (or so) of 1.0. Thanks! Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] multinomial question
I would think that multinomial(1,prob,size=ntrials).sum(axis=0) would be equivalent to multinomial(ntrials,prob) but the first gives a surprising result. (See below.) Explanation? Thank you, Alan Isaac ntrials = 10 prob = N.arange(100,dtype=N.float32)/4950 multinomial(1,prob,size=ntrials).sum(axis=0) array([ 0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0, 990, 1058, 996, 1102, 1088, 1137, 1144, 1150, 1196, 1198, 1272, 1273, 1268, 1265, 1380, 1336, 1371, 1405, 1348, 1420, 1515, 1506, 1571, 1499, 1556, 1517, 1603, 1691, 1696, 1763, 1622, 1716, 1722, 1785, 1866, 1799, 1918, 1818, 1868, 1938, 2010, 1916, 1950, 1983, 2062, 2079, 2224, 2165, 2136, 2156, 2215, 2118, 2309, 2389, 2377, 2423, 2328, 2325, 2469]) multinomial(ntrials,prob) array([ 0, 27, 33, 55, 104, 104, 116, 153, 166, 181, 189, 199, 244, 262, 259, 303, 330, 343, 373, 360, 371, 437, 423, 470, 460, 550, 551, 497, 517, 593, 623, 623, 648, 660, 638, 718, 713, 754, 784, 831, 804, 868, 902, 851, 918, 932, 945, 972, 966, 1025, 1005, 1038, 1075, 1046, 1121, 1069, 1121, 1152, 1209, 1148, 1196, 1261, 1288, 1304, 1250, 1324, 1348, 1430, 1370, 1419, 1388, 1364, 1473, 1414, 1511, 1523, 1583, 1574, 1575, 1575, 1613, 1559, 1665, 1666, 1712, 1728, 1715, 1709, 1846, 1774, 1819, 1869, 1886, 1963, 1837, 1906, 1983, 1867, 1968, 1916]) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] loadtxt bug?
On Fri, Nov 23, 2007 at 07:58:13AM -0500, Alan G Isaac wrote: Specifically, is it not the case that the last line of a text file is not guaranteed to have a terminator? Does this not raise the possibility that a digit will be clipped from the last line? On Fri, 23 Nov 2007, Gael Varoquaux apparently wrote: Yes. If the line does not end by a terminator you have a problem. I do not know how common this situation is, but: - it is common enough that some editors address it explicitly (e.g., Vim, Epsilon) - Java's TextReader addresses it explicitly URL:http://www.cs.arizona.edu/~reges/teachers/TextReader.html Based on these considerations an unterminated final line looks like a possibility. If so, perhaps that should be addressed by changing that line I pointed out in `loadtxt`. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] loadtxt bug?
On Thu, Nov 22, 2007 at 11:14:07PM -0500, Alan G Isaac wrote: In numpy.core.numeric.py you will find loadtxt, which uses the following:: line = line[:line.find(comments)].strip() On Fri, 23 Nov 2007, Gael Varoquaux apparently wrote: Unless you are sure that line always ends with a \n. This is the case in the code you are refering too. Unless I am missing some thing. I am not understanding your comment here. In the line of code above, is there a problem or not? Specifically, is it not the case that the last line of a text file is not guaranteed to have a terminator? E.g., URL:http://www.neppert.com/ioutilities/doc/com/neppert/io/TextReader.html Does this not raise the possibility that a digit will be clipped from the last line? Of course strip will afterwards strip any line terminators. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] loadtxt bug?
In numpy.core.numeric.py you will find loadtxt, which uses the following:: line = line[:line.find(comments)].strip() I believe there is a bug here (when a line has no comment). To illustrate:: line = 12345 comments = # line[:line.find(comments)] '1234' So I propose this should be:: try: line = line[:line.index(comments)].strip() except ValueError: line = line.strip() Am I right? Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] weibull distribution has only one parameter?
On Mon, 12 Nov 2007, D.Hendriks (Dennis) apparently wrote: All of this makes me doubt the correctness of the formula you proposed. It is always a good idea to hesitate before doubting Robert. URL:http://en.wikipedia.org/wiki/Weibull_distribution#Generating_Weibull-distributed_random_variates hth, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] matrix problem: float to matrix power
1.0**numpy.array([1,2,3]) array([ 1., 1., 1.]) 1.0**numpy.mat([1,2,3]) Traceback (most recent call last): File stdin, line 1, in module TypeError: unsupported operand type(s) for ** or pow(): 'float' and 'matrix' Why the restriction for matrices? Same question for matrices conformable for broadcasting: why not produce the equivalent of the array result? Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] design patterns for computing
It sounds to me like you have something closer to the following. class Problem - initialized with an Input instance and an Analysis instance - has a ``get_results`` method that asks the Analysis instance to - call ``get_input`` on Input instance - run analysis on the provided input - create and return and instance of a Results class Instances of the Input class can then produce input anyway you like---e.g., as data containers or as data fetchers---as long as they provide it in a standard format in response to ``get_input``. fwiw, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Use of PyArray FromAny() wi th a PyArrayInterface object
On Fri, 12 Oct 2007, Matthieu Brucher apparently wrote: I'm trying to understand (but perhaps everything is in the numpy book in which case I'd rather buy the book immediately) how to use the PyArray_FromAny() function. This function is discussed in the NumPy Book. I see perhaps a dozen references to the function in the Complete API chapter. Even apart from that chapter, which is useful to you but not to me, I have found the book to be excellent. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] abstraction and interfaces
On Fri, 12 Oct 2007, Renato Serodio apparently wrote: The scripts that produce these metrics use Scipy/Numpy functions that operate on data conveniently converted to numpy arrays. They're quite specific, and I tend to produce/tweak a lot of them. So, to fit in this application someone suggested I programmed 'interfaces' (in java jargon) to them - that way I could develop the whole wrapper application without giving much thought to the actual number-crunching bits. That sounds quite right. Check out URL:https://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/solvers/optimizers/optimizer URL:http://svn.scipy.org/svn/scipy/trunk/scipy/stats/models/ for examples that may be relevant to your project. Python does not have interfaces per se, but that does not stop you from designing interface-like classes and inheriting from them. fwiw, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.distutils.cpuinfo bugs?
On Tue, 2 Oct 2007, David M. Cooke apparently wrote: Should be fixed now. The update seems to work for all my students who were having problems. Thank you, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] beginner question: rank-1 arrays
On Mon, 8 Oct 2007, Robin apparently wrote: However in my code (I am converting from MATLAB) it is important to maintain 2d arrays, and keep the difference between row and column vectors. How about using matrices? help(numpy.mat) hth, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python Magazine
On Fri, 05 Oct 2007, Christopher Barker apparently wrote: There is a new Python Magazine out there: http://www.pythonmagazine.com/ Looks useful. If you think so too, make sure you library subscribes. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Default value in documentation
On Tue, 2 Oct 2007, Charles R Harris apparently wrote: We're avoiding consolidated fields because they behave badly. ... The main problem with the consolidated fields is that they are all put together as item lists in a definition list and moved to the end of the docstring when it is rendered. There is also little control through the .css style sheet, they are all bulleted, and some of the types are missing. Is Ed Loper aware of this complaint? If so, has he indicated an interest (or lack) in addressing this complaint? Consolidated fields are great: it is a shame to do without them. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] boolean matrix bug?
Shouldn't x**0 be boolean for a boolean matrix?
Cheers,
Alan Isaac
import numpy
numpy.__version__
'1.0.3.1'
x = numpy.mat('1 1;1 0',dtype='bool')
x**0
matrix([[ 1., 0.],
[ 0., 1.]])
x**1
matrix([[ True, True],
[ True, False]], dtype=bool)
x**2
matrix([[ True, True],
[ True, True]], dtype=bool)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-dev] adopting Python Style Guide for classes
To help me understand, might someone offer some examples of NumPy names that really should be changed? Thank you, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.distutils.cpuinfo bugs?
On Tue, 02 Oct 2007, Pearu Peterson apparently wrote: 1. The printed '0' traces to an undesirable print statement. (I've reported this before.) Travis seemed to fix this about two weeks ago. Sorry for the noise. 2. The 'False report is on a Pentium M. Should that not be True? URL:http://en.wikipedia.org/wiki/Pentium_M Or am I misusing the test? What OS are you using? If Linux, then can you send the content of /proc/cpuinfo? It is a student's machine, running Windows XP. I did check the system information to confirm that it is really a Pentium M. I will be happy to convey any suggested diagnostics to the student. (I have sent David's suggestion.) Thank you, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.distutils.cpuinfo bugs?
Here is the processor information using the Intel utility. Cheers, Alan Isaac Intel(R) Processor Identification Utility Version: 3.7.20070907 Time Stamp: 2007/10/02 14:21:29 Number of processors in system: 1 Current processor: #1 Cores per processor: 1 Disabled cores per processor: 0 Processor Name: Intel(R) Pentium(R) M processor 735 1.70GHz Type: 0 Family: 6 Model: D Stepping: 6 Revision: 18 L1 Instruction Cache: 32 KB L1 Data Cache: 32 KB L2 Cache: 2 MB Packaging: µFCPGA/µFCBGA EIST: Yes MMX(TM): Yes SSE: Yes SSE2: Yes SSE3: No SSE4: No Enhanced Halt State: No Execute Disable Bit: No Hyper-Threading Technology: No Intel(R) 64 Architecture: No Intel(R) Virtualization Technology: No Expected Processor Frequency: 1.70 GHz Reported Processor Frequency: 1.70 GHz Expected System Bus Frequency: 400 MHz Reported System Bus Frequency: 400 MHz * ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Default value in documentation
On Tue, 2 Oct 2007, Pierre GM apparently wrote: is there any kind of standard to describe the attributes of a class, a la :IVariables: in epydoc ? I thought it was ... :IVariables: i.e., I thought the standard was reST as handled by epydoc. URL:http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines URL:http://epydoc.sourceforge.net/api/epydoc.markup.restructuredtext-module.html#CONSOLIDATED_DEFLIST_FIELDS Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] combinations anomaly
On Sat, 22 Sep 2007, Charles R Harris apparently wrote: an array view is returned, and the data is updated in the loop ... I think your range fix is the way to go. Got it. Thanks! Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Extracting all the possible com binations of a grid
On Fri, 21 Sep 2007, Stephen McInerney apparently wrote: The pure Pythonic solution is a list comprehension involving multiple sequences: x = range(0,n) y = x z = x t = [(xx,yy,zz) for xx in x for yy in y for zz in z] Different question ... Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] unwanted cpuinfo output
Suppose I import cpuinfo on a Win32 platform:: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import numpy numpy.__version__ '1.0.3.1' from numpy.distutils import cpuinfo 0 That unwanted '0' is due to a print statement on line 527:: print proc This is being printed is the **absence** of an exception, so I believe this is unwanted behavior. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Citing Numeric and numpy
On Wed, 29 Aug 2007, Peter apparently wrote: I would like to know if there is a preferred form for citing the old Numeric library I'll attach text from the first two pages of *Numerical Python* below. Cheers, Alan Isaac - An Open Source Project Numerical Python David Ascher Paul F. Dubois Konrad Hinsen Jim Hugunin Travis Oliphant with contributions from the Numerical Python community. September 7, 2001 Lawrence Livermore National Laboratory, Livermore, CA 94566 UCRLMA128569 ii Legal Notice Please see file Legal.html in the source distribution. This open source project has been contributed to by many people, including personnel of the Lawrence Liver more National Laboratory. The following notice covers those contributions including this manual. Copyright (c) 1999, 2000, 2001. The Regents of the University of California. All rights reserved. Permission to use, copy, modify, and distribute this software for any purpose without fee is hereby granted, provided that this entire notice is included in all copies of any software which is or includes a copy or modifi cation of this software and in all copies of the supporting documentation for such software. This work was produced at the University of California, Lawrence Livermore National Laboratory under con tract no. W7405ENG48 between the U.S. Department of Energy and The Regents of the University of Cali fornia for the operation of UC LLNL. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] additional thanks
On Fri, 24 Aug 2007, Ryan Krauss apparently wrote: I helped a couple of my students install on Vista. It was enough to right click on the exe and choose Run as Administrator. A pop-up window then comes up asking you if you trust the file or something and you have to chose an option that is something like, yes, let it proceed. OK. I was not present for the installs. (Our classes start next week.) I did of course check that they were installing as Administrator, and they claimed yes. I'll know more next week. Thanks, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.array does not take generators
On Thu, 16 Aug 2007, Geoffrey Zhu apparently wrote: K=numpy.array(o[2]/1000.0 for o in opts) It does not work. K=numpy.fromiter((o[2]/1000.0 for o in opts),'float') hth, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Count the occurrence of a certain integer in a list of integers
On Tue, 07 Aug 2007, Nils Wagner apparently wrote: I have a list of integer numbers. The entries can vary between 0 and 19. How can I count the occurrence of any number. Consider data [9, 6, 9, 6, 7, 9, 9, 10, 7, 9, 9, 6, 7, 9, 8, 8, 11, 9, 6, 7, 10, 9, 7, 9, 7, 8, 9, 8, 7, 9] Is there a better way than using, e.g. shape(where(array(data)==10))[1] 2 You did not say why data.count(10) is unsatisfactory ... Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] multinomial error?
On Fri, 03 Aug 2007, [EMAIL PROTECTED] apparently wrote: I appear to be having a problem with the random.multinomial function. For some reason if i attempt to loop over a large number of single-trial multinomial picks then the function begins to ignore some non-zero entries in my 1-D array of multinomial probabilities... Is seems that there is no upper limit on the size of the probability array for a one off multinomial pick, but if looping over the process multiple times the function can't handle the whole array and seems to truncate it arbitrarily before performing the trial with only the remaining probabilities. Minimal example? Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Finalising documentation guidelines for NumPy
On Tue, 17 Jul 2007, Stefan van der Walt apparently wrote: var1 : Description. breaks. This can be fixed either by omitting the colon after 'var1' in the second case, or by slightly modifying epydoc's output. It breaks semantically too, no? (The colon is a separator, separating the variable name from its type.) By the way, Are you referring to a particular document? I see the following document http://projects.scipy.org/scipy/numpy/wiki/DocstringStandards which points to the detailed document. http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/HOWTO_DOCUMENT.txt The detailed document seems the place to add your changes. (Note that the renderred version is unavailable: http://projects.scipy.org/scipy/numpy/wiki/HowToDocument) Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Should bool_ subclass int?
I found Gael's presentation rather puzzling for two reasons. 1. It appears to contain a `+` vs. `*` confusion. See http://en.wikipedia.org/wiki/Two-element_Boolean_algebra 2. MUCH more importantly: In implementations of TWO, we interpret `-` as unary complementation (not e.g. as additive inverse; note True does not have one). So -True is False -False is True This matches numpy: -N.array([False]) array([True], dtype=bool) -N.array([True]) array([False], dtype=bool) This is a GOOD THING. However, a-b should then just be shorthand for a+(-b). Here numpy does not in my opinion behave correctly: N.array([False])-N.array([True]) array([True], dtype=bool) N.array([False])+(-N.array([True])) array([False], dtype=bool) The second answer is the right one, in this context. I would call this second answer a bug. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Should bool_ subclass int?
On Mon, 9 Jul 2007, Timothy Hochberg apparently wrote: x*y and x**2 are already decoupled for arrays and matrices. What if x*y was simply defined to do a boolean matrix multiply when the arguments are boolean matrices? I don't care about this that much though, so I'll let it drop. So if x and y are arrays and you use `dot` you would get a different result than turning them into matrices and using `*`? I'd find that pretty odd. I'd also find it odd that equivalent element-by-element operations (`+`, `-`) would then return different outcomes for boolean arrays and boolean matrices. (This is what I meant by decoupled.) This is just a user's perspective. I do not pretend to see into the design issues. However, daring to tread where I should not, I offer two observations: - matrices and 2-d arrays with dtype 'bool' should give the same result for comparable operations (where `dot` for arrays compares with `*` for matrices). - it would be possible to have a new class, say `boolmat`, that implements the expected behavior for boolen matrices and then make matrices and arrays of dtype 'bool' behave in the Python way (e.g., True+True is 2, yuck!). I am definitely NOT advocating this (I like the current arrangement), but it is a possibility. Cheers, Alan Isaac PS Here is Guido's justification for bool inheriting from int (http://www.python.org/dev/peps/pep-0285/). It seems that numpy's current behavior is closer to his ideal world. 6) Should bool inherit from int? = Yes. In an ideal world, bool might be better implemented as a separate integer type that knows how to perform mixed-mode arithmetic. However, inheriting bool from int eases the implementation enormously (in part since all C code that calls PyInt_Check() will continue to work -- this returns true for subclasses of int). Also, I believe this is right in terms of substitutability: code that requires an int can be fed a bool and it will behave the same as 0 or 1. Code that requires a bool may not work when it is given an int; for example, 3 4 is 0, but both 3 and 4 are true when considered as truth values. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Should bool_ subclass int?
Hi Gael, More important is the following. On Tue, 10 Jul 2007, Alan G Isaac apparently wrote: N.array([False])-N.array([True]) array([True], dtype=bool) N.array([False])+(-N.array([True])) array([False], dtype=bool) The second answer is the right one, in this context. I would call this [first!!!] answer a bug. Do you agree that the first (!!!) answer is a bug? (The basis is apparently performed as follows: integer array subtraction is first performed, and then nonzero ints are converted to True. But this gives the wrong answer and most critically breaks the equivalence of a-b and a+(-b).) Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-dev] numpy.cumproduct() documentation: bug?
On Wed, 04 Jul 2007, dmitrey apparently wrote: cumproduct(x, axis=None, dtype=None, out=None) Sum the array over the given axis. Docstring bug. But it behaves right. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unfortunate user experience with max()
On Wed, 16 May 2007, Anne Archibald apparently wrote: numpy.max(-1.3,2,7) -1.3 Is that new behavior? I get a TypeError on the last argument. (As expected.) Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation
Gary Ruben wrote: In you post, is your numpy/doc reference referring to the file HOWTO_DOCUMENT.txt? I notice that this is not the same as the one here http://scipy.org/DocstringStandard which I think may be the preferred standard. If someone can confirm this, it should probably replace the HOWTO_DOCUMENT.txt content. IMO, the wiki version is more readable and also more comprehensive. On Tue, 15 May 2007, Robert Kern apparently wrote: Note that despite the title, we haven't actually agreed to this format. It was simply a proposal. Just to add a bit more specificity, I believe that the HOWTO_DOCUMENT.txt document at http://svn.scipy.org/svn/numpy/trunk/numpy/doc/HOWTO_DOCUMENT.txt summarizes a substantial discussion and broad agreement. I.e., it is currently the preferred standard. Apologies if I missed a relevant discussion, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation
On 5/15/07, Alan G Isaac [EMAIL PROTECTED] wrote: Just to add a bit more specificity, I believe that the HOWTO_DOCUMENT.txt document at http://svn.scipy.org/svn/numpy/trunk/numpy/doc/HOWTO_DOCUMENT.txt summarizes a substantial discussion and broad agreement. I.e., it is currently the preferred standard. On Tue, 15 May 2007, Charles R Harris apparently wrote: I think the output generated for the consolidated lists is too ugly to bear. The bullets are distracting, there is no spacing between entries, and the explanatory text is appended on the same line, making it difficult to read. So get rid of :Parameters: and just use Parameters: . Futhermore, the dashes under Notes and Examples make these section headers and PyDoc moves these blocks to the top so that they are printed before the Parameters list and other list blocks. Did no one actually run this stuff through PyDoc? So my recommendations are to remove the leading :'s from the list headings, making them definition lists, italicize them, and insert the mandatory blank line after. Then remove the dashes from under Notes and Examples, and let the documenter choose between lists with the appended : , or just indent the text after, which has the same effect if there are no list item headings, which there typically aren't in those sections. If this is meant as a reply to my post, it seems to treat my simple summary as advocacy. Now I am in fact an advocate of sticking with reStructuredText, but I was simply summarizing how I understood a rather *extended* discussion. There was an outcome; I believe the doc above captures it. Charles apparently wishes to reopen that discussion. It will probably help to keep a few things separate. Bullets in consolidated lists: if you don't like them, don't use them. Use a definition list instead. (I like this much better myself.) Formatting: this is just a style issue. Submit a CSS file. Placement of Notes and Examples: Seems simple to change, and the Epydoc developer has been very accommodating. Raise it as an issue or submit a patch. I will not try to summarize all the reasons *for* relying on reST, since these were hashed over in the previous discussion. I will just mention the obvious: getting additional functionality can have some costs, and one cost of having access to all the possible epydoc conversions---including typeset math in both PDF and XHTML documents---is the use of (very light) informative markup. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation
On Tue, 15 May 2007, Charles R Harris apparently wrote: It also causes the headings to be set in large bold type. Ugly. Well I agree. But again this is just a style issue. All font decisions (and *much* else) can be set in a CSS file. I think reST is great, and properly used we get good looking output without mucking up the help text displayed in a terminal. I agree. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation
On Tue, May 15, 2007 at 01:15:12PM -0400, Alan G Isaac wrote: Bullets in consolidated lists: if you don't like them, don't use them. Use a definition list instead. (I like this much better myself.) On Tue, 15 May 2007, Gael Varoquaux apparently wrote: Can't this be fixed by a CSS ? That is also true for the HTML. But I thought he was not liking them in the text (console) documentation as well. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation
On Tue, 15 May 2007, Charles R Harris apparently wrote: If a CSS can set all the font styles, item spacing, and treatment of explanatory text, that would be the more flexible route. I'm not sure what treatment meams here, but if it is a matter of font decisions or spacing, the answer should be yes. If we can also make SeeAlso generate links to the referenced routines I will be very satisfied. epydoc supports documentation cross-reference links. I think you get what you want (if I understand) just but putting the name in back ticks, `like_this`. That will give me a link to the like_this function in the same module (and maybe anywhere in the package, but I'm not sure). Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation
On Tue, 15 May 2007, Charles R Harris apparently wrote: Looks like the font used for section headings can be specified, but there is nothing in the epydoc.css file that looks like it affects the consolidated lists or the movement of a section heading to the top of the output. I think the latter comes from reST because that is where it is documented. I cannot imagine that reST would move things around unless you ask, so that must be an epydoc decision. Perhaps I recall (?) that the epydoc developer expressed willingness to revisit this decision or make it modifiable. I suppose it might be modified by floating it (with CSS), but that seems a last resort. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation
On Tue, 15 May 2007, Charles R Harris apparently wrote: The item in a consolidated list is divided into three parts: name, type, explanation. I see no way in the CSS to control the display of those parts, although it might be an undocumented feature. I basically want it to look like a definition list with maybe the current default for type, which puts it in parenthesis. OK, I see. To control this we need a very small change in output. Instead of:: dl class=docutils dtcode class=linkmyvar/code: mytype/dt ddmy explanation/dd /dl I think (as long as the colon is ok) we just need:: dl class=docutils parameterlist dt code class=link parametermyvar/code: span class=parametertypemytype/span /dt ddmy explanation/dd /dl This actually seems a very appropriate change for epydoc and fully backwards compatible. I'll copy this to Ed Loper and see if he will consider making this change. (I'm not sure he is monitoring this discussion any longer.) Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documentation
On Tue, 15 May 2007, Charles R Harris apparently wrote: What I would like it to look like, except for the type stuff, is attached. Ooof! Aside from obviously agreeing with the location of notes and examples, I have to say, the readability of your example is greatly reduced from the epydoc default! Specifically, I would restore the background colors and restore bold to the headings. (I would agree bold is not needed/desirable for the function names in the Function Details.) But I have no background in web design. Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] building pynetcdf-0.7 on OS X 10.4 intel
On Wed, 02 May 2007, Rob De Almeida apparently wrote: http://cheeseshop.python.org/pypi/pupynere/ I do not think you were shameless enough. Pupynere is a PUre PYthon NEtcdf REader. It allows read-access to netCDF files using the same syntax as the Scientific.IO.NetCDF module. Even though it's written in Python, the module is up to 40% faster than Scientific.IO.NetCDF and pynetcdf. Mentioning the MIT license is also worthwhile. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] question about standalone small software and teaching
On Thu, 5 Apr 2007, Gael Varoquaux apparently wrote: Actually I do it the other way around nowadays. Except in the tutorial? But anyway, I'm willing to try anything that gets them moving. It is true that avoiding the appearance of complexity can sometimes add complexity. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] basic python questions
On Wed, 04 Apr 2007, Eric Firing apparently wrote: Key point: properties work with new-style classes but fail silently and mysteriously with classic classes. Or making the same point a little more generally, descriptors only work for new-style classes: http://users.rcn.com/python/download/Descriptor.htm I am nevertheless uncertain why you need new-style classes if you create a iterable class that you want numpy to be able to convert to an array. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] organizational question
Is either NumPy or SciPy substantially supported by an identifiable and actual non-profit organization? I ask because I think both fit under http://www.mellon.org/grant_programs/programs/copy_of_research item 4. Here is the announcement: http://matc.mellon.org/ Note that universities are among the nominees: http://matc.mellon.org/2007_nominations Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On Tue, 27 Mar 2007, Zachary Pincus apparently wrote: Now, Bill offers up a different suggestion: indexing M yields neither a matrix nor an array, but a class that operates more or less like an array, except insofar as it interacts with other matrix objects, or other objects of similar classes. I'm interested in hearing more about this, what trade-offs or other compromises it might involve. So would you agree that in this case M[0] and M[0,:] would have to be different things? Or would you then want even such numpy indexing not to produce matrices?? Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On Tue, 27 Mar 2007, Bill Baxter apparently wrote: xformedPt = someComplicatedNonLinearThing(pt) I do stuff like the above quite frequently in my code, although with arrays rather than matrices. Exactly: that was one other thing I found artificial. Surely the points will then be wanted as arrays. So my view is that we still do not have a use case for wanting matrices yielded when iterating across rows of a matrix. Alan Isaac PS In the large number of points case, the thing to do would be to extract modest sized submatrices. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] missing use case
Hi Zachary, I think your response highlights very well the apparent design flaw. Here is your response to my request for a use case where iteration over a matrix should yield matrices: do not iterate! Does some part of you not find that just a little bizarre?! As for offering as a use case that with a matrix M you are allowed to use M[0] instead of M[0,:] when you want the first row as a matrix, I really cannot take that trivial convenience seriously as the basis of a fundamental design decision. However there is no sympathy for my view on this, so I am not debating it any more. Instead I have asked a simple question: what use case is this design decision supporting? I am interested in this so that I can see into the decision better. Nowith Chris proposes that M[i] == M[i,:] by definition. If so, that is an design-based answer to my question. I agree that M[i,:] should return a matrix. But my understanding was different: I thought M[i] relied on standard Python idexing while M[i,:] was numpy indexing. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
Hi Zach, The use case I requested was for iteration over a matrix where it is desirable that matrices are yielded. That is not what you offered. The context for this request is my own experience: whenever I have needed to iterate over matrices, I have always wanted the arrays. So I am simply interested in seeing an example of the opposite desire. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On Tue, 27 Mar 2007, Robert Kern apparently wrote: Gram-Schmidt orthogonalization I take it from context that you consider it desirable to end up with a list of matrices? I guess I would find it more natural to work with the arrays, but perhaps that starts just being taste. Thank you, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On Tue, 27 Mar 2007, Robert Kern apparently wrote: Gram-Schmidt orthogonalization Alan G Isaac wrote: I take it from context that you consider it desirable to end up with a list of matrices? Robert wrote: Honestly, I don't care. You asked about iteration, and I gave you an example where it was important that the iterates were matrices (such that .T worked correctly). Please stop moving the goal posts. It is really not my intent to be irritating or to move the posts. But I had two reasons to ask. First, your claim is false that this was important in your example. (To see this, replace M[1:] with M.A[1:].) So actually your code would work the same if iteration over matrices were producing arrays (after replacing M[0] with M[0,:] to match that case). Second, when I spoke of *desirability*, the output is relevant. Try nump.mat(ortho) to see what I mean. If iteration were to produce arrays, the outcome of implementing the algorithm (e.g., using ``dot``) would be I suggest more desirable, in that numpy.mat(ortho) would work as hoped/expected. In this sense, the example perhaps speaks against your intent. You offer code that would work just fine if iteration yielded arrays. Apologies in advance if this again seems tangential to my original request. To me it does not. If you really want iterates to be arrays, just use .A. I have mentioned that several times. It is orthogonal to the design issue I raised. (I suggested that under the current behavior you do not usually end up with what you want when iterating over matrices.) But again, I recognize that I am alone in that view. I am just trying to understand why. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote: Perhaps things would be clearer if we thought of the constituent groups of data in a matrix as being themselves matrices. This thinking of is what you have suggested before. You need to explain why it is not begging the question. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
Alan G Isaac schrieb: X[1] array([3,4]) X[1,:] matrix([[3, 4]]) But again the point is: indexing for submatrices should produce matrices. Normal Python indexing should access the constituent arrays. On Mon, 26 Mar 2007, Sven Schreiber apparently wrote: I think this is a tricky business. There's also the rule indexing reduces the rank, slicing preserves it. Numpy-matrices form an exception to this rule, always being 2d, but the exception is consistently enforced. Now it seems you want to have an exception from the exception, correct? What I want: the best design. I did not claim that the current design is flawed, only to suspect it. Why I wrote: current behavior feels wrong - suspect design flaw. What feels wrong: iterating over a container does not give access to the contained objects. This is not Pythonic. *Symptom* of the underlying problem: for matrix M, M[0] returns a matrix. Would the change I suggest mean that the behavior of the matrix class deviates less from the array class: yes. Does this mean the matrix class behavior would be less consistent? I have tried to explain why the answer is no. hth, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
Alan G Isaac schrieb: What feels wrong: iterating over a container does not give access to the contained objects. This is not Pythonic. On Mon, 26 Mar 2007, Sven Schreiber apparently wrote: If you iterate over the rows of the matrix, it feels natural to me to get the row vectors Natural in what way? Again, I am raising the question of what would be expected from someone familiar with Python. Abstractly, what do you expect to get when you iterate over a container? Seriously. But I admit I'm a 2d fan so much so that I didn't even know that using a single index is possible with a matrix. Exactly. When you want submatrices, you expect to index for them. EXACTLY!! Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On Mon, 26 Mar 2007, Sebastian Haase apparently wrote: A matrix is an object that you expect a certain (mathematical !) behavior from. If some object behaves intuitively right -- that's ultimately pythonic! The problem is, as I am not the only one to point out, this particular behavior is NOT intuitively right. The clash is, NOT to see a matrix just as another container. But be serious, no object is just another container. Again, this just begs the question. The question is a design question. E.g., what is the principle of least surprise? more notes/points: a) I have never heard about the m.A1 - what is it ? It returns a 1d array holding the raveled matrix. b) I don't think that if m[1] would return a (rank 2) matrix, that m[1].A could return a (rank 1) array ... It does not, of course. (But both should, I believe.) c) I'm curious if there is a unique way to extend the matrix class into 3D or ND. Is that not what an array is for?? Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote: One would expect the iteration over A to return row vectors, represented by (1, n) matrices. On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote: This is again simple assertion. **Why** would one expect this? Some people clearly do not. On Mon, 26 Mar 2007, Charles R Harris apparently wrote: Well, and what should they expect. Since matrices are an iterable Python object, we *expect* to iterate over the contained objects. (Arrays.) I am not sure why this is not evident to all, but it is surely the sticking point in this discussion. A matrix is not a container of matrices. That it acts like one is surprsing. Surprises are bad unless they have a clear justification. Perhaps a clear justification exists, but it has not been offered in this discussion. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] matrix indexing question
One thing keeps bugging me when I use numpy.matrix.
All this is fine::
x=N.mat('1 1;1 0')
x
matrix([[1, 1],
[1, 0]])
x[1,:]
matrix([[1, 0]])
But it seems to me that I should be able
to extract a matrix row as an array.
So this ::
x[1]
matrix([[1, 0]])
feels wrong. (Similarly when iterating across rows.)
Of course I realize that I can just ::
x.A[1]
array([1, 0])
but since the above keeps feeling wrong I felt I should
raise this as a possible design issue, better discussed
early than latter.
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
Em Dom, 2007-03-25 às 13:07 -0400, Alan G Isaac escreveu:
x[1]
matrix([[1, 0]])
feels wrong. (Similarly when iterating across rows.)
On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote:
I think the point here is that if you are using matrices,
then all you should want are matrices, just like in
MATLAB:
b = A(1, :)
b =
1 2
Yes, that is the idea behind this, which I am also
accustomed to from GAUSS. But note again that the Matlab
equivalent ::
x=N.mat('1 2;3 4')
x[0,:]
matrix([[1, 2]])
does provide this behavior. The question I am raising
is a design question and is I think really not addressed
by the rule of thumb you offer. Specifically, that rule
of thumb if it is indeed the justification of ::
x[1]
matrix([[3, 4]])
finds itself in basic conflict with the idea that I ought to
be able to iterate over the objects in an iterable container.
I mean really, does this not feel wrong? ::
for item in x: print item.__repr__()
...
matrix([[1, 2]])
matrix([[3, 4]])
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
