Mailman 3 November 2013 - NumPy-Discussion

Struct dtypes alignment
by Bogdan Opanchuk Nov. 23, 2013

Nov. 23, 2013

Hello, I have some questions about how ``align=True`` and the corresponding ``isalignedstruct`` attribute work. Suppose we create the following dtype: >>> dt1 = numpy.dtype(dict(names=['i1','i2'], formats=[numpy.int32, numpy.int32], offsets=[0,4], itemsize=12, aligned=True)) >>> dt1.alignment 4 >>> dt1.isalignedstruct True The problem here is that the itemsize ``12`` is not actually achievable in C code for these particular fields without an explicit padding. But the ``isalignedstruct`` field reports that the struct is aligned, which is a bit misleading. There is no way to know which is true: 1) ``itemsize`` is consistent with the fields (that is, in C code you would not need any explicit modifiers) 2) ``itemsize`` requires an explicit alignment attribute in C code (e.g, ``itemsize=16`` would be achievable with an explicit alignment=16 applied to the whole struct). 3) ``itemsize`` is not achievable in C code and requires padding. Based on this, I would expect the following behavior: >>> dt1 = numpy.dtype(dict(names=['i1','i2'], formats=[numpy.int32, numpy.int32], offsets=[0,4], itemsize=8, aligned=True)) >>> dt1.base_alignment 4 >>> dt1.alignment 4 >>> dt1.isalignedstruct True >>> dt1 = numpy.dtype(dict(names=['i1','i2'], formats=[numpy.int32, numpy.int32], offsets=[0,4], itemsize=12, aligned=True)) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: itemsize 12 for this dtype is not achievable without an explicit padding >>> dt1 = numpy.dtype(dict(names=['i1','i2'], formats=[numpy.int32, numpy.int32], offsets=[0,4], itemsize=16, aligned=True)) >>> dt1.base_alignment 4 >>> dt1.alignment 16 >>> dt1.isalignedstruct True It would be also convenient to have a keyword for the total alignment of the struct (which will affect how it is placed in an encompassing struct): >>> dt1 = numpy.dtype(dict(names=['i1','i2'], formats=[numpy.int32, numpy.int32], offsets=[0,4], itemsize=8, alignment=8, aligned=True)) >>> dt1.base_alignment 4 >>> dt1.alignment 8 >>> dt1.isalignedstruct True So, is the current numpy behavior an intended one, or is it a bug? Best regards, Bogdan

1 0

numpy.i and INPLACE_ARRAY1[ANY]
by Kaspar Emanuel Nov. 22, 2013

Nov. 22, 2013

Hey, I am trying to improve the Lilv <http://drobilla.net/software/lilv/> Python bindings to include numpy.i to allow for creation and verification of audio test buffers using NumPy. I am just trying to get *something* working at the moment so I am tring to wrap a test function. static inline void lilv_test(float* data_location){} and I have in lilv.i: %apply (float* INPLACE_ARRAY1) {(float* data_location)}; This doesn’t produce any warnings or anything but when I try and use it from Python I get: TypeError: in method 'lilv_test', argument 1 of type 'float *' What does work is if I have: lilv_test(float* data_location, int n){} and %apply (float* INPLACE_ARRAY1, int DIM1) {(float* data_location, int n)}; but this doesn’t fit very well with the functions I eventually want to wrap, as they don’t have a dimension argument. Is it not possible to use INPLACE_ARRAY1 without a dimension? Thanks for any help, Kaspar

2 7

ANN: SfePy 2013.4
by Robert Cimrman Nov. 22, 2013

Nov. 22, 2013

I am pleased to announce release 2013.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. The code is based on NumPy and SciPy packages. 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 -------------------------- - simplified quadrature definition - equation sequence solver - initial support for 'plate' integration/connectivity type - script for visualization of quadrature points and weights For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman and Contributors (*) (*) Contributors to this release (alphabetical order): Vladimír Lukeš, Jaroslav Vondřejc

1 0

f2py and Fortran STOP statement issue
by Pearu Peterson Nov. 21, 2013

Nov. 21, 2013

Hi, The issue with wrapping Fortran codes that contain STOP statements has been raised several times in past with no good working solution proposed. Recently the issue was raised again in f2py issues. Since the user was filling to test out few ideas with positive results, I decided to describe the outcome (a working solution) in the following wikipage: https://code.google.com/p/f2py/wiki/FAQ2ed Just FYI, Pearu

1 0

strange runtimes of numpy fft
by Max Linke Nov. 20, 2013

Nov. 20, 2013

Hi I noticed some strange scaling behavior of the fft runtime. For most array-sizes the fft will be calculated in a couple of seconds, even for very large ones. But there are some array sizes in between where it will take about ~20 min (e.g. 400000). This is really odd for me because an array with 10 million entries is transformed in ~2s. Is this typical for numpy? I attached a plot and an ipynb to reproduce and illustrate it. best Max

11 20

ANN: Bokeh 0.3 released
by Bryan Van de Ven Nov. 20, 2013

Nov. 20, 2013

