Mailman 3 February 2018 - NumPy-Discussion

Permissable NumPy logo usage
by Daniel Smith 16 Feb '18

16 Feb '18

Hello everyone, I have a project which combines NumPy and a quantum chemistry program (Psi4, psicode.org <http://psicode.org/>) for education and rapid prototyping. One of the authors has proposed a new logo which is a tweaked form of the the NumPy and Psi4 logos combined. I was curious if we were violating any NumPy copyright or community taboos in either using the NumPy name or a modified version of the NumPy logo. Any advice or direction would be most welcome. Current logo: https://github.com/psi4/psi4numpy/blob/master/media/psi4banner_numpy_intera… <https://github.com/psi4/psi4numpy/blob/master/media/psi4banner_numpy_intera…> Proposed logo: https://github.com/loriab/psi4numpy/blob/0866d0fb67f2c9629e2ba37bc4a091e206… <https://github.com/loriab/psi4numpy/blob/0866d0fb67f2c9629e2ba37bc4a091e206…> Project link: https://github.com/psi4/psi4numpy <https://github.com/psi4/psi4numpy> ChemRxiv: https://chemrxiv.org/articles/Psi4NumPy_An_Interactive_Quantum_Chemistry_Pr… <https://chemrxiv.org/articles/Psi4NumPy_An_Interactive_Quantum_Chemistry_Pr…> Cheers, -Daniel — Daniel G. A. Smith Software Scientist The Molecular Sciences Software Institute (MolSSI <http://molssi.org/>) @dgas_smith

3 2

NumPy should not silently promote numbers to strings
by Stephan Hoyer 14 Feb '18

14 Feb '18

This is one of my oldest NumPy pain-points: >>> np.array([1, 2, 'three']) array(['1', '2', 'three'], dtype='<U21') This is almost never what I want. In many cases, I simply write dtype=object, but for others (e.g., numpy.where), it's a minor annoyance to explicitly cast inputs to the right type. Autoconverting numbers into strings occasionally introduces real bugs (e.g., where using `np.nan` as a sentinel value for NA when working with strings, as in https://github.com/pydata/xarray/pull/1847), but mostly just hides bugs until later. It's certainly very un-Pythonic. The sane promotion rule would be `np.promote_types(str, float) -> object`, not a size 32 string. Is it way too late to fix this for NumPy, or is this something we could change in a major release? It would certainly need at least a deprecation cycle. This is easy enough to introduce accidentally that there are undoubtedly many users whose code would break if we changed this.

3 3

@xoviat
by Charles R Harris 12 Feb '18

12 Feb '18

Anyone know what happened to xoviat? He seems to have been disappeared. Chuck

2 1

type promotion rules for integers
by Kirill Balunov 09 Feb '18

09 Feb '18

What considerations formed the basis for choosing the next type promotion behavior in numpy: In[2] : a = np.array([10], dtype=np.int64) b = np.array([10], dtype=np.uint64) (a+b).dtype Out[2]: dtype('float64') Why the `object` dtype was not chosen for the resulting dtype? Are there any disadvantages in this case when choosing `object` instead of `float64`? With kind regards, -gdg

1 0

dtype argument description for np.array
by Kirill Balunov 09 Feb '18

09 Feb '18

Currently in docstring the description of dtype argument for np.array says this: dtype : data-type, optional > The desired data-type for the array. If not given, then the type will > be determined as the minimum type required to hold the objects in the > sequence. This argument can only be used to 'upcast' the array. For > downcasting, use the .astype(t) method. > But I found this description somewhat misleading for integer types. Is this generally true that "the type will be determined as the minimum type required to hold the objects in the sequence."? As I always thought for integer arrays first `np.int_` is assumed and if it is not enough the bigger dtype s are used, and finally falling to `object` dtype. This question comes from this discussion: https://github.com/numba/numba/issues/2729. Also somewhat (un)related (but I was always curious), why `float` type was chosen as a default for dtype? >>> np.array([]).dtype dtype('float64') >>> np.ones([]).dtype dtype('float64') Why np.int_ was not chosen and will this change be a good idea (in general, without taking into account backward compatibility :-))? There is some discussion here: https://github.com/numpy/numpy/issues/10405. ----------------- p.s.: For some constructors the signature looks as follows (in IPython console): >>> np.zeros? Docstring: zeros(shape, dtype=float, order='C') Return a new array of given shape and type, filled with zeros. >>> np.empty? Docstring: empty(shape, dtype=float, order='C') Return a new array of given shape and type, without initializing entries. But for `ones` the dtype is none instead of float and looks different: >>> np.ones? Signature: np.ones(shape, dtype=None, order='C') Docstring: Return a new array of given shape and type, filled with ones. ----------------- With kind regards, -gdg

1 0

SciPy 2018 - one week left for submissions
by Paul Ivanov 08 Feb '18

08 Feb '18

SciPy 2018, the 17th annual Scientific Computing with Python conference, will be held July 9-15, 2018 in Austin, Texas. The annual SciPyConference brings together over 700 participants from industry, academia, and government to showcase their latest projects, learn from skilled users and developers, and collaborate on code development. The call for abstracts for SciPy 2018 for talks, posters and tutorials is now open. The new extended deadline for submissions is February 15, 2018. Conference Website: https://scipy2018.scipy.org Submission Website: https://easychair.org/conferences/?conf=scipy2018 *July 9-15, 2018 | Austin, Texas * - *Tutorials:* July 9-10, 2018 - *Conference (Talks and Posters):* July 11-13, 2018 - *Sprints: *July 14-15, 2018 In addition to the general track, this year will have specialized tracks focused on: - Data Visualization - Reproducibility and Software Sustainability *Mini Symposia* · Astronomy · Biology and Bioinformatics · Data Science · Earth, Ocean and Geo Science · Image Processing · Language Interoperability · Library Science and Digital Humanities · Machine Learning · Materials Science · Political and Social Sciences There will also be a SciPy Tools Plenary Session each day with 2 to 5 minute updates on tools and libraries. *Tutorials (July 9-10, 2018)* Tutorials should be focused on covering a well-defined topic in a hands-on manner. We are looking for awesome techniques or packages, helping new or advanced Python programmers develop better or faster scientific applications. We encourage submissions to be designed to allow at least 50% of the time for hands-on exercises even if this means the subject matter needs to be limited. Tutorials will be 4 hours in duration. In your tutorial application, you can indicate what prerequisite skills and knowledge will be needed for your tutorial, and the approximate expected level of knowledge of your students (i.e., beginner, intermediate, advanced). Instructors of accepted tutorials will receive a stipend.

1 0

Hoop jumping, and other sports
by Charles R Harris 08 Feb '18

08 Feb '18

Hi All, I was thinking about things to do to simplify the NumPy development process. One thing that came to mind was our use of prefixes on commits, BUG, TST, etc. Those prefixes were originally introduced by David Cournapeau when he was managing releases in order help him track commits that might need backports. I like the prefixes, but now that we are organized by PRs, rather than commits, the only place we really need them, for some meaning of "need", is in the commit titles, and maintainers can change and edit those without problems. So I would like to propose that we no longer be picky about having them in the commit summary line. Furthermore, that got me thinking that there are probably other things we could do to simplify the development process. So I'd like folks to weigh in with other ideas for simplification or complaints about nit picky things that have annoyed them. Chuck

8 9

Extending C with Python
by Jialin Liu 06 Feb '18

06 Feb '18

Hello, I'm extending C with python (which is opposite way of what people usually do, extending python with C), I'm currently stuck in passing a C array to python layer, could anyone plz advise? I have a C buffer in my C code and want to pass it to a python function. In the C code, I have: npy_intp dims [2]; > dims[0] = 10; > dims[1] = 20; > import_array(); > npy_intp m=2; > PyObject * py_dims = PyArray_SimpleNewFromData(1, &m, NPY_INT16 ,(void > *)dims ); // I also tried NPY_INT > PyObject_CallMethod(pInstance, method_name, "O", py_dims); In the Python code, I want to just print that array: def f(self, dims): print ("np array:%d,%d"%(dims[0],dims[1])) But it only prints the first number correctly, i.e., dims[0]. The second number is always 0. Best, Jialin LBNL/NERSC

5 7

documentation, sound and music [was: doc? music through mathematical relations between LPCM samples and musical elements/characteristics]
by Renato Fabbri 31 Jan '18

31 Jan '18

Dear Scipy-ers, If you think I should split the message so that things get more clear... But the things are: 1) How to document numpy-heavy projects? 2) How to better make these contributions available to the numpy/scipy community? Directions will be greatly appreciated. I suspect that this info is all gathered somewhere I did not find. PS. I apologize for the cross-post, this is a message sent to numpy list but without any replies, so I found fit to send the message to both lists. Thanks in advance, Best, R. ---------- Forwarded message ---------- From: Renato Fabbri <renato.fabbri(a)gmail.com> Date: Tue, Jan 30, 2018 at 8:32 PM Subject: doc? music through mathematical relations between LPCM samples and musical elements/characteristics To: Discussion of Numerical Python <numpy-discussion(a)python.org> the half-shape suite: archive.org/details/ShapeSuite was completely synthesized using psychophysical relations for each resulting 16bit 44kHz samples: https://arxiv.org/abs/1412.6853 I am thinking about the ways in which to make the documentation at least to: * mass (music and audio in sample sequences): the framework. It might be considered a toolbox, but it is not a package: https://github.com/ttm/mass/ * music: a package for making music, including the routines used to make the half-shape suite: https://github.com/ttm/music == It seems reasonable at first to: * upload the package to PyPI (mass is not a package), music is there (beta but there). * Make available some summary of the file tree, including some automated code documentation. As I follow numpy's convention (or try to), and the package and framework are particularly useful for proficient numpy users, I used Sphinx. The very preliminary version is: https://pythonmusic.github.io/ * Make a nice readthedocs documentation. "music" project name was taken so I made: http://music-documentation.readthedocs.io/en/latest/ "mass" project name was also taken so I made: http://musicmass.readthedocs.io/en/latest/ And I found these URLs clumsy. Is there a standard or would you go with musicpackage.read.. and massframework.read... ? More importantly: * would you use readthedocs for the sphinx/doxigen output? * would you use readthedocs.org or a gitbook would be better or...? Should I contact the scipy community to make available a scikit or integrate it to numpy in any way beyond using and citing it appropriately?. BTW. I am using vimwiki with some constant attempt to organize and track my I/O: https://arxiv.org/abs/1712.06933 So maybe a unified solution for all these documentation instances using a wiki structure seems reasonable at the moment. Maybe upload the generated html from Sphinx and from Vimwiki to readthedocs...? Best, R. -- Renato Fabbri GNU/Linux User #479299 labmacambira.sourceforge.net -- Renato Fabbri GNU/Linux User #479299 labmacambira.sourceforge.net

2 2