Re: [Numpy-discussion] np.array execution path
On Sat, Sep 22, 2012 at 1:00 PM, Sebastian Haase seb.ha...@gmail.com wrote: Oh, is this actually documented - I knew that np.array would (by default) only create copies as need ... but I never knew it would - if all fits - even just return the original Python-object... was that a typo? is is asarray that returns the orignal object if it can. That's kin dof the point. Perhaps the OP was confusing asarray() with .view(). IIUC, .view() will always create a new ndarray object, but will use the same internal data pointer. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.array execution path
On Mon, Sep 24, 2012 at 7:09 PM, Chris Barker chris.bar...@noaa.gov wrote: On Sat, Sep 22, 2012 at 1:00 PM, Sebastian Haase seb.ha...@gmail.com wrote: Oh, is this actually documented - I knew that np.array would (by default) only create copies as need ... but I never knew it would - if all fits - even just return the original Python-object... was that a typo? is is asarray that returns the orignal object if it can. That's kin dof the point. well, I have misread the original post . so never mind my question ... - Sebastian Haase Perhaps the OP was confusing asarray() with .view(). IIUC, .view() will always create a new ndarray object, but will use the same internal data pointer. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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] np.array execution path
In case you are interested, the second (real odditiy), is caused by ISFORTRAN and IS_F_CONTIGUOUS mixup, I have found three occurances where I think ISFORTRAN should be replaced by the latter. Check also: https://github.com/seberg/numpy/commit/4d2713ce8f2107d225fe291f5da6c6a75436647e Sebastian On Sat, 2012-09-22 at 13:12 -0500, Travis Oliphant wrote: Check to see if this expression is true no is o In the first case no and o are the same object Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Sep 22, 2012, at 1:01 PM, Sebastian Berg sebast...@sipsolutions.net wrote: Hi, I have a bit of trouble figuring this out. I would have expected np.asarray(array) to go through ctors, PyArray_NewFromArray, but it seems to me it does not, so which execution path is exactly taken here? The reason I am asking is that I want to figure out this behavior/bug, and I really am not sure which function is responsible: In [69]: o = np.ones(3) In [70]: no = np.asarray(o, order='C') In [71]: no[:] = 10 In [72]: o # OK, o was changed in place: Out[72]: array([ 10., 10., 10.]) In [73]: no.flags # But no claims to own its data! Out[73]: C_CONTIGUOUS : True F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False In [74]: no = np.asarray(o, order='F') In [75]: no[:] = 11 In [76]: o # Here asarray actually returned a real copy! Out[76]: array([ 10., 10., 10.]) Thanks, Sebastian ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.array execution path
On Sat, Sep 22, 2012 at 10:24 PM, Sebastian Berg sebast...@sipsolutions.net wrote: In case you are interested, the second (real odditiy), is caused by ISFORTRAN and IS_F_CONTIGUOUS mixup, I have found three occurances where I think ISFORTRAN should be replaced by the latter. Check also: https://github.com/seberg/numpy/commit/4d2713ce8f2107d225fe291f5da6c6a75436647e So I guess we have this ISFORTRAN function (also exposed to Python[1]). It's documented as checking the rather odd condition of an array being in fortran-order AND having ndim 1. Sebastian, as part of polishing up some of our contiguity-handling code, is suggesting changing this so that ISFORTRAN is true for an array that is (fortran order !C order). Off the top of my head I can't think of any situation where *either* of these predicates is actually useful. (I can see why you want to check if an array is in fortran order, but not why it'd be natural to check whether it's in fortran order and also these other conditions together in one function call.) The problem is, this makes it hard to know whether Sebastian's change is a good idea. Can anyone think of legitimate uses for ISFORTRAN? Or should it just be deprecated altogether? -n [1] http://docs.scipy.org/doc/numpy/reference/generated/numpy.isfortran.html ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.array execution path
On Sun, 2012-09-23 at 18:54 +0100, Nathaniel Smith wrote: On Sat, Sep 22, 2012 at 10:24 PM, Sebastian Berg sebast...@sipsolutions.net wrote: In case you are interested, the second (real odditiy), is caused by ISFORTRAN and IS_F_CONTIGUOUS mixup, I have found three occurances where I think ISFORTRAN should be replaced by the latter. Check also: https://github.com/seberg/numpy/commit/4d2713ce8f2107d225fe291f5da6c6a75436647e So I guess we have this ISFORTRAN function (also exposed to Python[1]). It's documented as checking the rather odd condition of an array being in fortran-order AND having ndim 1. Sebastian, as part of polishing up some of our contiguity-handling code, is suggesting changing this so that ISFORTRAN is true for an array that is (fortran order !C order). Off the top of my head I can't think of any situation where *either* of these predicates is actually useful. (I can see why you want to check if an array is in fortran order, but not why it'd be natural to check whether it's in fortran order and also these other conditions together in one function call.) The problem is, this makes it hard to know whether Sebastian's change is a good idea. Can anyone think of legitimate uses for ISFORTRAN? Or should it just be deprecated altogether? Maybe I am missing things, but I think ISFORTRAN is used to decide the order in which a new array is requested when Anyorder is used. In some use cases it does not matter, but for example in these cases (where the new array has a different shape then the original) it would change if you just changed ISFORTRAN: a = np.ones(4) # C/F-Contig a.reshape(2,2, order='A') np.add.outer(a, a, order='A') These would return Fortran order instead of C if ISFORTRAN did not check dimension 1 (or equivalently !c-contig). -n [1] http://docs.scipy.org/doc/numpy/reference/generated/numpy.isfortran.html ___ 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
[Numpy-discussion] np.array execution path
Hi, I have a bit of trouble figuring this out. I would have expected np.asarray(array) to go through ctors, PyArray_NewFromArray, but it seems to me it does not, so which execution path is exactly taken here? The reason I am asking is that I want to figure out this behavior/bug, and I really am not sure which function is responsible: In [69]: o = np.ones(3) In [70]: no = np.asarray(o, order='C') In [71]: no[:] = 10 In [72]: o # OK, o was changed in place: Out[72]: array([ 10., 10., 10.]) In [73]: no.flags # But no claims to own its data! Out[73]: C_CONTIGUOUS : True F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False In [74]: no = np.asarray(o, order='F') In [75]: no[:] = 11 In [76]: o # Here asarray actually returned a real copy! Out[76]: array([ 10., 10., 10.]) Thanks, Sebastian ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.array execution path
Check to see if this expression is true no is o In the first case no and o are the same object Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Sep 22, 2012, at 1:01 PM, Sebastian Berg sebast...@sipsolutions.net wrote: Hi, I have a bit of trouble figuring this out. I would have expected np.asarray(array) to go through ctors, PyArray_NewFromArray, but it seems to me it does not, so which execution path is exactly taken here? The reason I am asking is that I want to figure out this behavior/bug, and I really am not sure which function is responsible: In [69]: o = np.ones(3) In [70]: no = np.asarray(o, order='C') In [71]: no[:] = 10 In [72]: o # OK, o was changed in place: Out[72]: array([ 10., 10., 10.]) In [73]: no.flags # But no claims to own its data! Out[73]: C_CONTIGUOUS : True F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False In [74]: no = np.asarray(o, order='F') In [75]: no[:] = 11 In [76]: o # Here asarray actually returned a real copy! Out[76]: array([ 10., 10., 10.]) Thanks, Sebastian ___ 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] np.array execution path
Ooops obviously thanks a lot, stupid me. Thanks was also enough to figure the rest out myself... On Sat, 2012-09-22 at 13:12 -0500, Travis Oliphant wrote: Check to see if this expression is true no is o In the first case no and o are the same object Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Sep 22, 2012, at 1:01 PM, Sebastian Berg sebast...@sipsolutions.net wrote: Hi, I have a bit of trouble figuring this out. I would have expected np.asarray(array) to go through ctors, PyArray_NewFromArray, but it seems to me it does not, so which execution path is exactly taken here? The reason I am asking is that I want to figure out this behavior/bug, and I really am not sure which function is responsible: In [69]: o = np.ones(3) In [70]: no = np.asarray(o, order='C') In [71]: no[:] = 10 In [72]: o # OK, o was changed in place: Out[72]: array([ 10., 10., 10.]) In [73]: no.flags # But no claims to own its data! Out[73]: C_CONTIGUOUS : True F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False In [74]: no = np.asarray(o, order='F') In [75]: no[:] = 11 In [76]: o # Here asarray actually returned a real copy! Out[76]: array([ 10., 10., 10.]) Thanks, Sebastian ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.array execution path
Oh, is this actually documented - I knew that np.array would (by default) only create copies as need ... but I never knew it would - if all fits - even just return the original Python-object... Thanks, Sebastian Haase On Sat, Sep 22, 2012 at 8:12 PM, Travis Oliphant tra...@continuum.io wrote: Check to see if this expression is true no is o In the first case no and o are the same object Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Sep 22, 2012, at 1:01 PM, Sebastian Berg sebast...@sipsolutions.net wrote: Hi, I have a bit of trouble figuring this out. I would have expected np.asarray(array) to go through ctors, PyArray_NewFromArray, but it seems to me it does not, so which execution path is exactly taken here? The reason I am asking is that I want to figure out this behavior/bug, and I really am not sure which function is responsible: In [69]: o = np.ones(3) In [70]: no = np.asarray(o, order='C') In [71]: no[:] = 10 In [72]: o # OK, o was changed in place: Out[72]: array([ 10., 10., 10.]) In [73]: no.flags # But no claims to own its data! Out[73]: C_CONTIGUOUS : True F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False In [74]: no = np.asarray(o, order='F') In [75]: no[:] = 11 In [76]: o # Here asarray actually returned a real copy! Out[76]: array([ 10., 10., 10.]) Thanks, Sebastian ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