I am pleased to announce the release of Bokeh 0.3! Bokeh is a Python interactive visualization library for large datasets that natively uses the latest web technologies. Its goal is to provide elegant, concise construction of novel graphics in the style of Protovis/D3, while delivering high-performance interactivity over large data to thin clients. If you are using Anaconda, you can install through conda: conda install bokeh Alternatively you can install from PyPI using pip: pip install bokeh This release was largely an internal refactor to merge the BokehJS and Bokeh projects into one repository, and to greatly improve and simplify the BokehJS coffee script build process. Additionally, this release also includes a number of bug and stability fixes, and some enhancements. See the CHANGELOG for full details. Many new examples were added including a reproduction of Burtin's Antibiotics, and examples of animation using the Bokeh plot server inside IPython notebooks. ColorBrewer palettes were also added on the python side. Finally, the user guide has been flushed out and will continually be updated as features and API changes are made. Check out the full documentation and interactive gallery at http://bokeh.pydata.org The release of Bokeh 0.4 is planned for early January. Some notable features to be included are: * Integrate Abstract Rendering into bokeh server * Better grid-based layout system; use Cassowary.js for layout solver * Tool Improvements (pan always on, box zoom always on, passive resize with hot corners) * Basic MPL compatibility interface (enough to make ggplot.py work) * Expose image plot in Python interface Issues or enhancement requests can be logged on the Bokeh Github page: https://github.com/continuumio/bokeh Questions can be directed to the Bokeh mailing list: bokeh(a)continuum.io Regards, Bryan Van de Ven

1 0

RuntimeWarning raised in the wrong line
by Daπid Nov. 20, 2013

Nov. 20, 2013

I have the following code, operating on some arrays. pen = 1 - (real_sum[int(i1 + t)]) / (absolute[int(i1 + t)]) if np.isnan(pen): pen = 0.0 I know that, sometimes, real_sum and absolute are 0 at the designated point, so I should get a RuntimeWarning. But, the warning is puzzling: RuntimeWarning: invalid value encountered in double_scalars pen = 0.0 Is the warning actually being raised at that point? Or can I not really trust the line reported by the warning? I have tried to replicate it in interactive terminal, but without luck, I always get it in the previous line. I am using Python 2.7 and Numpy 1.8.0. /David.

2 1

ANN: Scipy 0.13.1 release
by Ralf Gommers Nov. 18, 2013

Nov. 18, 2013

Hi, I'm happy to announce the availability of the scipy 0.13.1 release. This is a bugfix only release; it contains several fixes for issues in ndimage. Thanks to Pauli Virtanen and Ray Jones for fixing these issues quickly. Source tarballs, binaries and release notes can be found at http://sourceforge.net/projects/scipy/files/scipy/0.13.1/. Cheers, Ralf ========================== SciPy 0.13.1 Release Notes ========================== SciPy 0.13.1 is a bug-fix release with no new features compared to 0.13.0. The only changes are several fixes in ``ndimage``, one of which was a serious regression in ``ndimage.label`` (Github issue 3025), which gave incorrect results in 0.13.0. Issues fixed ------------ - 3025: ``ndimage.label`` returns incorrect results in scipy 0.13.0 - 1992: ``ndimage.label`` return type changed from int32 to uint32 - 1992: ``ndimage.find_objects`` doesn't work with int32 input in some cases

2 3

runtime warning for where
by David Pine Nov. 16, 2013

Nov. 16, 2013

The program at the bottom of this message returns the following runtime warning: python test.py test.py:5: RuntimeWarning: invalid value encountered in divide return np.where(x==0., 1., np.sin(x)/x) The function works correctly returning x = np.array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9., 10.]) y = np.array([ 1. , 0.84147098, 0.45464871, 0.04704 , -0.18920062, -0.19178485, -0.04656925, 0.09385523, 0.12366978, 0.04579094, -0.05440211]) The runtime warning suggests that np.where evaluates np.sin(x)/x at all x, including x=0, even though the np.where function returns the correct value of 1. when x is 0. This seems odd to me. Why issue a runtime warning? Nothing is wrong. Moreover, I don't recall numpy issuing such warnings in earlier versions. import numpy as np import matplotlib.pyplot as plt def sinc(x): return np.where(x==0., 1., np.sin(x)/x) x = np.linspace(0., 10., 11) y = sinc(x) plt.plot(x, y) plt.show()

5 5

Caution about using intrisincs, and other 'advanced' optimizations
by David Cournapeau Nov. 16, 2013

Nov. 16, 2013

Hi there, I have noticed more and more subtle and hard to track serious bugs in numpy and scipy, due to the use of advanced optimization features (flags, or gcc intrinsics). I am wondering whether those are worth it: they compile wrongly under quite a few configurations, and it is not always obvious to find the cause (case in point: gcc 4.4 with numpy 1.8.0 causes infinite loop in scipy.stats, which disappear if I disable the intrinsics in numpy/npy_config.h). Maybe they should be disabled by default, and only built in if required ? Do we know for sure they bring significant improvements ? While gcc 4.4 is not the most recent compiler, it is not ancient either, David

4 7