Mailman 3 December 2014 - NumPy-Discussion

simple reduction question
by Neal Becker Dec. 24, 2014

Dec. 24, 2014

What would be the most efficient way to compute: c[j] = \sum_i (a[i] * b[i,j]) where a[i] is a 1-d vector, b[i,j] is a 2-d array? This seems to be one way: import numpy as np a = np.arange (3) b = np.arange (12).reshape (3,4) c = np.dot (a, b).sum() but np.dot returns a vector, which then needs further reduction. Don't know if there's a better way. -- -- Those who don't understand recursion are doomed to repeat it

5 5

Re: [Numpy-discussion] Fast sizes for FFT
by RayS Dec. 24, 2014

Dec. 24, 2014

At 06:47 PM 12/23/2014, you wrote: >The performance of fftpack depends very strongly on the array size >-- sizes that are powers of two are good, but also powers of three, >five and seven, or numbers whose only prime factors are from >(2,3,5,7). For problems that can use padding, rounding up the size >(using np.fft.fft(x, n=size_with_padding)) to one of these multiples >makes a big difference. Checking some of my old code, we had typically done: N2 = 2**int(math.ceil(math.log(N,2))) and then something like abs(rfft(data[minX:maxX, ch]*weightingArray, N2))[1:numpy.floor(N2/2)+1] * norm_factor In the PDF linked, I can see where N % 3,5,7 could really help; we just don't do giant FFTs (>2**22) often. However, users would often see loooong waits if/when they selected prime N on a data plot and asked for the full FFT without padding enabled - like ~5 seconds on a Core 2. When released we'll certainly use the new functionality. - Ray

1 0

Fast sizes for FFT
by Robert McGibbon Dec. 24, 2014

Dec. 24, 2014

Hey, The performance of fftpack depends very strongly on the array size -- sizes that are powers of two are good, but also powers of three, five and seven, or numbers whose only prime factors are from (2,3,5,7). For problems that can use padding, rounding up the size (using np.fft.fft(x, n=size_with_padding)) to one of these multiples makes a big difference. Some other packages expose a function for calculating the next fast size, e.g: http://ltfat.sourceforge.net/notes/ltfatnote017.pdf. Is there anything like this in numpy/scipy? If not, would this be a reasonable feature to add? -Robert

5 10

Why am I getting a FutureWarning with this code?
by Steve Spicklemire Dec. 22, 2014

Dec. 22, 2014

