Mailman 3 May 2011 - NumPy-Discussion

f2py complications
by Jose Gomez-Dans 12 May '11

12 May '11

Hi, We have some fortran code that we'd like to wrap using f2py. The code consists of a library that we compile into an .so file, and a file that wraps that library, which is then wrapped by f2py to provide a clean interface to the library. The process thus includes two steps: 1.- Use a makefile to compile the library 2.- Use f2py to create the python bindings from a fortran file, and link dynamically to the library created in the previous step. Now, I don't see why just a call to f2py shouldn't suffice (we don't really need to have an .so lying around, and it implies that we have to set eg $LD_LIBRARY_PATH to search for it). I thought about using a pyf file for this, and use the only :: option: $ f2py -h my_model.pyf -m my_model my_wrapper.f90 only: func1 func2 func3 : all_my_other_files.f even_more_files.f90 $ f2py -c -m my_model --f90flags="-fdefault-real-8 -O3 -march=native -m32" --f90exec=/usr/bin/gfortran --f77exec=/usr/bin/gfortran --opt=-O3 my_model.pyf This however, doesn't seem to work, with python complaining about missing things. If I put all my *.f and *f90 files after the my_model.pyf (which doesn't seem to have them in the file), I get undefined symbol errors when importing the .so in python. Additionally, it would be great to have this compilation in a distutils-friendly package, but how do you specify all these compiler flags? Thanks! Jose

2 1

Problem with Numpy and array
by Claudia Chan Yone 12 May '11

12 May '11

Hi, I have a problem with the Numpy module, but I think it is a very basic issue for many of you... I have a file with numerical data (2 columns, and 5 lignes) as : 1 2 3 4 ... ... And I woulid like to convert it in a matrix as : [[1,2] [3,4] ...] My python script is : fic=open('file.txt','r') ligne=fic.readlines() fic.close() m=numpy.array(ligne) and I get : ['1,2\n' '3,4'] So I cannot call m[0][0]... Even if I modify my text file with : [[1,2], [3,4] ...] I get : ['[[1,2],[3,4]]'] and I cannot call m[0][0]. Thank you very much for your help, Clo

4 5

Mapping of dtype to C types
by Keith Goodman 11 May '11

11 May '11

I'm writing a function that accepts four possible dtypes: int32, int64, float32, float64. The function will call a C extension (wrapped in Cython). What are the equivalent C types? int, long, float, double, respectively? Will that work on all systems?

7 7

EuroPython: Early Bird will end in 2 days!
by Palla 11 May '11

11 May '11

Hi all, If you plan to attend, you could save quite a bit on registration fees! The end of Early bird is on May 12th, Friday, 23:59:59 CEST. We'd like to ask to you to forward this post to anyone that you feel may be interested. We have an amazing lineup of tutorials, events and talks. We have some excellent keynote speakers and a very complete partner program... but early bird registration ends in 2 days! Right now, you still get discounts on talks and tutorials so if you plan to attend Register Now: http://ep2011.europython.eu/registration/ While you are booking, remember to have a look at the partner program and our offer for a prepaid, data+voice+tethering SIM. We'd like to ask to you to forward this post to anyone that you feel may be interested. All the best, -- ->PALLA

1 0

Inconsistent output dtype in mixed scalar-array operations
by Olivier Delalleau 10 May '11

10 May '11

