Mailman 3 November 2014 - SciPy-Dev

Documentation page on API
by Yuxiang Wang 14 Dec '14

14 Dec '14

(Sorry about sending this to the wrong list, scipy-user instead of scipy-dev, before; apologize to those who saw this twice) Hi all, I was reading through the link (http://docs.scipy.org/doc/scipy/reference/api.html#guidelines-for-importing…) and it mentioned that the first form is preferred over the second one under most circumstances: # first form from scipy import stats stats.lomax(...) # second form from scipy.stats import distributions distributions.lomax(...) I honestly think the second form is far more frequently used in the examples given in the document, for example: http://docs.scipy.org/doc/scipy/reference/tutorial/special.html http://docs.scipy.org/doc/scipy/reference/tutorial/integrate.html http://docs.scipy.org/doc/scipy/reference/tutorial/optimize.html http://docs.scipy.org/doc/scipy/reference/tutorial/interpolate.html http://docs.scipy.org/doc/scipy/reference/tutorial/fftpack.html Would you think it'd be better to update this link? -Shawn

2 2

Pole placement
by Irvin Probst 06 Dec '14

06 Dec '14

Hi, 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 (http://www.cds.caltech.edu/~murray/wiki/Control_Systems_Library_for_Python) 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. Regards -- Irvin

3 7

SciPy under Android
by Apps Embedded 02 Dec '14

02 Dec '14

Hi, 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.

4 5

ANN: SfePy 2014.4
by Robert Cimrman 28 Nov '14

28 Nov '14

I am pleased to announce release 2014.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 -------------------------- - preliminary support for 1D problems - data probes using pyVTK library 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): Lubos Kejzlar, Vladimir Lukes

1 0

Blomberg open source event London 29-30 Nov
by Evgeni Burovski 27 Nov '14

27 Nov '14

Hi, 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: <http://go.bloomberg.com/promo/invite/bloomberg-open-source-day-scientific-p…> http://go.bloomberg.com/promo/invite/bloomberg-open-source-day-scientific-p… Here are related annoucements/discussions in pydata and numpy lists: https://groups.google.com/forum/#!topic/pydata/Z9Nd3sQH8Lw http://mail.scipy.org/pipermail/numpy-discussion/2014-November/071724.html 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, Evgeni

2 1

ANN: Scipy 0.15.0 beta 1 release
by Pauli Virtanen 26 Nov '14

26 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We have finally finished preparing the Scipy 0.15.0 beta 1 release. Please try it and report any issues on the scipy-dev mailing list, and/or on Github. If no surprises turn up, the final release is planned on Dec 20 in three weeks. Source tarballs and full release notes are available at https://sourceforge.net/projects/scipy/files/SciPy/0.15.0b1/ Binary installers should also be up soon. Best regards, Pauli Virtanen - -------------------------------------------- SciPy 0.15.0 is the culmination of 6 months of hard work. It contains several new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Moreover, our development attention will now shift to bug-fix releases on the 0.16.x branch, and on adding new features on the master branch. This release requires Python 2.6, 2.7 or 3.2-3.3 and NumPy 1.5.1 or greater. New features ============ Linear Programming Interface - - ---------------------------- The new function ``scipy.optimize.linprog`` provides a generic linear programming similar to the way ``scipy.optimize.minimize`` provides a generic interface to nonlinear programming optimizers. Currently the only method supported is *simplex* which provides a two-phase, dense-matrix-based simplex algorithm. Callbacks functions are supported,allowing the user to monitor the progress of the algorithm. Differential_evolution, a global optimizer - - ------------------------------------------ A new ``differential_evolution`` function is available in the ``scipy.optimize`` module. Differential Evolution is an algorithm used for finding the global minimum of multivariate functions. It is stochastic in nature (does not use gradient methods), and can search large areas of candidate space, but often requires larger numbers of function evaluations than conventional gradient based techniques. ``scipy.signal`` improvements - - ----------------------------- The function ``max_len_seq`` was added, which computes a Maximum Length Sequence (MLS) signal. ``scipy.integrate`` improvements - - -------------------------------- It is now possible to use ``scipy.integrate`` routines to integrate multivariate ctypes functions, thus avoiding callbacks to Python and providing better performance. ``scipy.linalg`` improvements - - ----------------------------- Add function ``orthogonal_procrustes`` for solving the procrustes linear algebra problem. ``scipy.sparse`` improvements - - ----------------------------- ``scipy.sparse.linalg.svds`` can now take a ``LinearOperator`` as its main input. ``scipy.special`` improvements - - ------------------------------ Values of ellipsoidal harmonic (i.e. Lame) functions and associated normalization constants can be now computed using ``ellip_harm``, ``ellip_harm_2``, and ``ellip_normal``. New convenience functions ``entr``, ``rel_entr`` ``kl_div``, ``huber``, and ``pseudo_huber`` were added. ``scipy.sparse.csgraph`` improvements - - ------------------------------------- Routines ``reverse_cuthill_mckee`` and ``maximum_bipartite_matching`` for computing reorderings of sparse graphs were added. ``scipy.stats`` improvements - - ---------------------------- Added a Dirichlet distribution as multivariate distribution. The new function ``scipy.stats.median_test`` computes Mood's median test. The new function ``scipy.stats.combine_pvalues`` implements Fisher's and Stouffer's methods for combining p-values. ``scipy.stats.describe`` returns a namedtuple rather than a tuple, allowing users to access results by index or by name. Deprecated features =================== The ``scipy.weave`` module is deprecated. It was the only module never ported to Python 3.x, and is not recommended to be used for new code - use Cython instead. In order to support existing code, ``scipy.weave`` has been packaged separately: `https://github.com/scipy/weave`_. It is a pure Python package, and can easily be installed with ``pip install weave``. ``scipy.special.bessel_diff_formula`` is deprecated. It is a private function, and therefore will be removed from the public API in a following release. Backwards incompatible changes ============================== scipy.ndimage - - ------------- The functions ``scipy.ndimage.minimum_positions``, ``scipy.ndimage.maximum_positions`` and ``scipy.ndimage.extrema`` return positions as ints instead of floats. scipy.integrate - - --------------- The format of banded Jacobians in ``scipy.integrate.ode`` solvers is changed. Note that the previous documentation of this feature was erroneous. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRyaf8ACgkQ6BQxb7O0pWC7XQCeNtdJD4ZNDXvFeNFs7N3KjQn6 8QkAoK3pFmhMrTwCrgkusl+fRNMboN2r =WSpM -----END PGP SIGNATURE-----

6 16

Re: [SciPy-Dev] [Numpy-discussion] Scipy 0.15.0 beta 1 release
by David Cournapeau 25 Nov '14

25 Nov '14

On Tue, Nov 25, 2014 at 6:10 PM, Sturla Molden <sturla.molden(a)gmail.com> wrote: > David Cournapeau <cournape(a)gmail.com> wrote: > > Shall we consider <a > > href="https://github.com/scipy/scipy/issues/4168"> > https://github.com/scipy/scipy/issues/4168</a> > > to be a > > blocker (the issue arises on scipy master as well as 0.14.1) ? > > > > It is really bad, but does anyone know what is really going on? > Yes, it is in the bug report. David > > Which changes to NumPy set this off? > > Sturla > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion(a)scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >

1 0

[Wiki] NumPy / Matlab-Cheatsheet
by Michael Käppler 25 Nov '14

25 Nov '14

Hi guys, thanks for this great cheatsheet you provided on wiki.scipy.org/NumPy_for_Matlab_Users. 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, Michael

3 2

Release schedule
by Pauli Virtanen 23 Nov '14

23 Nov '14

Hi, The 0.14.1 and 0.15.0 releases were delayed a bit. My suggested release plan is below: 0.14.1 - 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. 0.15.0 - branch & beta1: Nov 23 - rc1: Dec 7 - final: Dec 20 The 0.15.0 has a number of issues tagged for it: https://github.com/scipy/scipy/milestones/0.15.0 Pauli

3 5

Re: [SciPy-Dev] removing umfpack wrapper
by Robert Cimrman 23 Nov '14

23 Nov '14

On 11/12/2013 11:22 PM, Ralf Gommers wrote: > On Tue, Nov 12, 2013 at 10:20 AM, Robert Cimrman <cimrman3(a)ntc.zcu.cz>wrote: > >> Hi Ralf, >> >> On 11/10/2013 04:36 PM, Ralf Gommers wrote: >>> Hi all, >>> >>> This is long overdue, but I think it's time to remove the UMFPACK wrapper >>> before the next release. I'd like some feedback on how to do that and to >>> what package (if any) to point existing users. >>> >>> As for why to remove the wrapper, see: >>> https://github.com/scipy/scipy/issues/3002 >>> http://permalink.gmane.org/gmane.comp.python.scientific.user/20451 >>> Short summary: UMFPACK changed from a BSD-compatible license to GPL at >> some >>> point. >>> >>> The deprecation warning in sparse.linalg has been referring people to >>> scikits.umfpack until now, however that package has disappeared >> completely >>> as far as I can tell. I suspect it was in the old scikits svn repo and >> was >>> never moved before that was killed. The alternatives seems to be >> Pysparse ( >> >> I missed that the scikit was lost in transition... >> >> How much work would be to move it to the new site - move from SVN to git, >> and? >> I would be willing to do it, if there is interest. >> > > Hi Robert, I think the moving wouldn't be a lot of work (assuming svn > access can still be arranged). If you'd revive the scikit it's not a > one-time effort though - it's only useful if the code is being maintained > imho. That can still be low effort perhaps, but with reviewing some PRs, > maintenance releases, putting it on pypi, etc. I'd expect at least an hour > a week or so. > > Are there scikits.umfpack users now? Would it make sense to salvage > whatever is useful from the scikit and contribute it to pysparse instead? We are using it in sfepy as the default direct solver. It seems to me that the pysparse interface requires the input matrix to be in the LL (linked list) format, which is unfortunate for us, as we use CSR. The scipy (and former scikit) umfpack wrappers have used CSR, so no copies were necessary. (After all, I have created the original scipy wrappers to be used from sfepy in the first place...) So in case others are not interested in having the scikit, I can see two possible solutions from my perspective: either enhance pysparse interface to allow CSR as well, or move the wrappers to sfepy (which I maintain anyway, but swig -> cython conversion would be needed). Not sure yet which solution I prefer. Cheers, r. > Cheers, > Ralf >> >> Cheers, >> r. >> >>> http://pysparse.sourceforge.net) and PyUBlasExt ( >>> https://pypi.python.org/pypi/PyUblasExt). Scikits.sparse is dead(-ish) >> and >>> doesn't wrap umfpack it looks like. PyUBlasExt has something that looks >>> like a wrapper but for C++ (?). So can we refer people to pysparse? >>> >>> Other question: do we call Pysparse instead of scikits.umfpack when >>> available? And if so, by default or not? Or do we rip out everything that >>> sits under useUmfpack=True? >>> >>> Cheers, >>> Ralf

2 5