Evgeni Burovski | 26 Nov 23:11 2014

Blomberg open source event London 29-30 Nov


In case somebody is interested and have not heard about it --- Blooomberg is organizing a two-day open source event for scientific python in London this weekend, Nov 28-29.

The event is RSVP:  


Here are related annoucements/discussions in pydata and numpy lists: 
If you are not around, consider joining remotely --- I do not speak for the organizers, but we can always self-organize on github or ML.

See you on Saturday --- in person or online,

SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
Irvin Probst | 26 Nov 19:59 2014

Pole placement


Is there any reason why scipy has no pole placement method (ppol in 
Scilab or place in Matlab)? I.e for a given linear system xdot=A*X+B*U, 
and a given set of poles P, find K such as eigenvalues(A-BK)=P ? Or did 
I miss it in the doc ?

I'm aware of python-control 
but 99.9% of the time I use it it is ONLY for pole placement as scipy 
already provides enough tools for simple linear systems simulations, 
furthermore python-control's place() function only task is to call the 
relevant function in the Scilot library (which I also need to install 
BTW+ bindings from scylot).

So, I've started to port in "pure" numpy/python matlab's place() 
function which is based on Kautsky et Al's algorithm, would it be of any 
intest for you ? It is not rocket science, and it is not finished yet, 
but I thought it could be useful for other people.

Let me know what you think and sorry for the disturbance if it is not 
relevant for you.



Apps Embedded | 25 Nov 10:39 2014

SciPy under Android


We are about publishing an Android app with all the SciPy python packages.
We will include :
- Python
- Numpy package
- Scipy package
- Matplotlib package
- pandas package
- Sympy package
- iPython
- nose package

The app will be published under a freemium model.
The free app will include a small top ad banner and enable user to use all the packages. However in this free app, graphics will not be available.
In the premium app for a very small fee under the Play Store, user will have access to the same things as the free version but the top ad banner will be removed and the graphics will be enabled with the use of Matplotlib.

We are going to call these two apps "LabPy Console Free" and "LabPy Console Premium".

The licence of the work bundle will be GPL v3 but the Python software and all the associated packages will stay in their respective licence. We will of course publish the source code of all the project.

We had recently the written approbation of the Python Trademark comittee from a trademark point of view.

We are writing this email to see if there are no legal issue we are missing with the licence for example and if the name of the app LabPy Console Free / Premium is ok from your point of view.

Best regards.

Apps Embedded Team.

SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
Michael Käppler | 24 Nov 08:42 2014

[Wiki] NumPy / Matlab-Cheatsheet

Hi guys,
thanks for this great cheatsheet you provided on 
I'm not allowed to edit the wiki, so I would like to propose an addition 
regarding different array shaping conventions: Consider f.e. a Matlab 
zeros(1, 4).
If I'm right, this results in a [0 0 0 0] or in something that Matlab 
treats like a 1D-Array if it makes sense. You can f.e. do 
diag(ones(1, 4)) and you get a matrix.
However, NumPy zeros((1,4)) results in [[0 0 0 0]], which is 2D and if you 
try to do diag(ones((1,4))) you will get [1], which is obviously different 
behaviour compared to Matlab.
NumPy zeros(4) yields [0 0 0 0] which seems to me is the correct 
equivalent. Other Matlab commands that use this array shaping syntax are 
also affected in the same way.
I recently ran into this issue while porting some Matlab code to NumPy.

Have a nice week,
Ryan Orendorff | 17 Nov 22:39 2014

PyOp: Linear Operator package

Hi SciPy,

We wanted to get our recent work on an extended linear operator
package out there to the community and get your thoughts. We are
calling our work PyOp and the motivation is to extend the
scipy.sparse.linalg LinearOperator class. In particular, our goals are
to integrate robust ability for matrix-free methods and use in inverse
problems (forward and adjoint operations). This includes seemless
composition of various forms of operators (dense/sparse matrix,
matrix-free functions) and a handful of useful predefined operators
(convolve, FFT, gradient, etc.). We are inoperable with the scipy
LinearOperator functions, support various ways of constructing block
operators (bmat), and we have implemented convenient methods for
working with vectorized inputs.

Source: https://github.com/rdodesigns/pyop
Documentation: http://rdodesigns.github.io/pyop/

Ryan Orendorff and Daniel Hensley
vattan | 16 Nov 20:20 2014

Best practice property storage

I am working on a module to handle simple fluid and thermal problems.  To simplify data entry i am storing material properties as dicts named after the material, ie air{'density':1.2,....} and my functions can just take a material that is predefined or created by the user and use it assuming the needed properties are defined.
My concern is this may be too simplistic, for example in the future my module may need to vary density with temperature, but my current logic is all material properties are static.  Am I better off using objects to contain mtl properties so that they can contain functions to modify inter-related properties?

Thanks guys, hope to get my stuff cleaned up and on github by next weekend.

SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
Pauli Virtanen | 16 Nov 19:53 2014

Release schedule


The 0.14.1 and 0.15.0 releases were delayed a bit. My suggested release
plan is below:


- rc1: Nov 23
- final: Dec 7

High-priority bugfixes have still some time to be backported. Currently,
I'm aware of the OSX/SGEMV issue which could be added, plus expm integer
dtype fix.


- branch & beta1: Nov 23
- rc1: Dec 7
- final: Dec 20

The 0.15.0 has a number of issues tagged for it:

vattan | 16 Nov 04:56 2014

scikit guide, writing one

Hello folks, just subscribed to the list and I am looking to get some
feedback.   I am a brand new scipy convert, never used it prior to
about 3 weeks ago, always used Octave/Matlab, but since Octave doesn't
have a GUI generator, I decided it was time to jump full in and here I

anyways I am porting over my limited old scripts and functions and my
fluid flow stuff has grown exponentionally and is quite convenient
imho.  I would love to lend it out to the community as a scikit, but
it ilikely is highly divergent from what the norm and standard is as I
am NOT a programmer by trade or schooling, and I have neve even used
python before.

I am willing to put it up on github or whever a normal place for such
a kit would be if anyone is willing to help me keep it conforming to
"best practices" and avoid dumb pitfalls.  As it sits now it is
probably too poorly written to be of any use to anyone but me, however
much to my surprise I couldn't find a equivalent already out in the
wild.  currently it has channel objects that define a geometry, fluid
flow objects that contain a channel, length, fluid.  It also has a few
unit converters functions for convenience, sample materials etc.

I really enjoy writing this stuff, i just don't have a ton of time,
but every now and then I just like to sit and code for a day straight
when I can, its very cathartic vs what I normally do.
Julian Taylor | 2 Nov 14:33 2014

ANN: NumPy 1.9.1 bugfix release


We am pleased to announce the release of NumPy 1.9.1, a
bugfix only release for the 1.9.x series.
The upgrade is recommended for all users of the 1.9.x series.

Following issues have been fixed:
* gh-5184: restore linear edge behaviour of gradient to as it was in < 1.9.
  The second order behaviour is available via the `edge_order` keyword
* gh-4007: workaround Accelerate sgemv crash on OSX 10.9
* gh-5100: restore object dtype inference from iterable objects without
* gh-5163: avoid gcc-4.1.2 (red hat 5) miscompilation causing a crash
* gh-5138: fix nanmedian on arrays containing inf
* gh-5240: fix not returning out array from ufuncs with subok=False set
* gh-5203: copy inherited masks in MaskedArray.__array_finalize__
* gh-2317: genfromtxt did not handle filling_values=0 correctly
* gh-5067: restore api of npy_PyFile_DupClose in python2
* gh-5063: cannot convert invalid sequence index to tuple
* gh-5082: Segmentation fault with argmin() on unicode arrays
* gh-5095: don't propagate subtypes from np.where
* gh-5104: np.inner segfaults with SciPy's sparse matrices
* gh-5251: Issue with fromarrays not using correct format for unicode arrays
* gh-5136: Import dummy_threading if importing threading fails
* gh-5148: Make numpy import when run with Python flag '-OO'
* gh-5147: Einsum double contraction in particular order causes ValueError
* gh-479: Make f2py work with intent(in out)
* gh-5170: Make python2 .npy files readable in python3
* gh-5027: Use 'll' as the default length specifier for long long
* gh-4896: fix build error with MSVC 2013 caused by C99 complex support
* gh-4465: Make PyArray_PutTo respect writeable flag
* gh-5225: fix crash when using arange on datetime without dtype set
* gh-5231: fix build in c99 mode

The source distributions have been uploaded to PyPI. The Windows
installers, documentation and release notes can be found at:

Julian Taylor

SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
David Strozzi | 1 Nov 15:56 2014

definition in scipy.signal.hilbert


It would be nice to add an exact formula for the Hilbert transform in
the document comment for scipy.signal.hilbert.  In particular,
different authors use a different overall sign convention.  Not a big
deal but having a formula would save some time.

Matthew Brett | 31 Oct 08:16 2014

ndimage reflect mode


Sorry if this is a dumb question, but I just noticed some behavior of
scipy.ndimage that surprised me:

In [63]: oned = np.arange(1, 10, dtype=float)
In [64]: scipy.ndimage.affine_transform(oned, [1], [-2], mode='reflect')
Out[64]: array([ 2.,  1.,  1.,  2.,  3.,  4.,  5.,  6.,  7.])

OK so far.  But this I was surprised by:

In [68]: scipy.ndimage.affine_transform(oned, [1], [-2 - 1e-15], mode='reflect')
Out[68]: array([ 2.,  1.,  2.,  2.,  3.,  4.,  5.,  6.,  7.])

Why did the third value turn from a 1 into a 2?  I am missing something obvious?