Hi, I opened a ticket about this (http://projects.scipy.org/numpy/ticket/1827), but thought I'd also ask on the mailing list whether this is working as intended. It looks like the resulting dtype of a "+" operation between a scalar and an array can depend on the order of the arguments. This seems wrong. Tested with numpy 1.5.1 under Ubuntu 11.04 (64-bit). In [4]: (numpy.array(0, dtype='uint16') + numpy.array([1], dtype='int8')).dtype Out[4]: dtype('int16') In [6]: (numpy.array([1], dtype='int8') + numpy.array(0, dtype='uint16')).dtype Out[6]: dtype('int8') Thanks for any feedback, -=- Olivier

2 3

bug in numpy.ndarray?
by Paul Anton Letnes 09 May '11

09 May '11

Hi, it seems that I have found a bug in numpy.ndarray. numpy 1.5.1, python 2.7.1 from macports on mac os x 10.6.7. I got the same error on Fedora 14 with numpy 1.4.1 and python 2.7. Appending a [0] to the last line solves the problem. % python testcrash.py [14:13:27 on 11-05-08] <type 'numpy.ndarray'> [ 12.+0.1j] <type 'numpy.ndarray'> [ 1.+0.1j] complex128 Traceback (most recent call last): File "testcrash.py", line 11, in <module> A[0] = A[0] + (eps1 - eps2) TypeError: can't convert complex to float % cat testcrash.py #!/usr/bin/env python import numpy A = numpy.zeros(10, dtype=numpy.complex128) eps1 = numpy.complex128([12.0 + 0.1j]) eps2 = numpy.complex128([1.0 + 0.1j]) print type(eps1), eps1 print type(eps2), eps2 print A.dtype A[0] = A[0] + (eps1 - eps2)

4 5

Bug: np.linalg.qr crash the python interpreter if getting a shape (0, x) array.
by Till Stensitzki 08 May '11

08 May '11

Hi, discovered another small bug. Windows 7 32 bit, Python 2.6. In [1]: np.__version__ Out[1]: '1.5.1' In [2]: a=np.zeros((0,2)) In [3]: np.linalg.qr(a) ** On entry to DGEQRF parameter number 4 had an illegal value --Here python is crashed. While np.linalg.lstsq doesn't crashs, the error message is not very helpfull. greetings Till

2 2

[ANN] EuroScipy 2011 - deadline extended
by Tiziano Zito 08 May '11

08 May '11

=================================== EuroScipy 2011 - Deadline Extended! =================================== Deadline extended! You can submit your contribution until Friday May 13. --------------------------------------------- The 4th European meeting on Python in Science --------------------------------------------- **Paris, Ecole Normale Supérieure, August 25-28 2011** We are happy to announce the 4th EuroScipy meeting, in Paris, August 2011. The EuroSciPy meeting is a cross-disciplinary gathering focused on the use and development of the Python language in scientific research. This event strives to bring together both users and developers of scientific tools, as well as academic research and state of the art industry. Main topics =========== - Presentations of scientific tools and libraries using the Python language, including but not limited to: - vector and array manipulation - parallel computing - scientific visualization - scientific data flow and persistence - algorithms implemented or exposed in Python - web applications and portals for science and engineering. - Reports on the use of Python in scientific achievements or ongoing projects. - General-purpose Python tools that can be of special interest to the scientific community. Tutorials ========= There will be two tutorial tracks at the conference, an introductory one, to bring up to speed with the Python language as a scientific tool, and an advanced track, during which experts of the field will lecture on specific advanced topics such as advanced use of numpy, scientific visualization, software engineering... Keynote Speaker: Fernando Perez =============================== We are excited to welcome Fernando Perez (UC Berkeley, Helen Wills Neuroscience Institute, USA) as our keynote speaker. Fernando Perez is the original author of the enhanced interactive python shell IPython and a very active contributor to the Python for Science ecosystem. Important dates =============== Talk submission deadline: Sunday May 8 Program announced: Sunday May 29 Tutorials tracks: Thursday August 25 - Friday August 26 Conference track: Saturday August 27 - Sunday August 28 Call for papers =============== We are soliciting talks that discuss topics related to scientific computing using Python. These include applications, teaching, future development directions, and research. We welcome contributions from the industry as well as the academic world. Indeed, industrial research and development as well academic research face the challenge of mastering IT tools for exploration, modeling and analysis. We look forward to hearing your recent breakthroughs using Python! Submission guidelines ===================== - We solicit talk proposals in the form of a one-page long abstract. - Submissions whose main purpose is to promote a commercial product or service will be refused. - All accepted proposals must be presented at the EuroSciPy conference by at least one author. The one-page long abstracts are for conference planing and selection purposes only. We will later select papers for publication of post-proceedings in a peer-reviewed journal. How to submit an abstract ========================= To submit a talk to the EuroScipy conference follow the instructions here: http://www.euroscipy.org/card/euroscipy2011_call_for_papers Organizers ========== Chairs: - Gaël Varoquaux (INSERM, Unicog team, and INRIA, Parietal team) - Nicolas Chauvat (Logilab) Local organization committee: - Emmanuelle Gouillart (Saint-Gobain Recherche) - Jean-Philippe Chauvat (Logilab) Tutorial chair: - Valentin Haenel (MKP, Technische Universität Berlin) Program committee: - Chair: Tiziano Zito (MKP, Technische Universität Berlin) - Romain Brette (ENS Paris, DEC) - Emmanuelle Gouillart (Saint-Gobain Recherche) - Eric Lebigot (Laboratoire Kastler Brossel, Université Pierre et Marie Curie) - Konrad Hinsen (Soleil Synchrotron, CNRS) - Hans Petter Langtangen (Simula laboratories) - Jarrod Millman (UC Berkeley, Helen Wills NeuroScience institute) - Mike Müller (Python Academy) - Didrik Pinte (Enthought Inc) - Marc Poinot (ONERA) - Christophe Pradal (CIRAD/INRIA, Virtual Plantes team) - Andreas Schreiber (DLR) - Stéfan van der Walt (University of Stellenbosch) Website ======= http://www.euroscipy.org/conference/euroscipy_2011 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion(a)scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

1 0

Bug? NumPy types circumvent some overloaded methods in ndarray subclasses
by Wes McKinney 08 May '11

08 May '11

This strikes me as a bug-- haven't checked NumPy 1.6 yet but this happens in 1.5.1. Here's a toy example: class MyNdarray(np.ndarray): def __new__(cls, data): subarr = np.array(data, dtype=np.float64).view(cls) return subarr def __radd__(self, other): print 'hello' return (self.view(np.ndarray) + other).view(MyNdarray) def __add__(self, other): print 'hello' return (self.view(np.ndarray) + other).view(MyNdarray) In [25]: foo = MyNdarray(np.arange(10.)) In [26]: foo + 3 hello Out[26]: MyNdarray([ 3., 4., 5., 6., 7., 8., 9., 10., 11., 12.]) In [27]: foo + np.float64(3) hello Out[27]: MyNdarray([ 3., 4., 5., 6., 7., 8., 9., 10., 11., 12.]) In [28]: 3 + foo hello Out[28]: MyNdarray([ 3., 4., 5., 6., 7., 8., 9., 10., 11., 12.]) In [29]: np.float64(3) + foo Out[29]: MyNdarray([ 3., 4., 5., 6., 7., 8., 9., 10., 11., 12.]) I'm not sure if there's an easy workaround here. I thought maybe it was an array priority issue but after some tinkering it doesn't look like it. Any ideas? - Wes

1 0

ANN: Numpy 1.6.0 release candidate 3
by Ralf Gommers 07 May '11

07 May '11

Hi, I am pleased to announce the availability of the third release candidate of NumPy 1.6.0. Compared to the second release candidate, two issues in f2py and one in loadtxt were fixed. If no new problems are reported, the final release will be in one week. Sources and binaries can be found at http://sourceforge.net/projects/numpy/files/NumPy/1.6.0rc3/<http://sourceforge.net/projects/numpy/files/NumPy/1.6.0rc2/> For (preliminary) release notes see below. Enjoy, Ralf ========================= NumPy 1.6.0 Release Notes ========================= This release includes several new features as well as numerous bug fixes and improved documentation. It is backward compatible with the 1.5.0 release, and supports Python 2.4 - 2.7 and 3.1 - 3.2. Highlights ========== * Re-introduction of datetime dtype support to deal with dates in arrays. * A new 16-bit floating point type. * A new iterator, which improves performance of many functions. New features ============ New 16-bit floating point type ------------------------------ This release adds support for the IEEE 754-2008 binary16 format, available as the data type ``numpy.half``. Within Python, the type behaves similarly to `float` or `double`, and C extensions can add support for it with the exposed half-float API. New iterator ------------ A new iterator has been added, replacing the functionality of the existing iterator and multi-iterator with a single object and API. This iterator works well with general memory layouts different from C or Fortran contiguous, and handles both standard NumPy and customized broadcasting. The buffering, automatic data type conversion, and optional output parameters, offered by ufuncs but difficult to replicate elsewhere, are now exposed by this iterator. Legendre, Laguerre, Hermite, HermiteE polynomials in ``numpy.polynomial`` ------------------------------------------------------------------------- Extend the number of polynomials available in the polynomial package. In addition, a new ``window`` attribute has been added to the classes in order to specify the range the ``domain`` maps to. This is mostly useful for the Laguerre, Hermite, and HermiteE polynomials whose natural domains are infinite and provides a more intuitive way to get the correct mapping of values without playing unnatural tricks with the domain. Fortran assumed shape array and size function support in ``numpy.f2py`` ----------------------------------------------------------------------- F2py now supports wrapping Fortran 90 routines that use assumed shape arrays. Before such routines could be called from Python but the corresponding Fortran routines received assumed shape arrays as zero length arrays which caused unpredicted results. Thanks to Lorenz Hüdepohl for pointing out the correct way to interface routines with assumed shape arrays. In addition, f2py supports now automatic wrapping of Fortran routines that use two argument ``size`` function in dimension specifications. Other new functions ------------------- ``numpy.ravel_multi_index`` : Converts a multi-index tuple into an array of flat indices, applying boundary modes to the indices. ``numpy.einsum`` : Evaluate the Einstein summation convention. Using the Einstein summation convention, many common multi-dimensional array operations can be represented in a simple fashion. This function provides a way compute such summations. ``numpy.count_nonzero`` : Counts the number of non-zero elements in an array. ``numpy.result_type`` and ``numpy.min_scalar_type`` : These functions expose the underlying type promotion used by the ufuncs and other operations to determine the types of outputs. These improve upon the ``numpy.common_type`` and ``numpy.mintypecode`` which provide similar functionality but do not match the ufunc implementation. Changes ======= ``default error handling`` -------------------------- The default error handling has been change from ``print`` to ``warn`` for all except for ``underflow``, which remains as ``ignore``. ``numpy.distutils`` ------------------- Several new compilers are supported for building Numpy: the Portland Group Fortran compiler on OS X, the PathScale compiler suite and the 64-bit Intel C compiler on Linux. ``numpy.testing`` ----------------- The testing framework gained ``numpy.testing.assert_allclose``, which provides a more convenient way to compare floating point arrays than `assert_almost_equal`, `assert_approx_equal` and `assert_array_almost_equal`. ``C API`` --------- In addition to the APIs for the new iterator and half data type, a number of other additions have been made to the C API. The type promotion mechanism used by ufuncs is exposed via ``PyArray_PromoteTypes``, ``PyArray_ResultType``, and ``PyArray_MinScalarType``. A new enumeration ``NPY_CASTING`` has been added which controls what types of casts are permitted. This is used by the new functions ``PyArray_CanCastArrayTo`` and ``PyArray_CanCastTypeTo``. A more flexible way to handle conversion of arbitrary python objects into arrays is exposed by ``PyArray_GetArrayParamsFromObject``. Deprecated features =================== The "normed" keyword in ``numpy.histogram`` is deprecated. Its functionality will be replaced by the new "density" keyword. Removed features ================ ``numpy.fft`` ------------- The functions `refft`, `refft2`, `refftn`, `irefft`, `irefft2`, `irefftn`, which were aliases for the same functions without the 'e' in the name, were removed. ``numpy.memmap`` ---------------- The `sync()` and `close()` methods of memmap were removed. Use `flush()` and "del memmap" instead. ``numpy.lib`` ------------- The deprecated functions ``numpy.unique1d``, ``numpy.setmember1d``, ``numpy.intersect1d_nu`` and ``numpy.lib.ufunclike.log2`` were removed. ``numpy.ma`` ------------ Several deprecated items were removed from the ``numpy.ma`` module:: * ``numpy.ma.MaskedArray`` "raw_data" method * ``numpy.ma.MaskedArray`` constructor "flag" keyword * ``numpy.ma.make_mask`` "flag" keyword * ``numpy.ma.allclose`` "fill_value" keyword ``numpy.distutils`` ------------------- The ``numpy.get_numpy_include`` function was removed, use ``numpy.get_include`` instead. Checksums ========= 295c456e5008873a14a56c11bce7cb60 release/installers/numpy-1.6.0rc3-py2.7-python.org-macosx10.6.dmg faaa5e8ec8992263ad444d809a511f07 release/installers/numpy-1.6.0rc3-win32-superpack-python2.5.exe 3a27307c4a5dcd56f8c8a1ae1d858f93 release/installers/numpy-1.6.0rc3-win32-superpack-python2.6.exe 6bf42735d54f7043a0d0b5a9652d3dbb release/installers/numpy-1.6.0rc3-win32-superpack-python2.7.exe 450e39f4666805e53fd750d1d0d07243 release/installers/numpy-1.6.0rc3-win32-superpack-python3.1.exe 500214e83b4823f90569ccf2f947ff6b release/installers/numpy-1.6.0rc3-win32-superpack-python3.2.exe 09efcfdb987899d0ff6b79d79e707ac9 release/installers/numpy-1.6.0rc3.tar.gz 466fe879964de5e9ecb562f48ba18131 release/installers/numpy-1.6.0rc3.zip

1 0