Re: [Numpy-discussion] Dropping support for Accelerate/veclib?
On Tue, Jun 11, 2013 at 11:57 PM, Pauli Virtanen wrote: > 12.06.2013 00:29, Ralf Gommers kirjoitti: > [clip] > > AFAIK custom compiler flags can be injected via FOPT/FFLAGS/LDFLAGS, > > so doing something like > > > > export FOPT="-ff2c" > [clip] > > Sounds like a good idea. Would still make sense to move Accelerate down > > in the list of preferred libs, so that one can install ATLAS, MKL or > > OpenBLAS once and be done, instead of always having to remember these > > envvars. > > Btw, it would be interesting to actually check if some combination of > "-ff2c" in FOPT/FFLAGS/LDFLAGS/... fixes the Scipy Arpack issues. https://github.com/scipy/scipy/issues/2256#issuecomment-17028321 Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] genfromtxt and gzip
On 05.06.2013, at 9:52AM, Ted To wrote:
>> From the list archives (2011), I noticed that there is a bug in the
> python gzip module that causes genfromtxt to fail with python 2 but this
> bug is not a problem for python 3. When I tried to use genfromtxt and
> python 3 with a gzip'ed csv file, I instead got:
>
> IOError: Mode rbU not supported
>
> Is this a bug? I am using python 3.2.3 and numpy 1.7.1 from the
> experimental Debian repository.
Interesting, it used to be the other way round indeed - at least Python3's gzip
module was believed to work with 'U' mode (universal newline conversion).
This was apparently fixed in Python 2.7.3:
http://bugs.python.org/issue5148
but from the closing comment I'd take it should indeed _not_ be used in Python 3
"The data corruption issue is now fixed in the 2.7 branch.
In 3.x, using a mode containing 'U' results in an exception rather than silent
data corruption.
Additionally, gzip.open() has supported text modes ("rt"/"wt"/"at") and newline
translation since 3.3"
Checking the various Python versions on OS X 10.8 I found:
2.6.8: fails similar to the older 2.x, i.e. gzip opens with 'rbU', but then
fails upon reading
(possibly randomly) with
/sw/lib/python2.6/gzip.pyc in _read_eof(self)
302 if crc32 != self.crc:
303 raise IOError("CRC check failed %s != %s" % (hex(crc32),
--> 304 hex(self.crc)))
2.7.5: works as to be expected with the resolution of 5148 above.
3.1.5: works as well, which could just mean that the exception mentioned above
has not
made it into the 3.1.x branch…
3.2.5+3.3.2: gzip.open raises the exception as documented.
This looks like the original issue, that the universal newline conversion
should not be passed
to gzip.open (where it is meaningless or even harmful) is still not resolved;
ideally the 'U' flag
should probably be caught in _datasource.py.
I take it from the comments on issue 5148 that 3.3's gzip module offers
alternative methods to
do the newline conversion, but for 3.1, 3.2 and 2.6 this might still have to be
done within either
_datasource.py or genfromtxt; however I have no idea if anyone has come up with
a good
solution for this by now…
Cheers,
Derek
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] quickselect
On 11.06.2013 14:37, Jonathan J. Helmus wrote: > > > Julian, > > > Since I am the author of the current percentile PR > (https://github.com/numpy/numpy/pull/2970), I'm willing to try > reimplementing percentile with the new partition functionality. I > don't expect to have time to do this until the Scipy conference in > two week, so if anyone else wants to give the implementation a try > please feel free. Julian will you be at Scipy this year if I have > any questions? I wont be at the Scipy in June, but I can be reached via email or IRC (jtaylor on freenode and oftc) in the evening (UTC). btw. you don't need the minimum "trick" currently used in the branch for even element medians any more, so don't copy it for percentile. partition is specialized for small kth elements to be almost as fast as minimum, sometimes even faster if iterative partitioning is used (e.g. np.partition(d, (mid, mid + 1))) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Accelerate/veclib?
12.06.2013 00:29, Ralf Gommers kirjoitti: [clip] > AFAIK custom compiler flags can be injected via FOPT/FFLAGS/LDFLAGS, > so doing something like > > export FOPT="-ff2c" [clip] > Sounds like a good idea. Would still make sense to move Accelerate down > in the list of preferred libs, so that one can install ATLAS, MKL or > OpenBLAS once and be done, instead of always having to remember these > envvars. Btw, it would be interesting to actually check if some combination of "-ff2c" in FOPT/FFLAGS/LDFLAGS/... fixes the Scipy Arpack issues. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Accelerate/veclib?
On 11 Jun 2013 22:31, "Ralf Gommers" wrote: > Sounds like a good idea. Would still make sense to move Accelerate down in the list of preferred libs, so that one can install ATLAS, MKL or OpenBLAS once and be done, instead of always having to remember these envvars. These days it might make sense to just make OpenBLAS the default on all platforms. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Accelerate/veclib?
On Tue, Jun 11, 2013 at 11:17 AM, Pauli Virtanen wrote: > David Cournapeau gmail.com> writes: > [clip] > > What is the default ABI used on homebrew ? I think we should just > > follow that, given that Apple cannot figure it out. > > I think for Scipy homebrew uses the Gfortran ABI: > https://trac.macports.org/browser/trunk/dports/python/py-scipy/Portfile > > But that's probably the wrong thing to do, it doesn't work: > http://trac.macports.org/ticket/36694 > > For Octave, they have -ff2c: > https://trac.macports.org/browser/trunk/dports/math/octave/Portfile > > *** > > A third option (maybe the best one) could be to add an ABI check > to numpy.distutils BLAS/LAPACK detection --- compile a small test > program that checks SDOT/CDOTU/DDOT etc., and refuse to use the > BLAS/LAPACK libraries if they give incorrect results. After that, > we can also remove the sdot/cdotu wrappers. > > This approach is used by Octave. > > This leaves the problem of dealing with Fortran ABI to those in > charge of the build environment, e.g., macports, Enthought, ..., > who are also in the best position to pick the correct solution > per each platform supported. > > AFAIK custom compiler flags can be injected via FOPT/FFLAGS/LDFLAGS, > so doing something like > > export FOPT="-ff2c" > > or > > export LDFLAGS="-ldotwrp -lblas" > > works? This makes things a bit more complicated to the builder, an > issue that can be solved with documentation, and keeping that up to > date is easier than hardcoding stuff into numpy.distutils. > Sounds like a good idea. Would still make sense to move Accelerate down in the list of preferred libs, so that one can install ATLAS, MKL or OpenBLAS once and be done, instead of always having to remember these envvars. https://github.com/scipy/scipy/issues/2256#issuecomment-17028321 has a sample test. Minor issue is that it segfaults with the wrong ABI, instead of giving an incorrect result. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for, Accelerate/veclib?
On Tue, Jun 11, 2013 at 1:28 PM, Ralf Gommers wrote: > The binaries will still be built against python.org Python, so there > shouldn't be an issue here. Same for building from source. My point was that it's nice to be able to have it build with an out of teh box wetup.py with accelerated LAPACK and all... If whoever is building binaries wants to get fancy, great. > Yeah, I still have an OS X 10.6 machine and Accelerate works great there. > But they screwed it up pretty bad in 10.7, and then made it worse for 10.8. > Not so cool anymore oh well, not on 10.8 yet myself -- if it's broken, it's broken :-( > I think we have to indeed keep it easy to build from source. Maybe providing > a script to automatically fetch all dependencies and then build (like MPL > does) would be a good way to go. Maybe, but stand alone scripts like that get pretty fragile ( I know, I have a few of them myself...) I really want to have a better system in place to build binaries for the mac -- ideally a system that uses the same infrastructure to build a variety of Mac packages, rather than each package having it's own build scripts that need to be maintained and probably overlap with each other. I"m looking at gattai as a system to build on. (http://sourceforge.net/projects/gattai/) There is also the issue of third-party dependencies (libpng, libfreetype, blas, etc, etc) I kind of like how Anaconda appears to be doing it. They have packages that have the shared libs in them, and then other packages can depend on those. Anyway, lots to do! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(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] Dropping support for Accelerate/veclib?
On Tue, Jun 11, 2013 at 2:09 PM, Matthew Brett wrote: > Hi, > > On Tue, Jun 11, 2013 at 5:17 AM, Pauli Virtanen wrote: > > David Cournapeau gmail.com> writes: > > [clip] > >> What is the default ABI used on homebrew ? I think we should just > >> follow that, given that Apple cannot figure it out. > > > > I think for Scipy homebrew uses the Gfortran ABI: > > https://trac.macports.org/browser/trunk/dports/python/py-scipy/Portfile > > > > But that's probably the wrong thing to do, it doesn't work: > > http://trac.macports.org/ticket/36694 > > > > For Octave, they have -ff2c: > > https://trac.macports.org/browser/trunk/dports/math/octave/Portfile > > > > *** > > > > A third option (maybe the best one) could be to add an ABI check > > to numpy.distutils BLAS/LAPACK detection --- compile a small test > > program that checks SDOT/CDOTU/DDOT etc., and refuse to use the > > BLAS/LAPACK libraries if they give incorrect results. After that, > > we can also remove the sdot/cdotu wrappers. > > > > This approach is used by Octave. > > > > This leaves the problem of dealing with Fortran ABI to those in > > charge of the build environment, e.g., macports, Enthought, ..., > > who are also in the best position to pick the correct solution > > per each platform supported. > > > > AFAIK custom compiler flags can be injected via FOPT/FFLAGS/LDFLAGS, > > so doing something like > > > > export FOPT="-ff2c" > > > > or > > > > export LDFLAGS="-ldotwrp -lblas" > > > > works? This makes things a bit more complicated to the builder, an > > issue that can be solved with documentation, and keeping that up to > > date is easier than hardcoding stuff into numpy.distutils. > > What will be the performance drop for the default OSX installer > version of numpy, if we drop Accelerate / veclib support? > Answer on scipy-dev: http://article.gmane.org/gmane.comp.python.scientific.devel/17864 Summary: it depends. If anyone knows of better benchmarks, please share. Joern Hees just wrote up how to install with OpenBLAS, if you want to know for your application you can give it a try: http://joernhees.de/blog/2013/06/08/mac-os-x-10-8-scientific-python-with-homebrew/ Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for, Accelerate/veclib?
On Tue, Jun 11, 2013 at 9:44 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > On Tue, Jun 11, 2013 at 10:22 AM, Nils Becker wrote: > > fwiw, homebrew is not macports. it's a more recent replacement that > > seems to be taking over gradually. > > And then there is (or was) fink > > Anyway, it would be really nice if numpy could work well out-of-the > box with the pyton.org python (and or the Apple-supplied one) without > any need fro macports, homebrew, etc. The binaries will still be built against python.org Python, so there shouldn't be an issue here. Same for building from source. > It's actually pretty cool that > Apple provides veclib, and and I liked that it got used by default > with a simple "setup.py build". > Yeah, I still have an OS X 10.6 machine and Accelerate works great there. But they screwed it up pretty bad in 10.7, and then made it worse for 10.8. Not so cool anymore It would be nice to keep it that way. > > If a user (or distributor of binaries) wants to build the whole scipy > stack, they'll need to figure out all this *&^%& anyway, changing a > config in numpy to build differently would be the easiest part. > > And yes, there really are folks that use numpy a lot without scipy. > I think we have to indeed keep it easy to build from source. Maybe providing a script to automatically fetch all dependencies and then build (like MPL does) would be a good way to go. Ralf > -Chris > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(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] Dropping support for, Accelerate/veclib?
On Tue, Jun 11, 2013 at 10:22 AM, Nils Becker wrote: > fwiw, homebrew is not macports. it's a more recent replacement that > seems to be taking over gradually. And then there is (or was) fink Anyway, it would be really nice if numpy could work well out-of-the box with the pyton.org python (and or the Apple-supplied one) without any need fro macports, homebrew, etc. It's actually pretty cool that Apple provides veclib, and and I liked that it got used by default with a simple "setup.py build". It would be nice to keep it that way. If a user (or distributor of binaries) wants to build the whole scipy stack, they'll need to figure out all this *&^%& anyway, changing a config in numpy to build differently would be the easiest part. And yes, there really are folks that use numpy a lot without scipy. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(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] Dropping support for, Accelerate/veclib?
> I think for Scipy homebrew uses the Gfortran ABI: > https://trac.macports.org/browser/trunk/dports/python/py-scipy/Portfile fwiw, homebrew is not macports. it's a more recent replacement that seems to be taking over gradually. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Will transpose ever need to copy data?
I noticed today that the documentation for np.transpose states, for the return value, that "A view is returned whenever possible." Is there really any situation where swapping axes around could trigger the need to copy data, or will a view always be returned no matter what? I can't think of any such situation, and was planning on relying on that for some code: basically, I have an output array, which I would like to be contiguous. So I preallocate it with the right shape, then take a view of it moving a certain axis to the end to make computations easier, run all my computations on the modified view, then return the original array, not the view. If I started with an array with the axis at the end, and then transposed it, I would need to make a copy to make it contiguous, which is what I am trying to avoid. Is this a bad practice? Is that precaution in the documentation real? Should I check that my view's base is the original array and trigger a copy, or is it an unnecessary check? Thanks in advance, Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] quickselect
On Jun 9, 2013, at 11:27 AM, Julian Taylor wrote: > On 09.06.2013 12:10, josef.p...@gmail.com wrote: >> On Wed, May 29, 2013 at 3:19 PM, wrote: >>> On Wed, May 29, 2013 at 12:25 PM, Julian Taylor >>> wrote: On 05/29/2013 06:12 AM, josef.p...@gmail.com wrote: > > On Tue, May 28, 2013 at 6:31 PM, Charles R Harris > wrote: >> >> Hi All, >> >> There is a PR adding quickselect to numpy as a function `partition`. >> Comments on name and exposure in the numpy API are welcome. > > > > > here a a quick status report on the PR > https://github.com/numpy/numpy/pull/3360 > > I now implemented partitioning via the introselect algorithm which is a > quickselect median of 3 pivot with a cutoff on recursion depth to a > median of median of 5 pivot for O(N) worst case complexity. > Additionally it can stores its pivots for reuse in other partitions on > the same data to reduce the space required to be partitioned next time, > this is useful e.g. for multiple percentiles. > > It is functionally ready, but there are still some API/ABI issues to be > solved. > Mainly deciding if we put the selection algorithms in the ABI for 1.8 or > not. Currently the ABI is unchanged so user types cannot make use of the > algorithms (they will fall back to quicksort). > > The python api is now: > np.partition(array, kth) > where kth is an integer or array of integers > > it will move each index in kth into its final sorted position, so > np.partition(a, range(a.size)) results in a (inefficient) sort. > e.g.: > > d = np.array([66, 81, 21, 75, 46, -6, 66, 86, 242, 47, 88, 79]) > np.partition(d, (2, -2)) # (2, 8) > array([ -6, 21, 46, 47, 75, 66, 66, 79, 81, 86, 88, 242]) > > Multidimensional arrays will use the same array of kth, you cannot > partition each axis by different values, you would have to explicitly > loop to do that. > > Median is implemented in terms of partitioning already, but percentile > is not. > I would suggest someone else than me gives a try at implementing > percentile in terms of partition to see if the documentation and api > make sense to others. > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion Julian, Since I am the author of the current percentile PR (https://github.com/numpy/numpy/pull/2970), I'm willing to try reimplementing percentile with the new partition functionality. I don't expect to have time to do this until the Scipy conference in two week, so if anyone else wants to give the implementation a try please feel free. Julian will you be at Scipy this year if I have any questions? Cheers, - Jonathan Helmus ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Accelerate/veclib?
Hi, On Tue, Jun 11, 2013 at 5:17 AM, Pauli Virtanen wrote: > David Cournapeau gmail.com> writes: > [clip] >> What is the default ABI used on homebrew ? I think we should just >> follow that, given that Apple cannot figure it out. > > I think for Scipy homebrew uses the Gfortran ABI: > https://trac.macports.org/browser/trunk/dports/python/py-scipy/Portfile > > But that's probably the wrong thing to do, it doesn't work: > http://trac.macports.org/ticket/36694 > > For Octave, they have -ff2c: > https://trac.macports.org/browser/trunk/dports/math/octave/Portfile > > *** > > A third option (maybe the best one) could be to add an ABI check > to numpy.distutils BLAS/LAPACK detection --- compile a small test > program that checks SDOT/CDOTU/DDOT etc., and refuse to use the > BLAS/LAPACK libraries if they give incorrect results. After that, > we can also remove the sdot/cdotu wrappers. > > This approach is used by Octave. > > This leaves the problem of dealing with Fortran ABI to those in > charge of the build environment, e.g., macports, Enthought, ..., > who are also in the best position to pick the correct solution > per each platform supported. > > AFAIK custom compiler flags can be injected via FOPT/FFLAGS/LDFLAGS, > so doing something like > > export FOPT="-ff2c" > > or > > export LDFLAGS="-ldotwrp -lblas" > > works? This makes things a bit more complicated to the builder, an > issue that can be solved with documentation, and keeping that up to > date is easier than hardcoding stuff into numpy.distutils. What will be the performance drop for the default OSX installer version of numpy, if we drop Accelerate / veclib support? Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Accelerate/veclib?
David Cournapeau gmail.com> writes: [clip] > What is the default ABI used on homebrew ? I think we should just > follow that, given that Apple cannot figure it out. I think for Scipy homebrew uses the Gfortran ABI: https://trac.macports.org/browser/trunk/dports/python/py-scipy/Portfile But that's probably the wrong thing to do, it doesn't work: http://trac.macports.org/ticket/36694 For Octave, they have -ff2c: https://trac.macports.org/browser/trunk/dports/math/octave/Portfile *** A third option (maybe the best one) could be to add an ABI check to numpy.distutils BLAS/LAPACK detection --- compile a small test program that checks SDOT/CDOTU/DDOT etc., and refuse to use the BLAS/LAPACK libraries if they give incorrect results. After that, we can also remove the sdot/cdotu wrappers. This approach is used by Octave. This leaves the problem of dealing with Fortran ABI to those in charge of the build environment, e.g., macports, Enthought, ..., who are also in the best position to pick the correct solution per each platform supported. AFAIK custom compiler flags can be injected via FOPT/FFLAGS/LDFLAGS, so doing something like export FOPT="-ff2c" or export LDFLAGS="-ldotwrp -lblas" works? This makes things a bit more complicated to the builder, an issue that can be solved with documentation, and keeping that up to date is easier than hardcoding stuff into numpy.distutils. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Accelerate/veclib?
On Tue, Jun 11, 2013 at 9:22 AM, Pauli Virtanen wrote: > Hi, > > numpy.distutils provides support for Accelerate+veclib on OSX, > but does not provide Fortran compiler flags that ensure that > the Fortran ABI used is compatible. As a result ASUM, SDOT, > (apparently also DDOT), and other common BLAS functions > return garbage when called with the wrong ABI. > > This breaks parts of Scipy. (There's some code to hack around > this --- it worked on earlier versions of OSX, but apparently > is unreliable on 10.8, demonstrating that this approach is just > too brittle.) > > Moreover, third-party module developers who use Fortran will not > be aware of this issue, so it may also break 3rd party code. > > As far as I see, the options are: > > 1. Add -ff2c (or whatever is the correct flag for Accelerate) >to the Fortran flags on OSX. What is the default ABI used on homebrew ? I think we should just follow that, given that Apple cannot figure it out. > > 2. Drop support for Veclib/Accelerate. > > I think Accelerate was also incompatible with multiprocessing, > which would weigh for option 2. As for multiprocessing support, the problem will happen with other libraries as well. Essentially, the way multiprocessing work (fork wo exec) is simply not supported on OS X. Olivier Grisel from scikits learn knows more about this (and has some workaround to use multiprocessing with numpy/scipy on os x). I will look into the issue with Accelerate on 10.8 (am still on 10.7 myself), but I would not mind dropping support for it if it is too much of an hassle. I will look into the bento issue that makes it fail on 64 bits python, and maybe using openblas should become the default ? David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Dropping support for Accelerate/veclib?
Hi, numpy.distutils provides support for Accelerate+veclib on OSX, but does not provide Fortran compiler flags that ensure that the Fortran ABI used is compatible. As a result ASUM, SDOT, (apparently also DDOT), and other common BLAS functions return garbage when called with the wrong ABI. This breaks parts of Scipy. (There's some code to hack around this --- it worked on earlier versions of OSX, but apparently is unreliable on 10.8, demonstrating that this approach is just too brittle.) Moreover, third-party module developers who use Fortran will not be aware of this issue, so it may also break 3rd party code. As far as I see, the options are: 1. Add -ff2c (or whatever is the correct flag for Accelerate) to the Fortran flags on OSX. 2. Drop support for Veclib/Accelerate. I think Accelerate was also incompatible with multiprocessing, which would weigh for option 2. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Re: empty_like for masked arrays
On June 11, 2013 at 00:40:31, Pierre GM (pgmdevl...@gmail.com) wrote: On June 10, 2013 at 23:07:24 , Eric Firing (efir...@hawaii.edu) wrote: On 2013/06/10 10:17 AM, Aldcroft, Thomas wrote: > I use np.ma , and for me the most intuitive would be the > second option where the new array matches the original array in shape > and dtype, but always has an empty mask. I always think of the *_like() > functions as just copying shape and dtype, so it would be a bit > surprising to get part of the data (the mask) from the original. If you > do need the mask then on the next line you have an explicit statement to > copy the mask and the code and intent will be clear. Also, most of the > time the mask is set because that particular data value was bad or > missing, so it seems like it would be a less-common use case to want a > new empty array with the same mask. > I also use np.ma (and it is used internally in matplotlib). I agree with Tom. I think all of the *_like() functions should start with mask=False, meaning nothing is masked by default. I don't see what the reasonable use cases would be for any alternative. Thinking about it, a replacement to `_convert2ma` should work something like`func(input.view(np.ndarray)).view(np.ma.MaskedArray)`The `input.view(np.ndarray)` will get the `.data` part of a MaskedArray and work seamlessly with a regular ndarray, the `.view(MaskedArray)` will attach a `np.ma.nomask` to the result of the previous view (therefore making the output a MaskedArray). Depending on your decision, we could add a flag to copy the initial mask (if any)___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
