Mailman 3 June 2015 - NumPy-Discussion

[JOBs] Data analysis position at the European synchrotron
by Jerome Kieffer June 13, 2015

June 13, 2015

Dear Pythonistas, The European Synchrotron, ESRF, located in the French Alps, just got approved a large upgrade in which data-analysis is a key element. I am pleased to announce this strategy is built around Python and all code developed in this frame will be based around Python and made open-source. Feel free to distribute this around. 1 metadata manager position: http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=413 2 data scientist positions: http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=421 http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=414 3 software engineer positions http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=418 http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=417 http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=419 Other related data analysis positions http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=420 http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=411 Best regards, Jerome Kieffer

2 1

changing ValueError to KeyError for bad field access
by Allan Haldane June 12, 2015

June 12, 2015

Hi all, I think it would be very nice to make access to invalid fields of a structured array give a KeyError instead of a ValueError. Like: >>> a = np.ones(3, dtype=[('a', 'f4'), ('b', 'f4')]) >>> a['c'] KeyError: 'c' A commit in my PR https://github.com/numpy/numpy/pull/5636 does this. As discussed there, backwards compatibility is a problem but it seems like the impact might be fairly small. Any opinions? Allan

3 2

ANN: xray v0.5
by Stephan Hoyer June 11, 2015

June 11, 2015

