Hi, I'm pleased to announce the availability of the first beta release of Scipy0.14.0. Please try this beta and report any issues on the scipy-dev mailing list. Source tarballs, binaries and the full release notes can be found at http://sourceforge.net/projects/scipy/files/scipy/0.14.0b1/. Part of the release notes copied below. A big thank you to everyone who contributed to this release! Ralf SciPy 0.14.0 is the culmination of 8 months of hard work. It contains many 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.14.x branch, and on adding new features on the master branch. This release requires Python 2.6, 2.7 or 3.2-3.4 and NumPy 1.5.1 or greater. New features ============ ``scipy.interpolate`` improvements ---------------------------------- A new wrapper function `scipy.interpolate.interpn` for interpolation on regular grids has been added. `interpn` supports linear and nearest-neighbor interpolation in arbitrary dimensions and spline interpolation in two dimensions. Faster implementations of piecewise polynomials in power and Bernstein polynomial bases have been added as `scipy.interpolate.PPoly` and `scipy.interpolate.BPoly`. New users should use these in favor of `scipy.interpolate.PiecewisePolynomial`. `scipy.interpolate.interp1d` now accepts non-monotonic inputs and sorts them. If performance is critical, sorting can be turned off by using the new ``assume_sorted`` keyword. Functionality for evaluation of bivariate spline derivatives in ``scipy.interpolate`` has been added. The new class `scipy.interpolate.Akima1DInterpolator` implements the piecewise cubic polynomial interpolation scheme devised by H. Akima. Functionality for fast interpolation on regular, unevenly spaced grids in arbitrary dimensions has been added as `scipy.interpolate.RegularGridInterpolator` . ``scipy.linalg`` improvements ----------------------------- The new function `scipy.linalg.dft` computes the matrix of the discrete Fourier transform. A condition number estimation function for matrix exponential, `scipy.linalg.expm_cond`, has been added. ``scipy.optimize`` improvements ------------------------------- A set of benchmarks for optimize, which can be run with ``optimize.bench()``, has been added. `scipy.optimize.curve_fit` now has more controllable error estimation via the ``absolute_sigma`` keyword. Support for passing custom minimization methods to ``optimize.minimize()`` and ``optimize.minimize_scalar()`` has been added, currently useful especially for combining ``optimize.basinhopping()`` with custom local optimizer routines. ``scipy.stats`` improvements ---------------------------- A new class `scipy.stats.multivariate_normal` with functionality for multivariate normal random variables has been added. A lot of work on the ``scipy.stats`` distribution framework has been done. Moment calculations (skew and kurtosis mainly) are fixed and verified, all examples are now runnable, and many small accuracy and performance improvements for individual distributions were merged. The new function `scipy.stats.anderson_ksamp` computes the k-sample Anderson-Darling test for the null hypothesis that k samples come from the same parent population. ``scipy.signal`` improvements ----------------------------- ``scipy.signal.iirfilter`` and related functions to design Butterworth, Chebyshev, elliptical and Bessel IIR filters now all use pole-zero ("zpk") format internally instead of using transformations to numerator/denominator format. The accuracy of the produced filters, especially high-order ones, is improved significantly as a result. The new function `scipy.signal.vectorstrength` computes the vector strength, a measure of phase synchrony, of a set of events. ``scipy.special`` improvements ------------------------------ The functions `scipy.special.boxcox` and `scipy.special.boxcox1p`, which compute the Box-Cox transformation, have been added. ``scipy.sparse`` improvements ----------------------------- - Significant performance improvement in CSR, CSC, and DOK indexing speed. - When using Numpy >= 1.9 (to be released in MM 2014), sparse matrices function correctly when given to arguments of ``np.dot``, ``np.multiply`` and other ufuncs. With earlier Numpy and Scipy versions, the results of such operations are undefined and usually unexpected. - Sparse matrices are no longer limited to ``2^31`` nonzero elements. They automatically switch to using 64-bit index data type for matrices containing more elements. User code written assuming the sparse matrices use int32 as the index data type will continue to work, except for such large matrices. Code dealing with larger matrices needs to accept either int32 or int64 indices. Deprecated features =================== ``anneal`` ---------- The global minimization function `scipy.optimize.anneal` is deprecated. All users should use the `scipy.optimize.basinhopping` function instead. ``scipy.stats`` --------------- ``randwcdf`` and ``randwppf`` functions are deprecated. All users should use distribution-specific ``rvs`` methods instead. Probability calculation aliases ``zprob``, ``fprob`` and ``ksprob`` are deprecated. Use instead the ``sf`` methods of the corresponding distributions or the ``special`` functions directly. ``scipy.interpolate`` --------------------- ``PiecewisePolynomial`` class is deprecated. Backwards incompatible changes ============================== scipy.special.lpmn ------------------ ``lpmn`` no longer accepts complex-valued arguments. A new function ``clpmn`` with uniform complex analytic behavior has been added, and it should be used instead. scipy.sparse.linalg ------------------- Eigenvectors in the case of generalized eigenvalue problem are normalized to unit vectors in 2-norm, rather than following the LAPACK normalization convention. The deprecated UMFPACK wrapper in ``scipy.sparse.linalg`` has been removed due to license and install issues. If available, ``scikits.umfpack`` is still used transparently in the ``spsolve`` and ``factorized`` functions. Otherwise, SuperLU is used instead in these functions. scipy.stats ----------- The deprecated functions ``glm``, ``oneway`` and ``cmedian`` have been removed from ``scipy.stats``. ``stats.scoreatpercentile`` now returns an array instead of a list of percentiles. scipy.interpolate ----------------- The API for computing derivatives of a monotone piecewise interpolation has changed: if `p` is a ``PchipInterpolator`` object, `p.derivative(der)` returns a callable object representing the derivative of `p`. For in-place derivatives use the second argument of the `__call__` method: `p(0.1, der=2)` evaluates the second derivative of `p` at `x=0.1`. The method `p.derivatives` has been removed. Authors ======= * Marc Abramowitz + * andbo + * Vincent Arel-Bundock + * Petr Baudis + * Max Bolingbroke * François Boulogne * Matthew Brett * Lars Buitinck * Evgeni Burovski * CJ Carey + * Thomas A Caswell + * Pawel Chojnacki + * Phillip Cloud + * Stefano Costa + * David Cournapeau * Dapid + * Matthieu Dartiailh + * Christoph Deil + * Jörg Dietrich + * endolith * Francisco de la Peña + * Ben FrantzDale + * Jim Garrison + * André Gaul * Christoph Gohlke * Ralf Gommers * Robert David Grant * Alex Griffing * Blake Griffith * Yaroslav Halchenko * Andreas Hilboll * Kat Huang * Gert-Ludwig Ingold * jamestwebber + * Dorota Jarecka + * Todd Jennings + * Thouis (Ray) Jones * Juan Luis Cano Rodríguez * ktritz + * Jacques Kvam + * Eric Larson + * Justin Lavoie + * Denis Laxalde * Jussi Leinonen + * lemonlaug + * Tim Leslie * Alain Leufroy + * George Lewis + * Max Linke + * Brandon Liu + * Benny Malengier + * Matthias Kümmerer + * Cimarron Mittelsteadt + * Eric Moore * Andrew Nelson + * Niklas Hambüchen + * Joel Nothman + * Clemens Novak * Emanuele Olivetti + * Stefan Otte + * peb + * Josef Perktold * pjwerneck * Andrew Sczesnak + * poolio * Jérôme Roy + * Carl Sandrock + * Shauna + * Fabrice Silva * Daniel B. Smith * Patrick Snape + * Thomas Spura + * Jacob Stevenson * Julian Taylor * Tomas Tomecek * Richard Tsai * Joris Vankerschaver + * Pauli Virtanen * Warren Weckesser A total of 78 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete.
Hi, I just built some scipy b1 OSX wheels, and put them here: https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp27-none-maco... https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp33-cp33m-mac... As usual, you need a recent copy of pip, setuptools: pip install --upgrade pip Then download and: pip install scipy-0.14.0b1-cp27-none-macosx_10_6_intel.whl (for example). Feedback welcome. I built these on 10.9 and tested on a completely bare 10.6 machine. I'll automate the build more, but for now the instructions are here: https://github.com/matthew-brett/delocate I'd like to volunteer to build wheels for the next pre-release. Ralf - would you mind giving me permission to upload? Cheers, Matthew
On Sat, Mar 22, 2014 at 8:09 AM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
I just built some scipy b1 OSX wheels, and put them here:
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp27-none-maco...
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp33-cp33m-mac...
As usual, you need a recent copy of pip, setuptools:
pip install --upgrade pip
Then download and:
pip install scipy-0.14.0b1-cp27-none-macosx_10_6_intel.whl
(for example). Feedback welcome.
I built these on 10.9 and tested on a completely bare 10.6 machine. I'll automate the build more, but for now the instructions are here:
Nice. This reminded me of https://github.com/scipy/scipy/issues/2829 again. Imho we should drop support for <Win7 in the official installers and use a similar approach with private dlls for Windows.
I'd like to volunteer to build wheels for the next pre-release. Ralf - would you mind giving me permission to upload?
Great! Done for both SF and (for final releases) PyPi. Ralf
Hi, On Sun, Mar 23, 2014 at 2:55 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Mar 22, 2014 at 8:09 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I just built some scipy b1 OSX wheels, and put them here:
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp27-none-maco...
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp33-cp33m-mac...
As usual, you need a recent copy of pip, setuptools:
pip install --upgrade pip
Then download and:
pip install scipy-0.14.0b1-cp27-none-macosx_10_6_intel.whl
(for example). Feedback welcome.
I built these on 10.9 and tested on a completely bare 10.6 machine. I'll automate the build more, but for now the instructions are here:
Nice.
This reminded me of https://github.com/scipy/scipy/issues/2829 again. Imho we should drop support for <Win7 in the official installers and use a similar approach with private dlls for Windows.
That seems reasonable to me. Is there any way of estimating how many Windows XP users are downloading the .exe installers these days? David C - what do you think about something like this?
I'd like to volunteer to build wheels for the next pre-release. Ralf - would you mind giving me permission to upload?
Great! Done for both SF and (for final releases) PyPi.
Thanks a lot, Matthew
On Mon, Mar 24, 2014 at 11:31 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Sun, Mar 23, 2014 at 2:55 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Mar 22, 2014 at 8:09 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I just built some scipy b1 OSX wheels, and put them here:
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp27-none-maco...
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp33-cp33m-mac...
As usual, you need a recent copy of pip, setuptools:
pip install --upgrade pip
Then download and:
pip install scipy-0.14.0b1-cp27-none-macosx_10_6_intel.whl
(for example). Feedback welcome.
I built these on 10.9 and tested on a completely bare 10.6 machine. I'll automate the build more, but for now the instructions are here:
Nice.
This reminded me of https://github.com/scipy/scipy/issues/2829 again. Imho we should drop support for <Win7 in the official installers and use a similar approach with private dlls for Windows.
That seems reasonable to me. Is there any way of estimating how many Windows XP users are downloading the .exe installers these days?
David C - what do you think about something like this?
Dropping support for XP is fine by me as long as we are only talking about the official installers (e.g. building numpy with MSVC should stilll work on XP) . It is only a data point, but @ Enthought, we have quite a few customers on XP. I would not go as far as saying that's the most common version of windows, but that's not the least common either. I would also reiterate my plea to avoid any PATH or pre-loading. Every library that does this has been a constant source of pain in my experience: embedding, integration with large 3rd party framework (especially the ones using multi-threading), etc... We remove it in every library we support @ Enthought (e.g. pytables 2.x) IMO, installing the mingw DLLs is the least bad option. David
I'd like to volunteer to build wheels for the next pre-release. Ralf - would you mind giving me permission to upload?
Great! Done for both SF and (for final releases) PyPi.
Thanks a lot,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
+1 for keeping the XP .exe installers. I don't know about others, but I use XP for compiling binaries of my packages that link against numpy for my windows users. -Robert On Tue, Mar 25, 2014 at 2:32 AM, Gael Varoquaux < gael.varoquaux@normalesup.org> wrote:
On Tue, Mar 25, 2014 at 08:08:12AM +0000, David Cournapeau wrote:
I would also reiterate my plea to avoid any PATH or pre-loading.
+1
G _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Tue, Mar 25, 2014 at 2:08 AM, David Cournapeau <cournape@gmail.com>wrote:
On Mon, Mar 24, 2014 at 11:31 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Sun, Mar 23, 2014 at 2:55 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Mar 22, 2014 at 8:09 AM, Matthew Brett <matthew.brett@gmail.com
wrote:
Hi,
I just built some scipy b1 OSX wheels, and put them here:
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp27-none-maco...
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp33-cp33m-mac...
As usual, you need a recent copy of pip, setuptools:
pip install --upgrade pip
Then download and:
pip install scipy-0.14.0b1-cp27-none-macosx_10_6_intel.whl
(for example). Feedback welcome.
I built these on 10.9 and tested on a completely bare 10.6 machine. I'll automate the build more, but for now the instructions are here:
Nice.
This reminded me of https://github.com/scipy/scipy/issues/2829 again. Imho we should drop support for <Win7 in the official installers and use a similar approach with private dlls for Windows.
That seems reasonable to me. Is there any way of estimating how many Windows XP users are downloading the .exe installers these days?
David C - what do you think about something like this?
Dropping support for XP is fine by me as long as we are only talking about the official installers (e.g. building numpy with MSVC should stilll work on XP) . It is only a data point, but @ Enthought, we have quite a few customers on XP. I would not go as far as saying that's the most common version of windows, but that's not the least common either.
When my dad retired from Lincoln Labs two years ago, the lab was still using XP. <snip> Chuck
Hi, On Tue, Mar 25, 2014 at 1:08 AM, David Cournapeau <cournape@gmail.com> wrote:
On Mon, Mar 24, 2014 at 11:31 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Sun, Mar 23, 2014 at 2:55 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Mar 22, 2014 at 8:09 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I just built some scipy b1 OSX wheels, and put them here:
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp27-none-maco...
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp33-cp33m-mac...
As usual, you need a recent copy of pip, setuptools:
pip install --upgrade pip
Then download and:
pip install scipy-0.14.0b1-cp27-none-macosx_10_6_intel.whl
(for example). Feedback welcome.
I built these on 10.9 and tested on a completely bare 10.6 machine. I'll automate the build more, but for now the instructions are here:
Nice.
This reminded me of https://github.com/scipy/scipy/issues/2829 again. Imho we should drop support for <Win7 in the official installers and use a similar approach with private dlls for Windows.
That seems reasonable to me. Is there any way of estimating how many Windows XP users are downloading the .exe installers these days?
David C - what do you think about something like this?
Dropping support for XP is fine by me as long as we are only talking about the official installers (e.g. building numpy with MSVC should stilll work on XP) . It is only a data point, but @ Enthought, we have quite a few customers on XP. I would not go as far as saying that's the most common version of windows, but that's not the least common either.
Steam users on 6% [1] "Desktop OS market share" nearly 30% [2] Other estimates somewhere between tending to low end [3]
I would also reiterate my plea to avoid any PATH or pre-loading. Every library that does this has been a constant source of pain in my experience: embedding, integration with large 3rd party framework (especially the ones using multi-threading), etc... We remove it in every library we support @ Enthought (e.g. pytables 2.x)
IMO, installing the mingw DLLs is the least bad option.
Sorry to be ignorant, but you mean copying these into the windows system directories or somewhere else on the system path? Cheers, Matthew [1] http://store.steampowered.com/hwsurvey?platform=pc [2] http://www.netmarketshare.com/ [3] http://en.wikipedia.org/wiki/Usage_share_of_operating_systems
On Tue, Mar 25, 2014 at 11:49 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Tue, Mar 25, 2014 at 1:08 AM, David Cournapeau <cournape@gmail.com> wrote:
On Mon, Mar 24, 2014 at 11:31 PM, Matthew Brett <matthew.brett@gmail.com
wrote:
Hi,
On Sun, Mar 23, 2014 at 2:55 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Mar 22, 2014 at 8:09 AM, Matthew Brett <
matthew.brett@gmail.com>
wrote:
Hi,
I just built some scipy b1 OSX wheels, and put them here:
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp27-none-maco...
https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.14.0b1-cp33-cp33m-mac...
As usual, you need a recent copy of pip, setuptools:
pip install --upgrade pip
Then download and:
pip install scipy-0.14.0b1-cp27-none-macosx_10_6_intel.whl
(for example). Feedback welcome.
I built these on 10.9 and tested on a completely bare 10.6 machine. I'll automate the build more, but for now the instructions are here:
Nice.
This reminded me of https://github.com/scipy/scipy/issues/2829 again. Imho we should drop support for <Win7 in the official installers and use a similar approach with private dlls for Windows.
That seems reasonable to me. Is there any way of estimating how many Windows XP users are downloading the .exe installers these days?
David C - what do you think about something like this?
Dropping support for XP is fine by me as long as we are only talking about the official installers (e.g. building numpy with MSVC should stilll work on XP) . It is only a data point, but @ Enthought, we have quite a few customers on XP. I would not go as far as saying that's the most common version of windows, but that's not the least common either.
Steam users on 6% [1] "Desktop OS market share" nearly 30% [2] Other estimates somewhere between tending to low end [3]
I would also reiterate my plea to avoid any PATH or pre-loading. Every library that does this has been a constant source of pain in my experience: embedding, integration with large 3rd party framework (especially the ones using multi-threading), etc... We remove it in every library we support @ Enthought (e.g. pytables 2.x)
IMO, installing the mingw DLLs is the least bad option.
Sorry to be ignorant, but you mean copying these into the windows system directories or somewhere else on the system path?
god no :) Putting them in sys.exec_prefix would work. I still think it will cause trouble in the future, but that's the least bad option from the other ones. David
Cheers,
Matthew
[1] http://store.steampowered.com/hwsurvey?platform=pc [2] http://www.netmarketshare.com/ [3] http://en.wikipedia.org/wiki/Usage_share_of_operating_systems _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (6)
-
Charles R Harris -
David Cournapeau -
Gael Varoquaux -
Matthew Brett -
Ralf Gommers -
Robert McGibbon