Mailman 3 December 2015 - NumPy-Discussion

AppVeyor
by Charles R Harris Dec. 22, 2015

Dec. 22, 2015

Hi All, Just checking if someone has already registered numpy on appveyor. If not, I intend to rename my personal account. Note that as AFAICT, someone has to be the admin for appveyor, and that someone, like everyone else, can only have one account on appveyor. Other folks with accounts can be added as collaborators, but they cannot belong to the numpy account. Or something. Reading the appveyor documentation, such as it is, is like driving through a heavy fog and the user interface is … [View More]

4 24

[ANN-JOB] Project Jupyter is hiring a Project Manager - position at UC Berkeley
by Fernando Perez Dec. 22, 2015

Dec. 22, 2015

Hi all, [ please direct all replies directly to me ] Project Jupyter is announcing the opening of a position for a full-time project manager, who will help us coordinate our technical development, engage the open source community and work with our multiple stakeholders in academia and industry. If you have experience leading technical teams in open source communities, we'd love to hear from you! In the last few years the project has rapidly grown in multiple directions, and this presents … [View More]

1 0

Re: [Numpy-discussion] PR for complex np.interp, question about assert_almost_equal
by Peter Creasey Dec. 22, 2015

Dec. 22, 2015

>> > assert_almost_equal >> > TypeError: Cannot cast array data from dtype('complex128') to >> dtype('float64') according to the rule 'safe' >> >> > > Hi Peter, that error is unrelated to assert_almost_equal. What happens is > that when you pass in a complex argument `fp` to your modified > `compiled_interp`, you're somewhere doing a cast that's not safe and > trigger the error at > https://github.com/numpy/numpy/blob/master/numpy/core/src/… [View More]

1 0

PR for complex np.interp, question about assert_almost_equal
by Peter Creasey Dec. 22, 2015

Dec. 22, 2015

Hi all, I submitted a PR (#6872) for using complex numbers in np.lib.interp. The tests pass on my machine, but I see that the TravisCI builds are giving assertion fails (on my own test) with python 3.3 and 3.5 of the form: > assert_almost_equal > TypeError: Cannot cast array data from dtype('complex128') to dtype('float64') according to the rule 'safe' When I was writing the test I used np.testing.assert_almost_equal with complex128 as it works in my python 2.7, however having checked … [View More]

3 2

Why is masked string array fill value 'N/A'
by Charles R Harris Dec. 21, 2015

Dec. 21, 2015

Why, why, why is it not the empty string. you can't actually fill an `S2` type with such a string, hence one must convert masked string arrays to a list of strings to use it. That is pathetic. Chuck

1 0

numpy.power -> numpy.random.choice Probabilities don't sum to 1
by Ryan R. Rosario Dec. 19, 2015

Dec. 19, 2015

Hi, I have a matrix whose entries I must raise to a certain power and then normalize by row. After I do that, when I pass some rows to numpy.random.choice, I get a ValueError: probabilities do not sum to 1. I understand that floating point is not perfect, and my matrix is so large that I cannot use np.longdouble because I will run out of RAM. As an example on a smaller matrix: np.power(mymatrix, 10, out=mymatrix) row_normalized = np.apply_along_axis(lambda x: x / np.sum(x), 1, mymatrix) … [View More]

4 3

7th Annual Scientific Software Days Conference (25-26 February, 2016 -- Austin, TX)
by Damon McDougall Dec. 18, 2015

Dec. 18, 2015

The 7th Annual Scientific Software Days Conference (SSD) <http://scisoftdays.org/> targets users and developers of scientific software. The conference will be held at the University of Texas at Austin Thursday Feb 25 - Friday Feb 26, 2016 and focuses on two themes: a) sharing best practices across scientific software communities; b) sharing the latest tools and technology relevant to scientific software. Past keynotes speakers include Greg Wilson (2008), Victoria Stodden (2009), … [View More]

1 0

Introducing outer/orthonongal indexing to numpy
by Sebastian Berg Dec. 18, 2015

Dec. 18, 2015

Hello all, sorry for cross posting (discussion should go to the numpy list). But I would like to get a bit of discussion on the introduction of (mostly) two new ways to index numpy arrays. This would also define a way for code working with different array-likes, some of which implement outer indexing (i.e. xray and dask I believe), to avoid ambiguity. The new methods are (names up for discussion): 1. arr.oindex[...] 2. arr.vindex[...] The difference beeing that `oindex` will return outer/… [View More]orthogonal type indexing, while `vindex` would be a (hopefully) less confusing variant of "fancy" indexing. The biggest reason for introducing this is to provide `oindex` for situations such as: >>> arr = np.arange(25).reshape((5, 5)) >>> arr[[0, 1], [1, 2]] array([1, 7]) >>> # While most might expect the result to be: >>> arr.oindex[[0, 1], [1, 2]] array([[1, 2], [6, 7]]) To provide backwards compatibility the current plan is to also introduce `arr.legacy_index[...]` or similar, with the (long term) plan to force the users to explicitly choose `oindex`, `vindex`, or `legacy_index` if the indexing operation is otherwise not well defined. There are still some open questions for me regarding, for example: * the exact time line (should we start deprecation immediately, etc.) * the handling of boolean indexing arrays * questions that might crop up about other array-likes/subclasses * Are there indexing needs that we are forgetting but are related? More details the current status of my NEP, which has a lot of examples, can be found at: https://github.com/numpy/numpy/pull/6256/files?short_path=01e4dd9#diff-01e4… and comments about are very welcome. There is a fully functional implementation available at https://github.com/numpy/numpy/pull/6075 and you can test it using (after cloning numpy): git fetch upstream pull/6075/head:pr-6075 && git checkout pr-6075; python runtests.py --ipython # Inside ipython (too see the deprecations): import warnings; warnings.simplefilter("always") My current hope for going forward is to get clear feedback of what is wanted, for the naming and generally from third party module people, so that we can polish up the NEP and the community can accept it. With good feedback, I think we may be able to get the new attributes into 1.11. So if you are interested in teaching and have suggestions for the names, or have thoughts about subclasses, or... please share your thoughts! :) Regards, Sebastian [View Less]

1 0

array_equal too strict?
by Nico Schlömer Dec. 17, 2015

Dec. 17, 2015

Hi everyone, I noticed a funny behavior in numpy's array_equal. The two arrays ``` a1 = numpy.array( [3.14159265358979320], dtype=numpy.float64 ) a2 = numpy.array( [3.14159265358979329], dtype=numpy.float64 ) ``` (differing the in the 18th overall digit) are reported equal by array_equal: ``` print(numpy.array_equal(a1, a2)) # output: true ``` That's expected because the difference is only in the 18th overall digit, and the mantissa length of float64 is 52 bits [1], i.e.… [View More]

4 3

A minor clarification no why count_nonzero is faster for boolean arrays
by Raghav R V Dec. 17, 2015

Dec. 17, 2015

I was just playing with `count_nonzero` and found it to be significantly faster for boolean arrays compared to integer arrays >>> a = np.random.randint(0, 2, (100, 5)) >>> a_bool = a.astype(bool) >>> %timeit np.sum(a) 100000 loops, best of 3: 5.64 µs per loop >>> %timeit np.count_nonzero(a) 1000000 loops, best of 3: 1.42 us per loop >>> %timeit np.count_nonzero(a_bool) 1000000 loops, best of 3: 279 ns per loop (… [View More]

4 4