Re: [Numpy-discussion] Resolving the associativity/precedence debate for @
Hi Nate, Many thanks first for the efforts you put in this. I'm not a computer scientist, but will give my opinion as physicist. As such, when I see A x B x C (A, B and C being matrices), I tend to read it from right to left : Ax (BxC). But if the size of the matrices do not match like this, then I'll read it the other way round. Moreover, matrix diagonalization is always written so that the operations are done from right to left (P^-1 x A x P is read do AxP first, then multiply by P⁻1) Éric. -- Un clavier azerty en vaut deux -- Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering
Hi all, Since we're mentionning obvious and non-obvious naming, > > I think you agree that there is potential for confusion, and there > doesn't seem any reason to continue with that confusion if we can come > up with a clearer name. > > So here is a compromise proposal. > > How about: > > * Preferring the names 'c-style' and 'f-style' for the indexing order > case (ravel, reshape, flatiter) This naming scheme is obvious for the ones that have been doing some coding for a long time, but they tend not to speak to anyone else. Why not use naming that are a little bit more explicit (and of course, keep the legacy naming available), and use 'row-first' and 'column-first' (or anything else that may be more explicit) ? Cheers, Éric. > * Leaving 'C" and 'F' as functional shortcuts, so there is no possible > backwards-compatibility problem. > > Would you object to that? > > Cheers, > > Matthew > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion Un clavier azerty en vaut deux -- Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Le jeudi 28 juin 2012 15:33:07, Travis Oliphant a écrit : > There are some good ideas here. > > I propose splitting this list into devel and users lists. > > This might best be done by creating a new list for users and using this > list for development. I second that idea. As one of the silent users of the list, with not (so) much interest in the details of the development (and even less in the public display of personal dislikes , I'd be happy to switch to a more users-oriented list. Éric. > > Travis > > -- > Travis Oliphant > (on a mobile) > 512-826-7480 > > On Jun 27, 2012, at 11:38 PM, srean wrote: > > Hi List, > > > > this has been brought up several times, and the response has been > > generally positive but it has fallen through the cracks. So here are a > > few repeat requests. Am keeping it terse just for brevity > > > > i) Split the list into [devel] and [help] and as was mentioned > > > > recently [rant/flame]: > > some request for help get drowned out during active development > > > > related discussions and simple help requests pollutes more urgent > > development related matters. > > > > ii) Stackoverflow like site for help as well as for proposals. > > > >The silent majority has been referred to a few times recently. I > > > > suspect there does exist many lurkers on the list who do prefer one > > discussed solution over the other but for various reasons do not break > > out of their lurk mode to send a mail saying "I prefer this solution". > > Such an interface will also help in keeping track of the level of > > support as compared to mails that are larges hunks of quoted text with > > a line or two stating ones preference or seconding a proposal. > > > > One thing I have learned from traffic accidents is that if one asks > > for a help of the assembled crowd, no one knows how to respond. On the > > other hand if you say "hey there in a blue shirt could you get some > > water" you get instant results. So pardon me for taking the > > presumptuous liberty to request Travis to please set it up or > > delegate. > > > > Splitting the lists shouldn't be hard work, setting up overflow might > > be more work in comparison. > > > > Best > > -- srean > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Un clavier azerty en vaut deux -- Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Possible roadmap addendum: building better text file readers
> But why, oh why, are people storing big data in CSV? Well, that's what scientist do :-) Éric. > > G > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion Un clavier azerty en vaut deux ------ Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Possible roadmap addendum: building better text file readers
Le jeudi 23 février 2012 21:24:28, Wes McKinney a écrit : > That would indeed be great. Reading large files is a real pain whatever the python method used. BTW, could you tell us what you mean by large files? cheers, Éric. > Sweet, between this, Continuum folks, and me and my guys I think we > can come up with something good and suits all our needs. We should set > up some realistic performance test cases that we can monitor via > vbench (wesm/vbench) while we're work on the project. > Un clavier azerty en vaut deux ------ Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] index the last several members of a ndarray
Le mardi 18 octobre 2011 13:44:00, Chao YUE a écrit : > Dear all, > > if I have > > In [395]: a > Out[395]: > array([[0, 1, 2, 3, 4], >[5, 6, 7, 8, 9]]) > > In [396]: a[...,-1] > Out[396]: array([4, 9]) > > In [397]: a[...,-4:-1] > Out[397]: > array([[1, 2, 3], >[6, 7, 8]]) > > In [398]: a[...,-4:0] > Out[398]: array([], shape=(2, 0), dtype=int64) > > how can I pick up something like: > array([[1, 2, 3, 4], >[6, 7, 8, 9]]) > > I want to index the final 4 rows. I cannot figure out how to do this? > Don't you want to do : In [1]: a[:,-4:] Out[1]: array([[1, 2, 3, 4], [6, 7, 8, 9]]) Éric. > Thanks for any help, > > Chao Un clavier azerty en vaut deux -- Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with Numpy and array
Le jeudi 12 mai 2011 12:21:46, Claudia Chan Yone a écrit :
> Hi,
>
> I have a problem with the Numpy module, but I think it is a very basic
> issue for many of you...
> I have a file with numerical data (2 columns, and 5 lignes) as :
> 1 2
> 3 4
> ... ...
>
> And I woulid like to convert it in a matrix as :
> [[1,2]
> [3,4]
> ...]
>
> My python script is :
>
> fic=open('file.txt','r')
> ligne=fic.readlines()
> fic.close()
>
> m=numpy.array(ligne)
>
> and I get :
> ['1,2\n' '3,4']
>
> So I cannot call m[0][0]...
>
> Even if I modify my text file with :
> [[1,2],
> [3,4]
> ...]
>
> I get :
>
> ['[[1,2],[3,4]]'] and I cannot call m[0][0].
>
> Thank you very much for your help,
>
>
> Clo
numpy.loadtxt() is probably what you need here.
hth.
Éric.
--
Un clavier azerty en vaut deux
--
Éric Depagnee...@depagne.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.histogram on arrays.
> > Well I guess, for a slight performance improvement, you could create your > own streamlined histogrammer. > > But, in order to better grasp your situation it would be beneficial to know > how the counts and bounds are used later on. Just wondering if this kind > massive histogramming could be somehow avoided totally. Indeed. Here's what I do. My images come from CCD, and as such, the zero level in the image is not the true zero level, but is the true zero + the background noise of each pixels. By doing the histogram, I plan on detecting what is the most common value per row. Once I have the most common value, I can derive the interval where most of the values are (the index of the largest occurence is easily obtained by sorting the counts, and I take a slice [index_max_count,index_max_count+1] in the second array given by the histogram). Then, I take the mean value of this interval and I assume it is the value of the bias for my row. I do this procedure both on the row and columns as a sanity check. And I know this procedure will not work if on any row/column there is a lot of signal and very little bias. I'll fix that afterwards ;-) Éric. > > Regards, > eat > Un clavier azerty en vaut deux ------ Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.histogram on arrays.
Hi. Sorry for not having been clearer. I'll explain a little bit. I have 4k x 4k images that I want to analyse. I turn them into numpy arrays so I have 4k x 4k np.array. My analysis starts with determining the bias level. To do that, I compute for each line, and then for each row, an histogram. So I compute 8000 histograms. Here is the code I've used sofar: for i in range(self.data.shape[0]): #Compute an histogram along the columns # Gets counts and bounds self.countsC[i], self.boundsC[i] = np.histogram(data[i], bins=self.bins) for i in range(self.data.shape[1]): # Do the same, along the rows. self.countsR[i], self.boundsR[i] = np.histogram(data[:,i], bins=self.bins) And data.shape is (4000,4000). If histogram had an axis parameter, I could avoid the loop and I guess it would be faster. Éric. > So it seems that you give your array directly to histogramdd (asking a > 4000D histogram!). Surely that's not what you are trying to achieve. Can > you elaborate more on your objectives? Perhaps some code (slow but > working) to demonstrate the point. > > Regards, > eat > Un clavier azerty en vaut deux ------ Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.histogram on arrays.
> FWIW, have you considered to use > http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogramdd.html# > numpy.histogramdd > > Regards, > eat > I tried, but I get a /usr/lib/pymodules/python2.6/numpy/lib/function_base.pyc in histogramdd(sample, bins, range, normed, weights) 370 # Reshape is used so that overlarge arrays 371 # will raise an error. --> 372 hist = zeros(nbin, float).reshape(-1) 373 374 # Compute the sample indices in the flattened histogram matrix. ValueError: sequence too large; must be smaller than 32 so I suspect my array is too big for histogramdd Éric. -- Un clavier azerty en vaut deux ---------- Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] np.histogram on arrays.
Hi all. Sorry if this question has already been asked. I've searched the archive, but could not find anything related, so here is my question. I'm using np.histogram on a 4000x4000 array, each with 200 bins. I do that on both dimensions, meaning I compute 8000 histograms. It takes around 5 seconds (which is of course quite fast). I was wondering why np.histogram does not accept an axis parameter so that it could work directly on the array without me having to write a loop. Or maybe did I miss some parameters using np.histogram. Thanks. Éric. Un clavier azerty en vaut deux -- Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