I'm pleased to announce version 0.5 of xray, N-D labeled arrays and datasets in Python. xray is an open source project and Python package that aims to bring the labeled data power of pandas to the physical sciences, by providing N-dimensional variants of the core pandas data structures. These data structures are based on the data model of the netCDF file format. Highlights of this release: * Support for parallel computation on arrays that don't fit in memory using dask.array (see http://continuum.io/blog/xray-dask for more details) * Support for multi-file datasets * assign and fillna methods, based on the pandas methods of the same name. * to_array and to_dataset methods for easier conversion between xray Dataset and DataArray objects. * Label based indexing with nearest neighbor lookups For more details, read the full release notes: http://xray.readthedocs.org/en/stable/whats-new.html Best, Stephan

1 0

Open CV 3.0 + NPY_RELAXED_STRIDES
by Jaime Fernández del Río June 11, 2015

June 11, 2015

I'm in the midst of a Python 3.5 + MSVS 2015 compilation frenzy. Today it was time for Open CV 3.0, where I found a nasty bug that I have eventually tracked down to using a development version of NumPy, and Open CV 3.0 choking on relaxed strides, as it does a check that every stride is a multiple of the itemsize. I was thinking of submitting a patch to opencv to fix this, but was wondering whether we have plans to eventually have relaxed strides out in the wild in user releases, or is it just a testing tool for development? Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

5 6

NumPy + Python 3.5 + Windows + VS2015
by Jaime Fernández del Río June 10, 2015

June 10, 2015

I have just unsuccessfully tried to build numpy under Windows for Python 3.5, using the latest release candidate for Visual Studio 2015. A very early failure with a: RuntimeError: Broken toolchain: cannot link a simple C program even though repeating the sequence of commands that lead to the failure manually seems to work. Anyway, before diving deeper into this, has anyone tried this out already and have some success or failure stories to share? Thanks, Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

3 3

ANN: Py-ART v1.4.0 released
by Jonathan Helmus June 9, 2015

June 9, 2015

I am happy to announce the release of Py-ART version 1.4.0. Py-ART is an open source Python module for reading, visualizing, correcting and analysis of weather radar data. Documentation : http://arm-doe.github.io/pyart/dev/index.html GitHub : https://github.com/ARM-DOE/pyart Pre-build conda binaries: https://binstar.org/jjhelmus/pyart/files?version=1.4.0 Version 1.4.0 is the result of 4 months of work by 7 contributors. Thanks to all contributors, especially those who have made their first contribution to Py-ART. Highlights of this release: * Support for reading and writing MDV Grid files. (thanks to Anderson Gama) * Support for reading GCPEX D3R files. (thanks to Steve Nesbitt) * Support for reading NEXRAD Level 3 files. * Optional loading of radar field data upon use rather than initial read. * Significantly faster gridding method, "map_gates_to_grid". * Improvements to the speed and bug fixes to the region based dealiasing algorithm. * Textures of differential phase fields. (thanks to Scott Collis) * Py-ART now can be used with Python 3.3 and 3.4 Cheers, - Jonathan Helmus

1 0

Backwards-incompatible improvements to numpy.random.RandomState
by Antony Lee June 9, 2015

June 9, 2015

Hi, As mentioned in #1450: Patch with Ziggurat method for Normal distribution #5158: ENH: More efficient algorithm for unweighted random choice without replacement #5299: using `random.choice` to sample integers in a large range #5851: Bug in np.random.dirichlet for small alpha parameters some methods on np.random.RandomState are implemented either non-optimally (#1450, #5158, #5299) or have outright bugs (#5851), but cannot be easily changed due to backwards compatibility concerns. While some have suggested new methods deprecating the old ones (see e.g. #5872), some consensus has formed around the following ideas (see #5299 for original discussion, followed by private discussions with @njsmith): - Backwards compatibility should only be provided to those who were explicitly instantiating a seeded RandomState object or reseeding a RandomState object to a given value, and drawing variates from it: using the global methods (or a None-seeded RandomState) was already non-reproducible anyways as e.g. other libraries could be drawing variates from the global RandomState (of which the free functions in np.random are actually methods). Thus, the global RandomState object should use the latest implementation of the methods. - "RandomState(seed)" and "r = RandomState(...); r.seed(seed)" should offer backwards-compatibility guarantees (see e.g. https://docs.python.org/3.4/library/random.html#notes-on-reproducibility). As such, we propose the following improvements to the API: - RandomState gains a (keyword-only) parameter, "version", also accessible as a read-only attribute. This indicates the version of the methods on the object. The current version of RandomState is retroactively assigned version 0. The latest available version is available as np.random.LATEST_VERSION. Backwards-incompatible improvements to RandomState methods can be introduced but increase the LAGTEST_VERSION. - The global RandomState is instantiated as RandomState(version=LATEST_VERSION). - RandomState() and rs.seed() sets the version to LATEST_VERSION. - RandomState(seed[!=None]) and rs.seed(seed[!=None]) sets the version to 0. A proof-of-concept implementation, still missing tests, is tracked as #5911. It includes the patch proposed in #5158 as an example of how to include an improved version of random.choice. Comments, and help for writing tests (in particular to make sure backwards compatibility is maintained) are welcome. Antony Lee

9 24

DEP: Deprecate boolean array indices with non-matching shape #4353
by Charles R Harris June 5, 2015

June 5, 2015

Hi All, I've not strong feelings one way or the other on this proposed deprecation for numpy 1.10 and would like some feedback from interested users. Chuck

6 11

variable end border in arrays
by Pablo June 5, 2015

June 5, 2015

Hi, If I want to remove 1 element in the beginning and the end of a numpy array "x" we do: x[1:-1] Now, if we have a border variable, and borders are allowed to be zero (which means no border), numpy syntax is inconvenient. For example if border=numpy.asarray([1,0]) and we try x[border[0],-border[1]] it will produce an empty array because border[1]==0 is not considered respect to the end of the array anymore. Is it possible to solve this without if/else's ? (I work with images and tensor's so if/else's have too many possible combinations) Thanks, Pablo

2 1

matmul needs some clarification.
by Charles R Harris June 5, 2015

June 5, 2015

Hi All, The problem arises when multiplying a stack of matrices times a vector. PEP465 defines this as appending a '1' to the dimensions of the vector and doing the defined stacked matrix multiply, then removing the last dimension from the result. Note that in the middle step we have a stack of matrices and after removing the last dimension we will still have a stack of matrices. What we want is a stack of vectors, but we can't have those with our conventions. This makes the result somewhat unexpected. How should we resolve this? Chuck

3 6