[Numpy-discussion] rollaxis
So, In [14]: x = zeros((2,3,4)) In [15]: rollaxis(x,0,3).shape Out[15]: (3, 4, 2) In [16]: rollaxis(x,0,2).shape Out[16]: (3, 2, 4) In [17]: rollaxis(x,0,1).shape Out[17]: (2, 3, 4) In [18]: rollaxis(x,0,0).shape Out[18]: (2, 3, 4) How come rollaxis(x,0,0) doesn't move 2 to the end ;) That's what the documentation implies. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy svn down
On Sat, Jul 17, 2010 at 17:06, Charles R Harris wrote: > At the moment... Chuck I can svn up at the moment. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy svn down
Sat, 17 Jul 2010 16:06:40 -0600, Charles R Harris wrote: > At the moment... Chuck Worksforme at the moment. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy svn down
At the moment... Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Crosstabulation
2010/7/17 Robert Kern : > On Sat, Jul 17, 2010 at 13:11, Friedrich Romstedt > wrote: >> 2010/7/14 Ionut Sandric : >> I'm afraid also Zach does not understand what you are talking about >> ... So my first question (please bear with me) would be: What's a dem? > > Digital Elevation Map. > >> (n/a in my dictionary) And sorry for the cross-talk on the other >> first post by you ... >> >> And by slope gradient you mean second derivative? > > No, the first derivative. "Slope gradient" is a reasonably common, > albeit somewhat redundant, idiom meaning the gradient of an elevation > map. Thanks Robert, that clarifies a lot. But still I don't understand how the crosstabulation shall work. What are the "classes"? Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PyDocWeb "the doc editor" and github transition
On Sat, Jul 17, 2010 at 1:47 PM, Pauli Virtanen wrote: > Sat, 17 Jul 2010 13:11:46 -0600, Vincent Davis wrote: >> I have not seen anything about the move to github and how this effects >> pydocweb or did I just miss it. I am willing to adapt pydocweb to work >> with github but not sure what the desired integration would be. This >> should not be to difficult but should/needs to be part of the plan and >> documented. > > You do not need to make any changes to the doc editor because of the > github move -- only to its configuration. The documentation editor app > itself does not know or care what the version control system is. > > The required change is essentially replacing > > svn checkout ... > svn update > > by > > git clone ... > git pull ... > > in a shell script, and clearing up the checkout directories. I can take > care of this on the server machine, once the move to git has been made. I was thinking it was that simple. Should it clone/pull.. from the master branch? Thanks Vincent > > -- > Pauli Virtanen > > ___ > 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
Re: [Numpy-discussion] PyDocWeb "the doc editor" and github transition
Sat, 17 Jul 2010 13:11:46 -0600, Vincent Davis wrote: > I have not seen anything about the move to github and how this effects > pydocweb or did I just miss it. I am willing to adapt pydocweb to work > with github but not sure what the desired integration would be. This > should not be to difficult but should/needs to be part of the plan and > documented. You do not need to make any changes to the doc editor because of the github move -- only to its configuration. The documentation editor app itself does not know or care what the version control system is. The required change is essentially replacing svn checkout ... svn update by git clone ... git pull ... in a shell script, and clearing up the checkout directories. I can take care of this on the server machine, once the move to git has been made. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Crosstabulation
On Sat, Jul 17, 2010 at 13:11, Friedrich Romstedt wrote: > 2010/7/14 Ionut Sandric : >> By raster data I mean classified slope gradient (derived from a dem), >> landuse-landcover, lithology etc. A crosstabulation analysis will give me a >> table with the common areas for each class from each raster and this will go >> into other analysis. I can do it with other softwares (like ArcGIS DEsktop >> etc), but I would like to have all with numpy or to build something on top >> of numpy > > I'm afraid also Zach does not understand what you are talking about > ... So my first question (please bear with me) would be: What's a dem? Digital Elevation Map. > (n/a in my dictionary) And sorry for the cross-talk on the other > first post by you ... > > And by slope gradient you mean second derivative? No, the first derivative. "Slope gradient" is a reasonably common, albeit somewhat redundant, idiom meaning the gradient of an elevation map. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] PyDocWeb "the doc editor" and github transition
I have not seen anything about the move to github and how this effects pydocweb or did I just miss it. I am willing to adapt pydocweb to work with github but not sure what the desired integration would be. This should not be to difficult but should/needs to be part of the plan and documented. My initial thought is to create a branch for the doc editor. My only thought is to allow the doc editor (and those administering it) to maintain a github repo/branch and then allow those that are in control of the numpy/scipy source to merge/pull the docs with the doc repo/branch. (tell me what to do and I will work on it) Vincent ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.5.x branched
On Sat, Jul 17, 2010 at 12:32 PM, Pauli Virtanen wrote: > Dear all, > > Based on patches contributed by Christoph Gohlke, I've created a branch > for 1.5.x: > >http://svn.scipy.org/svn/numpy/branches/1.5.x > > It should be > > a) Binary compatible with Numpy 1.4 on Python 2.x. > > This meant rolling back the datetime and a couple other changes. > > b) Support Python 3.1 and 2.7. > > I expect it will be easy to track changes in the trunk, even if preparing > the release will still take some time. > > Probably best to get started. The changes I want to put in are small additions and won't be difficult to backport as long as Ralf doesn't put out the first release this evening ;) Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 1.5.x branched
Dear all, Based on patches contributed by Christoph Gohlke, I've created a branch for 1.5.x: http://svn.scipy.org/svn/numpy/branches/1.5.x It should be a) Binary compatible with Numpy 1.4 on Python 2.x. This meant rolling back the datetime and a couple other changes. b) Support Python 3.1 and 2.7. I expect it will be easy to track changes in the trunk, even if preparing the release will still take some time. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Crosstabulation
2010/7/14 Ionut Sandric : > By raster data I mean classified slope gradient (derived from a dem), > landuse-landcover, lithology etc. A crosstabulation analysis will give me a > table with the common areas for each class from each raster and this will go > into other analysis. I can do it with other softwares (like ArcGIS DEsktop > etc), but I would like to have all with numpy or to build something on top of > numpy I'm afraid also Zach does not understand what you are talking about ... So my first question (please bear with me) would be: What's a dem? (n/a in my dictionary) And sorry for the cross-talk on the other first post by you ... And by slope gradient you mean second derivative? Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Crosstab
2010/7/14 Ionut Sandric : > I have two raster data and I would like to do a crosstabulation between them > and export the results to a table in a text file. Is it possible to do it > with NumPy? Does someone have an example? Am I understanding you correctly when I suppose you mean what is explained in Wikipedia under the name contingency table? http://en.wikipedia.org/wiki/Contingency_table . I got this from http://en.wikipedia.org/wiki/Crosstabulation . ? But then it doesn't make much sense to me. Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Difference between shape=() and shape=(1,)
2010/7/14 John Reid : > That sounds useful but I should have said: sometimes I need to replace > other values that aren't NaNs. Sorry, for the double dumb recommendation of nan_to_num, but when replacing other normal values mabe you can use: >>> a = numpy.asarray(1) >>> b = numpy.asarray([10, 1]) >>> a *= (a != 1) >>> b *= (b != 1) >>> a array(0) >>> b array([10, 0]) We have tested this for speed and it's even faster than the slicing-and-insert method. When having to replace, you can use a composite approach, e.g. to replace 1 by 1: >>> b = (b * (b != 1) + 1 * (b == 1)) I don't know how to replace nans by values other than zero. Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Difference between shape=() and shape=(1,)
2010/7/13 John Reid : > Hi, > > I have some arrays of various shapes in which I need to set any NaNs to > 0. I just ran across numpy.nan_to_num(): >>> a = numpy.log(-1) >>> b = numpy.log([-1, 1]) >>> a nan >>> b array([ NaN, 0.]) >>> numpy.nan_to_num(a) 0.0 >>> numpy.nan_to_num(b) array([ 0., 0.]) Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] __array__struct__: about using PyCapsule instead of PyCObject for Python 2.7
On Sat, Jul 17, 2010 at 8:51 AM, Pauli Virtanen wrote: > Wed, 30 Jun 2010 12:13:38 -0600, Charles R Harris wrote: > [clip] > >> > Grrr... I didn't see the point, myself, I'm tempted to deprecate 2.7 > >> > just > >> to > >> > get even. There are some routines in the numpy/core/src includes that > >> > you might want to copy, they will allow you to use a common interface > >> > for PyCObject and PyCapsule if you need to do that. > >> > > >> > > >> I've already fixed my code for PyCapsule. What's not clear to me is how > >> to build (i.e, use the old cobject or the new capsules) > >> __array_struct__ across NumPy and Python versions combinations. Will > >> NumPy 1.x series ever support Python 2.7? In such case, should I use > >> cobjects or capsules? > > > > We do support 2.7, but with PyCapsule. You might want to take a look at > > f2py also, as it also uses PyCapsule for Python >= 2.7. > > I think we need to change this decision. PyCObject is still available on > Python 2.7, and will only raise a PendingDeprecationWarning, which does > not show up by default. I believe the Python devs reversed the full > deprecation before the final 2.7 release. > > So I think we should just stick with PyCObject on 2.x, as we have done so > far. I'll just bump the version checks so that PyCapsule is used only on > 3.x. > > I'll commit this to Numpy SVN soon. > > Now that npy_3kcompat.h is public we can probably remove some of the version checks. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] __array__struct__: about using PyCapsule instead of PyCObject for Python 2.7
Wed, 30 Jun 2010 12:13:38 -0600, Charles R Harris wrote: [clip] >> > Grrr... I didn't see the point, myself, I'm tempted to deprecate 2.7 >> > just >> to >> > get even. There are some routines in the numpy/core/src includes that >> > you might want to copy, they will allow you to use a common interface >> > for PyCObject and PyCapsule if you need to do that. >> > >> > >> I've already fixed my code for PyCapsule. What's not clear to me is how >> to build (i.e, use the old cobject or the new capsules) >> __array_struct__ across NumPy and Python versions combinations. Will >> NumPy 1.x series ever support Python 2.7? In such case, should I use >> cobjects or capsules? > > We do support 2.7, but with PyCapsule. You might want to take a look at > f2py also, as it also uses PyCapsule for Python >= 2.7. I think we need to change this decision. PyCObject is still available on Python 2.7, and will only raise a PendingDeprecationWarning, which does not show up by default. I believe the Python devs reversed the full deprecation before the final 2.7 release. So I think we should just stick with PyCObject on 2.x, as we have done so far. I'll just bump the version checks so that PyCapsule is used only on 3.x. I'll commit this to Numpy SVN soon. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] _wrapit bug?
On Sun, Jun 20, 2010 at 2:43 PM, Benjamin Root wrote: > Hi, I was just digging through the fromnumeric.py code when I noticed that > the function _wrapit used asarray() rather than asanyarray(). I don't know > if this function really gets used anymore (as it gets called in special > situations), but would seem to be an issue as it would cause arrays such as > masked_array to lose its type. For example, if _wrapit was called for a > max() function on a masked array, the max returned would be for the > ndarray's max, not the masked_array's max. > > Let me know if this is a non-issue, I just thought I ought to point it out. > > Looks like fromnumeric.py has it's own version of masked arrays. Wasn't there some talk of removing some of these old compatibility functions? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