I’m working on visual python (http://vpython.org) which lists numpy among its dependencies. I recently updated my numpy installation to 1.9.1 and I’m now encountering this error: /usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/VPython-6.10-py2.7-macosx-10.10-x86_64.egg/visual_common/materials.py:70: FutureWarning: comparison to `None` will result in an elementwise object comparison in the future. self.__setattr__(key, value) Oddly, the code in question looks like this: 62 from . import cvisual 63 from numpy import array, reshape, fromstring, ubyte, ndarray, zeros, asarray 64 import os.path, math 65 66 class raw_texture(cvisual.texture): 67 def __init__(self, **kwargs): 68 cvisual.texture.__init__(self) 69 for key, value in kwargs.items(): 70 self.__setattr__(key, value) 71 72 class shader_material(cvisual.material): 73 def __init__(self, **kwargs): 74 cvisual.material.__init__(self) 75 for key, value in kwargs.items(): 76 self.__setattr__(key, value) I’m not clear on how __setattr__ is being called out as an array comparison. help? thanks, -steve

4 4

Re: [Numpy-discussion] [SciPy-Dev] ANN: Scipy 0.14.1 release candidate 1
by David Cournapeau Dec. 19, 2014

Dec. 19, 2014

I built that rc on top of numpy 1.8.1 and MKL, and it worked on every platform we support @ Enthought. I saw a few test failures on linux and windows 64 bits, but those were there before or are precisions issues. I also tested when run on top of numpy 1.9.1 (but still built against 1.8.1), w/ similar results. Thanks for all the hard work, David On Sun, Dec 14, 2014 at 10:29 PM, Pauli Virtanen <pav(a)iki.fi> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > We have finished preparing the Scipy 0.14.1 release candidate 1. > If no regressions turn up, the final release is planned within the > following weeks. > > The 0.14.1 release will be a bugfix-only release, addressing the > following issues: > > - - gh-3630 NetCDF reading results in a segfault > - - gh-3631 SuperLU object not working as expected for complex matrices > - - gh-3733 Segfault from map_coordinates > - - gh-3780 Segfault when using CSR/CSC matrix and uint32/uint64 > - - gh-3781 Fix omitted types in sparsetools typemaps > - - gh-3802 0.14.0 API breakage: _gen generators are missing from > scipy.stats.distributions API > - - gh-3805 ndimge test failures with numpy 1.10 > - - gh-3812 == sometimes wrong on csr_matrix > - - gh-3853 Many scipy.sparse test errors/failures with numpy 1.9.0b2 > - - gh-4084 Fix exception declarations for Cython 0.21.1 compatibility > - - gh-4093 Avoid a memory error in splev(x, tck, der=k) > - - gh-4104 Workaround SGEMV segfault in Accelerate (maintenance 0.14.x) > - - gh-4143 Fix ndimage functions for large data > - - gh-4149 Bug in expm for integer arrays > - - gh-4154 Ensure that the 'size' argument of PIL's 'resize' method is > a tuple > - - gh-4163 ZeroDivisionError in scipy.sparse.linalg.lsqr > - - gh-4164 Remove use of deprecated numpy API in lib/lapack/ f2py wrapper > - - gh-4180 pil resize support tuple fix > - - gh-4168 Address arpack test failures on windows 32 bits with numpy > 1.9.1 > - - gh-4218 make ndimage interpolation compatible with numpy relaxed > strides > - - gh-4225 off-by-one error in PPoly shape checks > - - gh-4248 fix issue with incorrect use of closure for slsqp > > Source tarballs and binaries are available at > https://sourceforge.net/projects/scipy/files/scipy/0.14.1rc1/ > > Best regards, > Pauli Virtanen > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlSOD0YACgkQ6BQxb7O0pWDO5ACfccLqMvZWfkHqSzDCkMSoRKAU > n7cAni6XhWJRy7oJ757rlGeIi0e34HTn > =9bB/ > -----END PGP SIGNATURE----- > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev(a)scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev >

1 0

Re: [Numpy-discussion] [SciPy-Dev] ANN: Scipy 0.15.0 release candidate 1
by Matthew Brett Dec. 17, 2014

Dec. 17, 2014

Hi, On Mon, Dec 15, 2014 at 2:47 PM, Pauli Virtanen <pav(a)iki.fi> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > Scipy 0.15.0 release candidate 1 is now available. If no surprises > turn up, the final release is planned within two weeks. > > Source tarballs, full release notes etc. are available at > https://sourceforge.net/projects/scipy/files/scipy/0.15.0rc1/ OSX wheels at http://wheels.scipy.org/ (via https://travis-ci.org/MacPython/scipy-wheels). Scipy-stack tests running at https://travis-ci.org/MacPython/scipy-stack-osx-testing Cheers, Matthew

1 0

[ANN] Summer School "Advanced Scientific Programming in Python" in Munich, Germany
by Tiziano Zito Dec. 17, 2014

Dec. 17, 2014

Advanced Scientific Programming in Python ========================================= a Summer School by the G-Node, the Bernstein Center for Computational Neuroscience Munich and the Graduate School of Systemic Neurosciences Scientists spend more and more time writing, maintaining, and debugging software. While techniques for doing this efficiently have evolved, only few scientists have been trained to use them. As a result, instead of doing their research, they spend far too much time writing deficient code and reinventing the wheel. In this course we will present a selection of advanced programming techniques, incorporating theoretical lectures and practical exercises tailored to the needs of a programming scientist. New skills will be tested in a real programming project: we will team up to develop an entertaining scientific computer game. We use the Python programming language for the entire course. Python works as a simple programming language for beginners, but more importantly, it also works great in scientific simulations and data analysis. We show how clean language design, ease of extensibility, and the great wealth of open source libraries for scientific computing and data visualization are driving Python to become a standard tool for the programming scientist. This school is targeted at Master or PhD students and Post-docs from all areas of science. Competence in Python or in another language such as Java, C/C++, MATLAB, or Mathematica is absolutely required. Basic knowledge of Python is assumed. Participants without any prior experience with Python should work through the proposed introductory materials before the course. Date and Location ================= August 31—September 5, 2015. Munich, Germany. Preliminary Program =================== Day 0 (Mon Aug 31) — Best Programming Practices • Best Practices for Scientific Computing • Version control with git and how to contribute to Open Source with github • Object-oriented programming & design patterns Day 1 (Tue Sept 1) — Software Carpentry • Test-driven development, unit testing & quality assurance • Debugging, profiling and benchmarking techniques • Advanced Python: generators, decorators, and context managers Day 2 (Wed Sept 2) — Scientific Tools for Python • Advanced NumPy • The Quest for Speed (intro): Interfacing to C with Cython • Contributing to Open Source Software/Programming in teams Day 3 (Thu Sept 3) — The Quest for Speed • Writing parallel applications in Python • Python 3: why should I care • Programming project Day 4 (Fri Sept 4) — Efficient Memory Management • When parallelization does not help: the starving CPUs problem • Programming project Day 5 (Sat Sept 5) — Practical Software Development • Programming project • The Pelita Tournament Every evening we will have the tutors' consultation hour: Tutors will answer your questions and give suggestions for your own projects. Applications ============ You can apply on-line at https://python.g-node.org Applications must be submitted before 23:59 UTC, March 31, 2015. Notifications of acceptance will be sent by May 1, 2015. No fee is charged but participants should take care of travel, living, and accommodation expenses. Candidates will be selected on the basis of their profile. Places are limited: acceptance rate is usually around 20%. Prerequisites: You are supposed to know the basics of Python to participate in the lectures Preliminary Faculty =================== • Francesc Alted, freelance developer, author of PyTables, Spain • Pietro Berkes, Enthought Inc., UK • Kathryn D. Huff, Department of Nuclear Engineering, University of California - Berkeley, USA • Zbigniew Jędrzejewski-Szmek, Krasnow Institute, George Mason University, USA • Eilif Muller, Blue Brain Project, École Polytechnique Fédérale de Lausanne, Switzerland • Rike-Benjamin Schuppner, Institute for Theoretical Biology, Humboldt-Universität zu Berlin, Germany • Nelle Varoquaux, Centre for Computational Biology Mines ParisTech, Institut Curie, U900 INSERM, Paris, France • Stéfan van der Walt, Applied Mathematics, Stellenbosch University, South Africa • Niko Wilbert, TNG Technology Consulting GmbH, Germany • Tiziano Zito, Forschungszentrum Jülich GmbH, Germany Organized by Tiziano Zito (head) and Zbigniew Jędrzejewski-Szmek for the German Neuroinformatics Node of the INCF Germany, Christopher Roppelt for the German Center for Vertigo and Balance Disorders (DSGZ) and the Graduate School of Systemic Neurosciences (GSN) of the Ludwig-Maximilians-Universität Munich Germany, Christoph Hartmann for the Frankfurt Institute for Advanced Studies (FIAS) and International Max Planck Research School (IMPRS) for Neural Circuits, Frankfurt Germany, and Jakob Jordan for the Institute of Neuroscience and Medicine (INM-6) and Institute for Advanced Simulation (IAS-6), Jülich Research Centre and JARA. Additional funding provided by the Bernstein Center for Computational Neuroscience (BCCN) Munich. Website: https://python.g-node.org Contact: python-info(a)g-node.org

1 0

Context manager for seterr
by Stefan van der Walt Dec. 15, 2014

Dec. 15, 2014

Hi all, Since the topic of context managers recently came up, what do you think of adding a context manager for seterr? with np.seterr(divide='ignore'): frac = num / denom Stéfan

3 5

Re: [Numpy-discussion] Fwd: numpy.i and std::complex
by Glen Mabey Dec. 14, 2014

Dec. 14, 2014

Hello, Ok, here's my attempt -- https://github.com/gmabey/numpy/compare/swig-std-complex Glen On Oct 27, 2014, at 11:13 AM, Bill Spotz <wfspotz(a)sandia.gov> wrote: > Supporting std::complex<> was just low enough priority for me that I decided to wait until someone expressed interest ... and now, many years later, someone finally has. > > I would be happy to include this into numpy.i, but I would like to see some tests in the numpy repository demonstrating that it works. These could be relatively short and simple, and since float and double are the only scalar data types that I could foresee supporting, there would not be a need for testing the large numbers of data types that the other tests cover. > > I would also want to protect the references to C++ objects with '#ifdef __cplusplus', but that is easy enough. > > -Bill > > On Oct 27, 2014, at 9:06 AM, Glen Mabey <gmabey(a)swri.org> wrote: > >> Hello, >> >> I was very excited to learn about numpy.i for easy numpy+swigification of C code -- it's really handy. >> >> Knowing that swig wraps C code, I wasn't too surprised that there was the issue with complex data types (as described at http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html#other-co…), but still it was pretty disappointing because most of my data is complex, and I'm invoking methods written to use C++'s std::complex class. >> >> After quite a bit of puzzling and not much help from previous mailing list posts, I created this very brief but very useful file, which I call numpy_std_complex.i -- >> >> /* -*- C -*- (not really, but good for syntax highlighting) */ >> #ifdef SWIGPYTHON >> >> %include "numpy.i" >> >> %include <std_complex.i> >> >> %numpy_typemaps(std::complex<float>, NPY_CFLOAT , int) >> %numpy_typemaps(std::complex<double>, NPY_CDOUBLE, int) >> >> #endif /* SWIGPYTHON */ >> >> >> I'd really like for this to be included alongside numpy.i -- but maybe I overestimate the number of numpy users who use complex data (let your voice be heard!) and who also end up using std::complex in C++ land. >> >> Or if anyone wants to improve upon this usage I would be very happy to hear about what I'm missing. >> >> I'm sure there's a documented way to submit this file to the git repo, but let me simultaneously ask whether list subscribers think this is worthwhile and ask someone to add+push it for me … >> >> Thanks, >> Glen Mabey >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion(a)scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > ** Bill Spotz ** > ** Sandia National Laboratories Voice: (505)845-0170 ** > ** P.O. Box 5800 Fax: (505)284-0154 ** > ** Albuquerque, NM 87185-0370 Email: wfspotz(a)sandia.gov ** > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion(a)scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion

2 2

Bilinear interpolation (numpy only)
by Nicolas P. Rougier Dec. 14, 2014

Dec. 14, 2014

Hi all, Does anyone has a simple 2D linear interpolation for resizing an image (without scipy) ? Ideally, something like ```def zoom(Z, ratio): ...``` where Z is a 2D scalar array and ratio the scaling factor. (I'm currently using ```scipy.ndimage.interpolation.zoom``` but I would like to avoid the scipy dependency) Thanks. Nicolas

2 3