Mailman 3 December 2015 - NumPy-Discussion

f2py, numpy.distutils and multiple Fortran source files
by David Verelst 05 Dec '15

05 Dec '15

Hi, For the wafo [1] package we are trying to include the extension compilation process in setup.py [2] by using setuptools and numpy.distutils [3]. Some of the extensions have one Fortran interface source file, but it depends on several other Fortran sources (modules). The manual compilation process would go as follows: gfortran -fPIC -c source_01.f gfortran -fPIC -c source_02.f f2py -m module_name -c source_01.o source_02.o source_interface.f Can this workflow be incorporated into setuptools/numpy.distutils? Something along the lines as: from numpy.distutils.core import setup, Extension ext = Extension('module.name', depends=['source_01.f', 'source_02.f'], sources=['source_interface.f']) (note that the above does not work) [1] https://github.com/wafo-project/pywafo [2] https://github.com/wafo-project/pywafo/blob/pipinstall/setup.py [3] http://docs.scipy.org/doc/numpy/reference/distutils.html Regards, David

3 3

NumPy Pyston support
by Boxiang Sun 05 Dec '15

05 Dec '15

Hi all, I am an open source contributor of Pyston, and working on NumPy Pyston support(Pyston: https://github.com/dropbox/pyston) I disabled some tests which cause segfaults. This is current situation(in my local branch): ---------------------------------- Ran 3240 tests in 80.811s FAILED (KNOWNFAIL=3, SKIP=6, errors=334, failures=74) ---------------------------------- Indeed, the time consuming was longer than CPython. I think this is because of the additional exceptions / frame introspection etc... And no one took yet a look at the perf. Pyston runtime miss some features. I will try to fix the problems which discovered in running NumPy test suite. This is basically an announcement. I will update the situation when I get breakthrough, ask for help if I encounter problems, submit commit to NumPy if needed. Looking for feedback. Regards, Sun

1 0

future of f2py and Fortran90+
by Eric Firing 04 Dec '15

04 Dec '15

F2py is a great tool, but my impression is that it is being left behind by the evolution of Fortran from F90 onward. This is unfortunate; it would be nice to be able to easily wrap new Fortran libraries. I'm curious: has anyone been looking into what it would take to enable f2py to handle modern Fortran in general? And into prospects for getting such an effort funded? Eric

5 6

Recognizing a cycle in a vector
by Manolo Martínez 03 Dec '15

03 Dec '15

Dear all, Suppose that I have a vector with the numerical solution of a differential equation -- more concretely, I am working with evolutionary game theory models, and the solutions are frequencies of types in a population that follows the replicator dynamics; but this is probably irrelevant. Sometimes these solutions are cyclical, yet I sample at points which do not correspond with the period of the cycle, so that np.allclose() cannot be directly applied. Is there any way to check for cycles in this situation? Thanks for any advice, Manolo

5 11

ANN: SciExp^2 (1.1.2)
by Lluís Vilanova 02 Dec '15

02 Dec '15

Hi all! I'm really happy to make the first public announcement of SciExp^2 (actually, it's release 1.1.2). Home page: https://projects.gso.ac.upc.edu/projects/sciexp2 Description ----------- SciExp² (aka SciExp square or simply SciExp2) stands for Scientific Experiment Exploration, which contains a comprehensive framework for easing the workflow of creating, executing and evaluating experiments. The driving idea behind SciExp² is the need for quick and effortless design-space exploration. It is divided into the following main pieces: * Launchgen: Aids in the process of defining experiments as a permutation of different parameters in the design space, creating the necessary files to run them (configuration files, scripts, etc.). * Launcher: Takes the result of launchgen and integrates with some well-known execution systems (e.g., simple shell scripts or gridengine) to execute and keep track of the experiments (e.g., re-run failed experiments, or run those whose files have been updated). In addition, experiments can be operated through filters that know about the parameters used during experiment generation. * Data: Aids in the process of collecting and analyzing the results of the experiments. Results are collected into arrays whose dimensions can be annotated by the user (e.g., to identify experiment parameters). It also provides functions to automatically extract experiment results into annotated arrays (implemented as numpy arrays with dimension metadata extensions). The framework is available in the form of Python modules which can be easily integrated into your own applications or used as a scripting environment. Notes ----- As you'll see, the data piece is my personal take on "labaled arrays", which I started well before the "datarray" project. It's just too bad that "datarray" did not succeed in unifying the common logic across the different projects with similar features. Cheers, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth

