Re: [Numpy-discussion] dot/tensordot limitations

On Tue, Apr 29, 2008 at 10:31 PM, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > Nadav Horesh wrote: > > You open here a Pandora box: > > What should I do if I want to run an operation on elements of an array > which are not in the library. The usual answers are either use more memory ( > (A*B).s

Re: [Numpy-discussion] dot/tensordot limitations

Nadav Horesh wrote: > You open here a Pandora box: > What should I do if I want to run an operation on elements of an array which > are not in the library. The usual answers are either use more memory ( > (A*B).sum(axis=1) ), or more time ([dot(A[i],B[i]) for i in len(A)]). > > Would your issue c

Re: [Numpy-discussion] dot/tensordot limitations

Nadav Horesh wrote: > You open here a Pandora box: > What should I do if I want to run an operation on elements of an array which > are not in the library. The usual answers are either use more memory ( > (A*B).sum(axis=1) ), or more time ([dot(A[i],B[i]) for i in len(A)]). > > Would your issue c

Re: [Numpy-discussion] dot/tensordot limitations

You open here a Pandora box: What should I do if I want to run an operation on elements of an array which are not in the library. The usual answers are either use more memory ( (A*B).sum(axis=1) ), or more time ([dot(A[i],B[i]) for i in len(A)]). Would your issue can be rephrase like this: A way

Re: [Numpy-discussion] Starting to work on runtime plugin system for plugin (automatic sse optimization, etc...)

On Dienstag 29 April 2008, David Cournapeau wrote: > Andreas Klöckner wrote: > > Yes, obviously everything will need to be linked into one big static > > executable blob. I am somewhat certain that distutils will be of no help > > there, so I will need to "roll my own". There is a CMake-based build

Re: [Numpy-discussion] Starting to work on runtime plugin system for plugin (automatic sse optimization, etc...)

Andreas Klöckner wrote: > But so far, I might not end up having to do all that, for which I'd be > endlessly grateful. > If you really need it, note that numpy can be built with scons instead of distutils, and the scons scripts are now available in numpy svn (and will be included in the rele

Re: [Numpy-discussion] Starting to work on runtime plugin system for plugin (automatic sse optimization, etc...)

Andreas Klöckner wrote: > > Yes, obviously everything will need to be linked into one big static > executable blob. I am somewhat certain that distutils will be of no help > there, so I will need to "roll my own". There is a CMake-based build of > Python for BG/L, I was planning to work off that

Re: [Numpy-discussion] Starting to work on runtime plugin system for plugin (automatic sse optimization, etc...)

On Dienstag 29 April 2008, David Cournapeau wrote: > Andreas Klöckner wrote: > > Argh. -1 for a hard dependency on dlopen(). > > There is no hard dependency on dlopen, there is a hard dependency on > runtime loading, because well, that's the point of a plugin system. It > should not be difficult to

Re: [Numpy-discussion] Starting to work on runtime plugin system for plugin (automatic sse optimization, etc...)

Andreas Klöckner wrote: > > Argh. -1 for a hard dependency on dlopen(). There is no hard dependency on dlopen, there is a hard dependency on runtime loading, because well, that's the point of a plugin system. It should not be difficult to be able to disable the plugin system for platforms who

Re: [Numpy-discussion] Starting to work on runtime plugin system for plugin (automatic sse optimization, etc...)

Lisandro Dalcin wrote: > David, I briefly took a look at your code, and I have a very, very > important observation. > > Your implementation make uses of low level dlopening. Then, your are > going to have to manage all the oddities of runtime loading in the > different systems. In this case, 'libt

Re: [Numpy-discussion] Can anyone look at #759

Travis E. Oliphant wrote: > David Cournapeau wrote: > >> Hi, >> >> I have a patch for an issue which had bugged me for some time, but >> since I am not familiar with that part of numpy code, I would prefer >> someone checking I am not doing anything stupid before checking in, >> >>

Re: [Numpy-discussion] Starting to work on runtime plugin system for plugin (automatic sse optimization, etc...)

On Dienstag 29 April 2008, Lisandro Dalcin wrote: > Your implementation make uses of low level dlopening. Then, your are > going to have to manage all the oddities of runtime loading in the > different systems. Argh. -1 for a hard dependency on dlopen(). At some point in my life, I might be force

Re: [Numpy-discussion] the path forward

On Tue, Apr 29, 2008 at 5:18 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote: > On Tue, 29 Apr 2008, Keith Goodman apparently wrote: > > I hope that changing x[0,:] is considered a major change since it will > > break most any package based on matrices (mine). And so > > I hope that such a change wou

Re: [Numpy-discussion] the path forward

On Tue, 29 Apr 2008, Keith Goodman apparently wrote: > I hope that changing x[0,:] is considered a major change since it will > break most any package based on matrices (mine). And so > I hope that such a change wouldn't show up, if at all, > until 2.0. What if the extant matrix class would co

Re: [Numpy-discussion] the path forward

On Tue, Apr 29, 2008 at 2:43 PM, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > > > The problem is that ``x[0]`` being 2d has produced a variety > > of anomalies, and the natural fix is for ``x[0]`` to be 1d. > > > > Gael has argued strongly that she should be able to use the > > following no

Re: [Numpy-discussion] Starting to work on runtime plugin system for plugin (automatic sse optimization, etc...)

David, I briefly took a look at your code, and I have a very, very important observation. Your implementation make uses of low level dlopening. Then, your are going to have to manage all the oddities of runtime loading in the different systems. In this case, 'libtool' could really help. I know, it

Re: [Numpy-discussion] the path forward

On Tue, Apr 29, 2008 at 06:44:11PM -0400, Alan G Isaac wrote: > On Tue, 29 Apr 2008, Alan G Isaac apparently wrote: > > Gael has argued strongly that he should be able to use the > > following notation: ``x[0,:]*A*x[:,0]``. > By the way Gael, is > x.rows(0) * A * x.cols(0) > a good replacement i

Re: [Numpy-discussion] untenable matrix behavior in SVN

On 30/04/2008, Keith Goodman <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 2:18 PM, Anne Archibald > <[EMAIL PROTECTED]> wrote: > > It is actually pretty unreasonable to hope that > > > > A[0] > > > > and > > > > A[[1,2,3]] > > or > > A[[True,False,True]] > > > > should re

[Numpy-discussion] dot/tensordot limitations

Timothy Hochberg has proposed a generalization of the matrix mechanism to support manipulating arrays of linear algebra objects. For example, one might have an array of matrices one wants to apply to an array of vectors, to yield an array of vectors: In [88]: A = np.repeat(np.eye(3)[np.newaxis,...

Re: [Numpy-discussion] the path forward

On Tue, 29 Apr 2008, Alan G Isaac apparently wrote: > Gael has argued strongly that he should be able to use the > following notation: ``x[0,:]*A*x[:,0]``. By the way Gael, is x.rows(0) * A * x.cols(0) a good replacement in your view? I find it nicely explicit and, to meet another of your concer

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, Christopher Barker apparently wrote: > a really good argument for: > A * B.col[i] Also see the syntax discussed in Proposal 5. (I am not expressing an opinion.) http://www.scipy.org/MatrixIndexing#proposal-5> One possibility is to let the rows and cols methods

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, "Travis E. Oliphant" apparently wrote: > x[i,:] * A * x[:,i] This need is also fully met by Proposal 5. It is just a matter of syntax and sticking with matrices. http://www.scipy.org/MatrixIndexing#proposal-5> E.g., x.rows(i) * A * x.cols(i) Cheers, Alan Isaac __

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 2:18 PM, Anne Archibald <[EMAIL PROTECTED]> wrote: > On 29/04/2008, Keith Goodman <[EMAIL PROTECTED]> wrote: > > In my use i is most commonly an array (i = M.where(y.A)[0] where y is > > a nx1 matrix), sometimes a list, and in ipython when debugging or > > first writing

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 03:03:51PM -0700, Christopher Barker wrote: > Gael Varoquaux wrote: > > However I would find it nice that, for linear algebra, > > x[i, :] == x[:, i].T > > This is the kind of behavior I expect, and we won't be getting it with 1D > > arrays. > But you WOULD get it with 1-

Re: [Numpy-discussion] accuracy issues with numpy arrays?

On 30/04/2008, eli bressert <[EMAIL PROTECTED]> wrote: > I'm writing a quick script to import a fits (astronomy) image that has > very low values for each pixel. Mostly on the order of 10^-9. I have > written a python script that attempts to take low values and put them > in integer format. I b

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 2:43 PM, Christopher Barker <[EMAIL PROTECTED]> wrote: > Timothy Hochberg wrote: > > However, there is matrix related > > stuff that is at best poorly supported now, namely operations on stacks > > of arrays (or vectors). > > Tim, this is important, but also appears to be a

Re: [Numpy-discussion] untenable matrix behavior in SVN

Gael Varoquaux wrote: > However I would find it nice that, for linear algebra, > x[i, :] == x[:, i].T > > This is the kind of behavior I expect, and we won't be getting it with 1D > arrays. But you WOULD get it with 1-d row/column objects. I'm going to try to summarize what I think is clear fro

[Numpy-discussion] accuracy issues with numpy arrays?

Hi, I'm writing a quick script to import a fits (astronomy) image that has very low values for each pixel. Mostly on the order of 10^-9. I have written a python script that attempts to take low values and put them in integer format. I basically do this by taking the mean of the 1000 lowest pixel v

Re: [Numpy-discussion] untenable matrix behavior in SVN

Bruce Southey wrote: > The ability to treat vectors as matrices would be sufficient for my > needs because these are almost always used in the context of > vector-matrix multiplication. There is no additional benefit from > having row or column shapes or metadata because the row/column nature > is

Re: [Numpy-discussion] untenable matrix behavior in SVN

Keith Goodman wrote: > It would seem odd to me if x[i,:] > returned different types of objects based on the type of i: I think this is where matrices should act like arrays: >>> a array([[0, 1, 2], [3, 4, 5], [6, 7, 8]]) >>> a[:,[1]] array([[1], [4], [7]]) >>>

Re: [Numpy-discussion] untenable matrix behavior in SVN

> I am puzzled by this. What is the rationale for x[i,:] not being a 1-d > object? Does this not require many special-case bits of code as well? > What about a[i,...]? That is what I would use to make a hierarchical > bit of code, and I would be startled to find myself in an infinite > loop waitin

Re: [Numpy-discussion] the path forward

> The problem is that ``x[0]`` being 2d has produced a variety > of anomalies, and the natural fix is for ``x[0]`` to be 1d. > > Gael has argued strongly that she should be able to use the > following notation: ``x[0,:]*A*x[:,0]``. But this will work > only if ``x[0,:]`` is 2d or if it is 1d bu

Re: [Numpy-discussion] failure building numpy using icc

On Tue, Apr 29, 2008 at 01:01:55PM -0500, Charles R Harris wrote: > Not really, it was just a shot in the dark. The thing is, if conv_python is > being run on the same source each time, it should give the same result. So I > suspect that something is changing the sources and that is what I'm tryi

Re: [Numpy-discussion] untenable matrix behavior in SVN

Timothy Hochberg wrote: > However, there is matrix related > stuff that is at best poorly supported now, namely operations on stacks > of arrays (or vectors). Tim, this is important, but also appears to be an orthogonal issue to me -- whatever we do with matrices, rows, columns, whatever, we st

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 11:16:15PM +0200, Anne Archibald wrote: > On 29/04/2008, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote: > > > I am puzzled by this. What is the rationale for x[i,:] not being a 1-d > > > object? > > It breaks

Re: [Numpy-discussion] untenable matrix behavior in SVN

> It breaks A*B[i, :] where A and B are matrices. > > A*B[:,i], surely. right. which is a really good argument for: A * B.col[i] (and .row, or course) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand

Re: [Numpy-discussion] untenable matrix behavior in SVN

Gael Varoquaux wrote: > On Tue, Apr 29, 2008 at 10:49:50AM -0500, Travis E. Oliphant wrote: > >> As the number of special-case work-arounds grows the more I'm convinced >> the conceptualization is wrong. So, I now believe we should change the >> a[i] for matrices to return a 1-d array. >>

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 3:07 PM, Gael Varoquaux < [EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote: > > I am puzzled by this. What is the rationale for x[i,:] not being a 1-d > > object? > > It breaks A*B[i, :] where A and B are matrices. A*B[:,i], surel

Re: [Numpy-discussion] untenable matrix behavior in SVN

On 29/04/2008, Keith Goodman <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 11:21 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote: > > On Tue, 29 Apr 2008, Keith Goodman apparently wrote: > > > I often use x[i,:] and x[:,i] where x is a matrix and i is > > > a scalar. I hope this continues to

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 2:07 PM, Gael Varoquaux < [EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote: > > I am puzzled by this. What is the rationale for x[i,:] not being a 1-d > > object? > > It breaks A*B[i, :] where A and B are matrices. Shouldn't that

Re: [Numpy-discussion] untenable matrix behavior in SVN

On 29/04/2008, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote: > > I am puzzled by this. What is the rationale for x[i,:] not being a 1-d > > object? > > It breaks A*B[i, :] where A and B are matrices. Really? How? In [26]: A = np.matr

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote: > I am puzzled by this. What is the rationale for x[i,:] not being a 1-d > object? It breaks A*B[i, :] where A and B are matrices. Gaël ___ Numpy-discussion mailing list Numpy-discussion@sc

Re: [Numpy-discussion] untenable matrix behavior in SVN

On 29/04/2008, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > I'm quite persuaded now that a[i] should return a 1-d object for > arrays.In addition to the places Chuck identified, there are at > least 2 other places where special code was written to work-around the > expectation that ite

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, Keith Goodman apparently wrote: > here's a use case that currently doesn't work but would be nice > (for me) if it did: > x[idx,i] = M.rand(2,1) I think this is another example of the kind of thing we are trying to fix ... Cheers, Alan Isaac _

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote: > I think the only correct option is the oriented 1D > objects. The second best option is not to change anything > in order not to break backward compatibility. Maybe the extant ``matrix`` class should be available for a while as ``oldmatri

Re: [Numpy-discussion] the path forward

On Tue, 29 Apr 2008, Bruce Southey apparently wrote: > There is no additional benefit from having row or column > shapes or metadata because the row/column nature is > usually predetermined and would be represented by the > shape of the corresponding matrix. The problem is that ``x[0]`` being

[Numpy-discussion] Linear Interpolation 2

Hi All, as I didn't get any answer, I thought I might repost with some more analysis the trouble I am having with interp2d. The attached script produces 3 different results depending on the value of the parameter numColumns, i.e.: 1) numColumns = 20 Traceback (most recent call last): File

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 12:50 PM, Keith Goodman <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 11:46 AM, Keith Goodman <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 11:21 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote: > > > On Tue, 29 Apr 2008, Keith Goodman apparently wrote: > > >

Re: [Numpy-discussion] untenable matrix behavior in SVN

Hi, On Tue, Apr 29, 2008 at 2:22 PM, Timothy Hochberg <[EMAIL PROTECTED]> wrote: > > Let me throw out a couple of more thoughts: > > First, there seems to be disagreement about what a row_vector and > column_vector are (and even if they are sensible concepts, but let's leave > that aside for momen

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 11:46 AM, Keith Goodman <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 11:21 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote: > > On Tue, 29 Apr 2008, Keith Goodman apparently wrote: > > > I often use x[i,:] and x[:,i] where x is a matrix and i is > > > a scalar. I hop

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 03:32:17PM -0400, Alan G Isaac wrote: > On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote: > > Could you remind me which one it is? > Proposal #6 at > http://www.scipy.org/MatrixIndexing#list-of-proposals> > is my effort to summarize what Tim was proposing. > It does n

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 12:22:18PM -0700, Timothy Hochberg wrote: >First, there seems to be disagreement about what a row_vector and >column_vector are (and even if they are sensible concepts, but let's leave >that aside for moment). One school of thought is that they are >one-dimen

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote: > Could you remind me which one it is? Proposal #6 at http://www.scipy.org/MatrixIndexing#list-of-proposals> is my effort to summarize what Tim was proposing. It does not include the oriented 1d vectors that I think you need (if I have under

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 03:20:02PM -0400, Alan G Isaac wrote: > On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote: > > x[i, :]*A*x[:, i] > > I find this cleaner, because more explicit, than x[i]*A*x[:, i]. > >> a. would e.g. ``x[i:i+1,:]`` > > No way. > So *if* ``x[0]`` is going to

Re: [Numpy-discussion] untenable matrix behavior in SVN

Let me throw out a couple of more thoughts: First, there seems to be disagreement about what a row_vector and column_vector are (and even if they are sensible concepts, but let's leave that aside for moment). One school of thought is that they are one-dimensional objects that have some orientation

[Numpy-discussion] Matrix: potential usage case?

Hi everyone, Despite being a bit lost in the matrix debate, today I was working on something which might want to use what is being described. You can see an array only version at: http://fable.svn.sourceforge.net/viewvc/fable/ImageD11/trunk/test/demo/latred.py?revision=2741&view=markup The pro

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote: > x[i, :]*A*x[:, i] > I find this cleaner, because more explicit, than x[i]*A*x[:, i]. >> a. would e.g. ``x[i:i+1,:]`` > No way. So *if* ``x[0]`` is going to be 1d to fix the many anomalies that have surfaced, then you would still

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 02:41:45PM -0400, Alan G Isaac wrote: > On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote: > > I really don't like a[i] != a[i,:]. > Tim H's proposal avoids that problem. > What do you think of it? Sorry, I guess I am lost. Could you remind me which one it is? Given ho

Re: [Numpy-discussion] untenable matrix behavior in SVN

I will answer this question too, because I feel like Keith. On Tue, Apr 29, 2008 at 02:21:34PM -0400, Alan G Isaac wrote: > On Tue, 29 Apr 2008, Keith Goodman apparently wrote: > > I often use x[i,:] and x[:,i] where x is a matrix and i is > > a scalar. I hope this continues to return a matrix.

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 12:41 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote: > On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote: > > I really don't like a[i] != a[i,:]. > > Tim H's proposal avoids that problem. > What do you think of it? > > Of course, now we will have to remove all that special

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 11:21 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote: > On Tue, 29 Apr 2008, Keith Goodman apparently wrote: > > I often use x[i,:] and x[:,i] where x is a matrix and i is > > a scalar. I hope this continues to return a matrix. > > 1. Could you give an example of the circumst

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote: > I really don't like a[i] != a[i,:]. Tim H's proposal avoids that problem. What do you think of it? > I also don't like loosing the information that you are > doing linear algebra. Hmmm. Is it a given that asking for ``a[i]`` is "doing

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, Keith Goodman apparently wrote: > I often use x[i,:] and x[:,i] where x is a matrix and i is > a scalar. I hope this continues to return a matrix. 1. Could you give an example of the circumstances of this use? 2. Would any or all of the following be just as good a result?

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 10:49:50AM -0500, Travis E. Oliphant wrote: > As the number of special-case work-arounds grows the more I'm convinced > the conceptualization is wrong. So, I now believe we should change the > a[i] for matrices to return a 1-d array. > The only down-side I see is that

Re: [Numpy-discussion] failure building numpy using icc

On Tue, Apr 29, 2008 at 11:19 AM, Glen W. Mabey <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 11:24:56AM -0500, Charles R Harris wrote: > > Hmm, something must be mucking with the sources. You can run > conv_template on the pure file from the src directory with > > > > python ../../distuti

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 10:11 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote: > indexing should should work just like ndarray indexing, > except that when it produces a 2d result then a matrix > is returned. (This means giving up the current behavior > of ``x[0,:]``.) I often use x[i,:] and x[:,i] wh

Re: [Numpy-discussion] untenable matrix behavior in SVN

Alan G Isaac wrote: > Perhaps I should note that I have come around to what > I take to be Tim H's view that matrix indexing should should > work just like ndarray indexing, except that when it > produces a 2d result then a matrix is returned. (This means > giving up the current behavior of ``

Re: [Numpy-discussion] failure building numpy using icc

On Tue, Apr 29, 2008 at 11:24:56AM -0500, Charles R Harris wrote: > Hmm, something must be mucking with the sources. You can run conv_template on > the pure file from the src directory with > > python ../../distutils/conv_template.py scalartypes.inc.src > > However, when called from within pyth

Re: [Numpy-discussion] untenable matrix behavior in SVN

>> http://www.scipy.org/MatrixIndexing#guidelines> On Tue, 29 Apr 2008, Christopher Barker apparently wrote: > Here are a few comments on that text In response, I have modified http://www.scipy.org/MatrixIndexing#guidelines> to try to clarify what was meant and perhaps to address your core c

Re: [Numpy-discussion] untenable matrix behavior in SVN

Alan G Isaac wrote: > For useful reference, these are now here: > http://www.scipy.org/MatrixIndexing#guidelines> Thanks Alan, Here are a few comments on that text (I know, I really should go dig up my scipy password...) > 1. Do we want to be able to extract a single row or column from a > m

Re: [Numpy-discussion] failure building numpy using icc

On Tue, Apr 29, 2008 at 9:50 AM, Glen W. Mabey <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 10:41:25AM -0500, Charles R Harris wrote: > > Could you post the new output? The conv_template routine has changed a > bit, you should make sure you have the latest version. Also, it is pure > pytho

Re: [Numpy-discussion] failure building numpy using icc

On Tue, Apr 29, 2008 at 10:41:25AM -0500, Charles R Harris wrote: > Could you post the new output? The conv_template routine has changed a bit, > you should make sure you have the latest version. Also, it is pure python and > the use of icc shouldn't make a difference in substituting the keys in

Re: [Numpy-discussion] untenable matrix behavior in SVN

Charles R Harris wrote: > > > On Tue, Apr 29, 2008 at 7:24 AM, Stéfan van der Walt <[EMAIL PROTECTED] > > wrote: > > Hi Charles > > 2008/4/29 Charles R Harris <[EMAIL PROTECTED] > >: > > May I add that if I edit defmatrix.py to ac

Re: [Numpy-discussion] failure building numpy using icc

On Tue, Apr 29, 2008 at 9:21 AM, Glen W. Mabey <[EMAIL PROTECTED]> wrote: > Robert, > Could you post the new output? The conv_template routine has changed a bit, you should make sure you have the latest version. Also, it is pure python and the use of icc shouldn't make a difference in substituti

Re: [Numpy-discussion] failure building numpy using icc

Robert, I do appreciate your response to this question (oh way back when) and am just now getting back to this problem. On Sat, Mar 01, 2008 at 02:17:46AM -0600, Robert Kern wrote: > On Thu, Feb 28, 2008 at 1:21 PM, Glen W. Mabey <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I'm using svn numpy

Re: [Numpy-discussion] Can anyone look at #759

David Cournapeau wrote: > Hi, > > I have a patch for an issue which had bugged me for some time, but > since I am not familiar with that part of numpy code, I would prefer > someone checking I am not doing anything stupid before checking in, > It looks good to me. -teo __

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, Apr 29, 2008 at 7:24 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > Hi Charles > > 2008/4/29 Charles R Harris <[EMAIL PROTECTED]>: > > May I add that if I edit defmatrix.py to act like an array for scalar > > indexing, then the following works. > > > > In [1]: a = matrix(eye(2)) > >

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, Stéfan van der Walt apparently wrote: > We were thinking of raising a warning on scalar indexing > for 1.1, but given the above, would that be sensical? There seem to be three basic proposals for scalar indexing: - raise an error - return a 1d array - return a new type of 1

Re: [Numpy-discussion] untenable matrix behavior in SVN

On Tue, 29 Apr 2008, Charles R Harris apparently wrote: > There are recursive routines that expect the dimensions to > decrease on each call. I have added your example as anomaly #2 at the very top of the discussion page: http://www.scipy.org/MatrixIndexing> Cheers, Alan Isaac _

Re: [Numpy-discussion] untenable matrix behavior in SVN

Hi Charles 2008/4/29 Charles R Harris <[EMAIL PROTECTED]>: > May I add that if I edit defmatrix.py to act like an array for scalar > indexing, then the following works. > > In [1]: a = matrix(eye(2)) > > In [2]: array([a,a]) > Out[2]: > array([[[ 1., 0.], > [ 0., 1.]], > >[[ 1.,

Re: [Numpy-discussion] Matrix Class [was numpy release]

On Apr 29, 2008, at 2:50 AM, Robert Cimrman wrote: > FYI: > In scipy, the iterative solvers (cg and like) should work with > LinearOperator (a class with matvec, rmatvec, and eventually matmat > methods) passed instead of the A matrix argument. There is a function > aslinearoperator() is scipy.spa

[Numpy-discussion] Can anyone look at #759

Hi, I have a patch for an issue which had bugged me for some time, but since I am not familiar with that part of numpy code, I would prefer someone checking I am not doing anything stupid before checking in, http://www.scipy.org/scipy/numpy/ticket/759 cheers, David ___

Re: [Numpy-discussion] Matrix Class [was numpy release]

Bill Spotz wrote: > On Apr 28, 2008, at 10:47 PM, Bill Spotz wrote: > >> As for this example, my version should work with a properly >> implemented sparse_matrix A, but the array approach precludes that. >> That is to say, I could convert A to a matrix if it is provided as an >> array, but you cou

Re: [Numpy-discussion] Starting to work on runtime plugin system for plugin (automatic sse optimization, etc...)

Stéfan van der Walt wrote: > Don't let me distract you, I'm very keen to see what you come up with! > Well, the point of making my preliminary work public is to get "distracted", as you put it :) It is really easy to come up with something not that useful without feedback or people remarks.