Re: [Numpy-discussion] 1.10.x is branched

On Mon, Aug 3, 2015 at 5:22 AM, Charles R Harris wrote: > Hi All, > > Numpy 1.10.x is branched. There is still some cleanup to do before the > alpha release, but that should be coming in a couple of days. > > Thanks Chuck. Looks like it's

Re: [Numpy-discussion] Change default order to Fortran order

This is very good discussion. Thank you all for replying. I can see the fundamental difference is that I always think/talk/read/write a 3D image as I(x, y, z), not (plane, row, column) . I am coming from MRI (magnetic resonance imaging) research, and I can assure you that the entire MRI communi

Re: [Numpy-discussion] Change default order to Fortran order

Hi Kang, Feel free to come chat about your application on the scikit-image list [1]! I'll note that we've been through the array order discussion many times there and even have a doc page about it [2]. The short version is that you'll save yourself a lot of pain by starting to think of your image

Re: [Numpy-discussion] Change default order to Fortran order

Kang, Thank you for explaining your motivation. It's clear from your last note, as you said, that your desire for column-first indexing has nothing to do with in-memory data layout. That being the case, I strongly urge you to just use bare numpy and do not use the "fortran_zeros" function I recomm

[Numpy-discussion] 1.10.x is branched

Hi All, Numpy 1.10.x is branched. There is still some cleanup to do before the alpha release, but that should be coming in a couple of days. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-

Re: [Numpy-discussion] Change default order to Fortran order

Just chiming in with my 2 cents, in direct response to your points... - Image oriented processing is most typically done with row-major storage layout. From hardware to general software implementations. - Well really think of it as [slice,] row, column (logical)... you don't actually

Re: [Numpy-discussion] Change default order to Fortran order

Thank you all for replying and providing useful insights and suggestions. The reasons I really want to use column-major are: I am image-oriented user (not matrix-oriented, as explained in  http://docs.scipy.org/doc/numpy/reference/internals.html#multidimensional-array-indexing-order-issue

Re: [Numpy-discussion] Change default order to Fortran order

On Aug 2, 2015 7:30 AM, "Sturla Molden" wrote: > > On 02/08/15 15:55, Kang Wang wrote: > > > Can anyone provide any insight/help? > > There is no "default order". There was before, but now all operators > control the order of their return arrays from the order of their input > array. This is... o

Re: [Numpy-discussion] Change default order to Fortran order

Could you please explain why you need 'F' ordering? It's pretty unlikely that you actually care about the internal memory layout, and you'll get better advice if you explain why you think you do care. > My first Python project is to somehow modify NumPy source > code such that everything is Fortra

Re: [Numpy-discussion] Change default order to Fortran order

On Aug 2, 2015 1:17 PM, "Kang Wang" wrote: > > Thank you all for replying! > > I did a quick test, using python 2.6.6, There's pretty much no good reason these days to be using python 2.6 (which was released in *2008*). I assume you're using it because you're using redhat or some redhat derivativ

Re: [Numpy-discussion] Change default order to Fortran order

On Aug 2, 2015 6:59 AM, "Kang Wang" wrote: > > Hi, > > I am an imaging researcher, and a new Python user. My first Python project is to somehow modify NumPy source code such that everything is Fortran column-major by default. > > I read about the information in the link below, but for us, the fact

Re: [Numpy-discussion] Change default order to Fortran order

On 02/08/15 22:28, Bryan Van de Ven wrote: > And to eliminate the order kwarg, use functools.partial to patch the zeros > function (or any others, as needed): This will probably break code that depends on NumPy, like SciPy and scikit-image. But if NumPy is all that matters, sure go ahead and mon

Re: [Numpy-discussion] Change default order to Fortran order

And to eliminate the order kwarg, use functools.partial to patch the zeros function (or any others, as needed): In [26]: import numpy as np In [27]: from functools import partial In [28]: np.zeros = partial(np.zeros, order="F") In [29]: x = np.zeros((2,3), dtype

Re: [Numpy-discussion] Change default order to Fortran order

On 02/08/15 22:14, Kang Wang wrote: > Thank you all for replying! > > I did a quick test, using python 2.6.6, and the original numpy package > on my Linux computer without any change. > == > x = np.zeros((2,3),dtype=np.int32,order='F') > print "x.strides =" > print x.strides > > y = x + 1 > print "

Re: [Numpy-discussion] Change default order to Fortran order

Thank you all for replying! I did a quick test, using python 2.6.6, and the original numpy package on my Linux computer without any change.== x = np.zeros((2,3),dtype=np.int32,order='F') print "x.strides =" print x.strides y = x + 1 print "y.strides =" print y.strides == Output: x.s

Re: [Numpy-discussion] Change default order to Fortran order

Well, numpy has a tendency to prefer C order. There is nothing you can do about that really. But you just cannot be sure what you get in some cases. Often you need something specific for interfaceing other code. But in that case quite often you also do not need to fear the copy. - Sebastian

Re: [Numpy-discussion] Change default order to Fortran order

On 02/08/15 15:55, Kang Wang wrote: > Can anyone provide any insight/help? There is no "default order". There was before, but now all operators control the order of their return arrays from the order of their input array. The only thing that makes C order "default" is the keyword argument to n

[Numpy-discussion] Change default order to Fortran order

Hi, I am an imaging researcher, and a new Python user. My first Python project is to somehow modify NumPy source code such that everything is Fortran column-major by default. I read about the information in the link below, but for us, the fact is that we absolutely want to use Fortran column

Re: [Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

On 31/07/15 09:38, Julian Taylor wrote: > A long is only machine word wide on posix, in windows its not. Actually it is the opposite. A pointer is 64 bit on AMD64, but the native integer and pointer offset is only 32 bit. But it does not matter because it is int that should be machine word size

Re: [Numpy-discussion] mailmap update

Hi Chuck, Tom Poole gmail.com > tpoole gmail.com > Tom > On 2 Aug 2015, at 06:08, Charles R Harris wrote: > > Hi All, > > I'm trying to update the .mailmap file on github and could use some help. The > current version seems common to both numpy and sc