1 0

Indexing structured masked arrays with multidimensional fields; what with fill_value?
by Gerrit Holl 01 Dec '15

01 Dec '15

Hello, usually, a masked array's .fill_value attribute has ndim=0 and the same dtype as the data attribute: In [27]: ar = array((0, [[0.0, 0.0, 0.0], [0.0, 0.0, 0.0]], 0.0), dtype="int, (2,3)float, float") In [28]: arm = ma.masked_array(ar) In [29]: arm.fill_value.ndim Out[29]: 0 In [31]: arm.fill_value.dtype Out[31]: dtype([('f0', '<i8'), ('f1', '<f8', (2, 3)), ('f2', '<f8')]) What would be the optimal approach for .fill_value if I address the member "f1" in this case? The current behaviour is: In [32]: f = arm["f1"] In [36]: f.fill_value Out[36]: array([[ 1.00000000e+20, 1.00000000e+20, 1.00000000e+20], [ 1.00000000e+20, 1.00000000e+20, 1.00000000e+20]]) This breaks the usual behaviour that .fill_value has ndim=0, which can cause bugs such as reported in issue #6723: https://github.com/numpy/numpy/issues/6723 What should numpy do instead? In pull request 6728, I propose to change the behaviour so that arm["f1"].fill_value is set to arm.fill_value["f1"].flat[0]. This is an arbitrary and somewhat ad-hoc solution. If I have chosen to set arm.fill_value["f1"] to something else, such as array([[1., 2., 3.], [4., 5., 6.]]), then the rest of my fill_value is lost. I don't know if this might lead to problems. Does it matter? See also http://stackoverflow.com/questions/33921579/what-practical-impact-if-any-do… . regards, Gerrit.

1 0

ANN: SfePy 2015.4
by Robert Cimrman 01 Dec '15

01 Dec '15

I am pleased to announce release 2015.4 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (preliminary support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: http://groups.google.com/group/sfepy-devel Git (source) repository, issue tracker, wiki: http://github.com/sfepy Highlights of this release -------------------------- - basic support for restart files - new type of linear combination boundary conditions - balloon inflation example For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman on behalf of the SfePy development team --- Contributors to this release in alphabetical order: Robert Cimrman Grant Stephens

1 0

Inconsistent/unexpected indexing semantics
by Lluís Vilanova 01 Dec '15

01 Dec '15

Hi, TL;DR: There's a pending pull request deprecating some behaviour I find unexpected. Does anyone object? Some time ago I noticed that numpy yields unexpected results in some very specific cases. An array can be used to index multiple elements of a single dimension: >>> a = np.arange(8).reshape((2,2,2)) >>> a[ np.array([[0], [0]]) ] array([[[[0, 1], [2, 3]]], [[[0, 1], [2, 3]]]]) Nonetheless, if a list is used instead, it is (unexpectedly) transformed into a tuple, resulting in indexing across multiple dimensions: >>> a[ [[0], [0]] ] array([[0, 1]]) I.e., it is interpeted as: >>> a[ [0], [0] ] array([[0, 1]]) Or what is the same: >>> a[( [0], [0] )] array([[0, 1]]) I've been informed that there's a pending pull request that deprecates this behaviour [1], which could in the future be reverted to what is expected (at least what I expect) from the documents (except for an obscure note in [2]). The discussion leading to this mail can be found here [3]. [1] https://github.com/numpy/numpy/pull/4434 [2] http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html#advanced-ind… [3] https://github.com/numpy/numpy/issues/6564 Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth

3 2