Mailman 3 June 2016 - SciPy-Dev

dense output option in integrate.ode
by Evgeni Burovski 20 Feb '17

20 Feb '17

Hi David, Hi Jim, > I am new to SciPy-dev. Will the dense output option in scipy.integrate.ode > become available in 0.17.0? This is a feature already available in the > original FORTAN, but wasn't implemented in the wrapper. If the feature is sent as a pull request against the scipy master branch, the PR is reviewed by the maintainers of the integrate package and merged into master before the release split, then yes, it would be available in 0.17.0. So far I do not see any progress towards it. > I wrote these dense output extensions that you listed: > > https://github.com/jddmartin/scipy/tree/dense_output_from_dopri5_and_dop853 > https://github.com/jddmartin/dense_output_example_usage > > but I didn't issue any pull request to scipy. I sent this message to the > scipy developers list: > http://article.gmane.org/gmane.comp.python.scientific.devel/19635/ > explaining the changes. I was hoping for some feedback before issuing a > pull request. Ah, I see that the email likely fell through the cracks back in April. Sorry about that. You might want to ping that email thread once more or send a pull request on github (or both). <snip> Cheers, Evgeni

3 5

(no subject)
by Nathan Woods 25 Jul '16

25 Jul '16

There have been a number of problems (e.g. GitHub issues #5002, #4831) with the C interface of scipy.integrate.quad since work was done a couple of years ago to allow performance optimizations ( https://github.com/scipy/scipy/commit/f5183a34a959d625c6b534e99df5db7ca49bf…). Specifically, the QuadPack Fortran library does not really accommodate multivariate integrand functions, which leads to all sorts of monkey business in the API to hide that multivariate-ness. This is further complicated by the fact that the QuadPack interface is one of the oldest parts of SciPy and uses the Python C API directly, which many (most?) of us are unfamiliar with. I'd really like to figure out some kind of "good" solution to this. I think that the requirements of the problem are fairly simple: connect the existing scipy.integrate.quad routine to the underlying Fortran code, while allowing users to use compiled function pointers as integrand functions, if they want to (and are willing to put in some effort). I guess that the question here is, what is the best way to go about this? Should we simply find a way to fix the existing interface code? Should we roll back the changes and disallow the use of function pointers in quad? Should we replace the existing API with something else, using Cython or f2py? Should we alter the QuadPack code itself (perhaps by adding a void* argument to the function) to make it more friendly to multivariate functions in general? The current state of affairs bothers me, especially since I was involved in the PR that caused the new problems, but I haven't been able to come up with a good way to fix things yet. I'd love to get some ideas and feedback on how this could be resolved. Nathan Woods

1 1

welcome Nikolay to the core team
by Ralf Gommers 28 Jun '16

28 Jun '16

Hi all, On behalf of the Scipy developers I'd like to welcome Nikolay Mayorov as member of the core dev team. Nikolay started contributing as a GSoC student last year, then he added optimize.lsq_linear/least_squares. Since then he's made many other contributions, for example: optimize.solve_bvp, interpolate.CubicSpline and a nearest neighbor chain algorithm to speed up cluster.linkage. See https://github.com/scipy/scipy/pulls/nmayorov Keep them coming Nikolay! Cheers, Ralf @other-newer-core-devs: if you're wondering if we all agreed on offering Nikolay commit rights, that happened already half a year ago via email (it just took a while before the acceptance came in:)).

7 6

Numpy 1.11.1 release
by Charles R Harris 26 Jun '16

26 Jun '16

Hi All, I'm pleased to announce the release of Numpy 1.11.1. This release supports Python 2.6 - 2.7, and 3.2 - 3.5 and fixes bugs and regressions found in Numpy 1.11.0 as well as making several build related improvements. Wheels for Linux, Windows, and OSX can be found on PyPI. Sources are available on both PyPI and Sourceforge <https://sourceforge.net/projects/numpy/files/NumPy/1.11.1/>. Thanks to all who were involved in this release, and a special thanks to Matthew Brett for his work on the Linux and Windows wheel infrastructure. The following pull requests have been merged: - 7506 BUG: Make sure numpy imports on python 2.6 when nose is unavailable. - 7530 BUG: Floating exception with invalid axis in np.lexsort. - 7535 BUG: Extend glibc complex trig functions blacklist to glibc < 2.18. - 7551 BUG: Allow graceful recovery for no compiler. - 7558 BUG: Constant padding expected wrong type in constant_values. - 7578 BUG: Fix OverflowError in Python 3.x. in swig interface. - 7590 BLD: Fix configparser.InterpolationSyntaxError. - 7597 BUG: Make np.ma.take work on scalars. - 7608 BUG: linalg.norm(): Don't convert object arrays to float. - 7638 BLD: Correct C compiler customization in system_info.py. - 7654 BUG: ma.median of 1d array should return a scalar. - 7656 BLD: Remove hardcoded Intel compiler flag -xSSE4.2. - 7660 BUG: Temporary fix for str(mvoid) for object field types. - 7665 BUG: Fix incorrect printing of 1D masked arrays. - 7670 BUG: Correct initial index estimate in histogram. - 7671 BUG: Boolean assignment no GIL release when transfer needs API. - 7676 BUG: Fix handling of right edge of final histogram bin. - 7680 BUG: Fix np.clip bug NaN handling for Visual Studio 2015. - 7724 BUG: Fix segfaults in np.random.shuffle. - 7731 MAINT: Change mkl_info.dir_env_var from MKL to MKLROOT. - 7737 BUG: Fix issue on OS X with Python 3.x, npymath.ini not installed. The following developers contributed to this release, developers marked with a '+' are first time contributors. - Allan Haldane - Amit Aronovitch+ - Andrei Kucharavy+ - Charles Harris - Eric Wieser+ - Evgeni Burovski - Loïc Estève+ - Mathieu Lamarre+ - Matthew Brett - Matthias Geier - Nathaniel J. Smith - Nikola Forró+ - Ralf Gommers - Ray Donnelly+ - Robert Kern - Sebastian Berg - Simon Conseil - Simon Gibbons - Sorin Sbarnea+ Chuck

1 0

How best to turn JSON into a CSV or Pandas data frame table?
by David Shi 26 Jun '16

26 Jun '16

Which are the best ways to turn a JSON object into a CSV or Pandas data frame table? Looking forward to hearing from you. Regards. David

1 1

Benchmark regression feeds
by Pauli Virtanen 24 Jun '16

24 Jun '16

Hi, In case someone is interested in getting notifications of performance regressions in the Numpy and Scipy benchmarks, this is available as Atom feeds at: https://pv.github.io/numpy-bench/regressions.xml https://pv.github.io/scipy-bench/regressions.xml -- Pauli Virtanen

1 0

Re: [SciPy-Dev] [Numpy-discussion] scipy 0.18 release candidate 1
by Ralf Gommers 24 Jun '16

24 Jun '16

On Tue, Jun 21, 2016 at 7:29 PM, Evgeni Burovski <evgeny.burovskiy(a)gmail.com > wrote: > On Tue, Jun 21, 2016 at 4:27 AM, Matthew Brett <matthew.brett(a)gmail.com> > wrote: > > Hi, > > > > On Mon, Jun 20, 2016 at 6:31 AM, Evgeni Burovski > > <evgeny.burovskiy(a)gmail.com> wrote: > >> Hi, > >> > >> I'm pleased to announce the availability of the first release > >> candidate for scipy 0.18.0. > >> Please try this release and report any issues on Github tracker, > >> https://github.com/scipy/scipy, or scipy-dev mailing list. > >> Source tarballs and release notes are available from Github releases, > >> https://github.com/scipy/scipy/releases/tag/v0.18.0rc1 > >> > >> Please note that this is a source-only release. We do not provide > >> Windows binaries for this release. OS X and Linux wheels will be > >> provided for the final release. > >> > >> The current release schedule is > >> > >> 27 June: rc2 (if necessary) > >> 11 July: final release > >> > >> Thanks to everyone who contributed to this release! > >> > >> Cheers, > >> > >> Evgeni > >> > >> > >> A part of the release notes follows: > >> > >> > >> > >> ========================== > >> SciPy 0.18.0 Release Notes > >> ========================== > >> > >> .. note:: Scipy 0.18.0 is not released yet! > >> > >> .. contents:: > >> > >> SciPy 0.18.0 is the culmination of 6 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.19.x branch, and on adding > >> new features on the master branch. > >> > >> This release requires Python 2.7 or 3.4-3.5 and NumPy 1.7.1 or greater. > > > > Thanks a lot for taking on the release. > > > > I put the manylinux1 and OSX wheel building into a single repo to test > > 64- and 32-bit linux wheels. There's a test run with the 0.18.0rc1 > > code here: > > > > https://travis-ci.org/MacPython/scipy-wheels/builds/139084454 > > > > For Python 3 I am getting these errors: > > https://github.com/scipy/scipy/issues/6292 > > > > For all 32-bit builds I am getting this error: > > https://github.com/scipy/scipy/issues/6093 > > > > For the Python 3 32-bit builds I am also getting this error: > > https://github.com/scipy/scipy/issues/6101 > > > > For the builds that succeeded without failure (all OSX and manylinux1 > > for 64 bit Python 2.7), you can test with: > > > > python -m pip install -U pip > > pip install --trusted-host wheels.scipy.org -f > > https://wheels.scipy.org -U --pre scipy > > > > Thanks again, sorry for the tiring news, > > > > Matthew > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion(a)scipy.org > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > Thanks Matthew for testing and reporting these! > Indeed, thanks! Would it make sense to put these wheels on PyPI, so people can test them with ``pip install scipy --pre``? We do that with Numpy wheels as well now. Ralf

6 12

Re: [SciPy-Dev] [scipy/scipy] 0.18.0 release candidate 1
by Andrew Nelson 22 Jun '16

22 Jun '16

The release candidate passes all the tests on my machine. OSX 10.9.5 python 3.4.4 (conda) numpy 1.12.0.dev0+6ab89b8 On 20 June 2016 at 23:17, Evgeni Burovski <notifications(a)github.com> wrote: > This is the first release candidate for scipy 0.18.0. See > https://github.com/scipy/scipy/blob/maintenance/0.18.x/doc/release/0.18.0-n… > for the release notes. > > Please note that this is a source-only release. > > If no issues are reported for this release, it will become the final > 0.18.0 release. Issues can be reported via Github or on the scipy-dev > mailing list (see http://scipy.org/scipylib/mailing-lists.html). > > — > You are receiving this because you are subscribed to this thread. > View it on GitHub <https://github.com/scipy/scipy/releases/tag/v0.18.0rc1> > or mute the thread > <https://github.com/notifications/unsubscribe/AAq51hqL8MQFRNKYjrOpB7T9SgFI98…> > . > -- _____________________________________ Dr. Andrew Nelson _____________________________________

2 1

scipy 0.18 release candidate 1
by Evgeni Burovski 21 Jun '16

21 Jun '16

Hi, I'm pleased to announce the availability of the first release candidate for scipy 0.18.0. Please try this release and report any issues on Github tracker, https://github.com/scipy/scipy, or scipy-dev mailing list. Source tarballs and release notes are available from Github releases, https://github.com/scipy/scipy/releases/tag/v0.18.0rc1 Please note that this is a source-only release. We do not provide Windows binaries for this release. OS X and Linux wheels will be provided for the final release. The current release schedule is 27 June: rc2 (if necessary) 11 July: final release Thanks to everyone who contributed to this release! Cheers, Evgeni A part of the release notes follows: ========================== SciPy 0.18.0 Release Notes ========================== .. note:: Scipy 0.18.0 is not released yet! .. contents:: SciPy 0.18.0 is the culmination of 6 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.19.x branch, and on adding new features on the master branch. This release requires Python 2.7 or 3.4-3.5 and NumPy 1.7.1 or greater. Highlights of this release include: - - A new ODE solver for two-point boundary value problems, `scipy.optimize.solve_bvp`. - - A new class, `CubicSpline`, for cubic spline interpolation of data. - - N-dimensional tensor product polynomials, `scipy.interpolate.NdPPoly`. - - Spherical Voronoi diagrams, `scipy.spatial.SphericalVoronoi`. - - Support for discrete-time linear systems, `scipy.signal.dlti`. New features ============ `scipy.integrate` improvements - ------------------------------ A solver of two-point boundary value problems for ODE systems has been implemented in `scipy.integrate.solve_bvp`. The solver allows for non-separated boundary conditions, unknown parameters and certain singular terms. It finds a C1 continious solution using a fourth-order collocation algorithm. `scipy.interpolate` improvements - -------------------------------- Cubic spline interpolation is now available via `scipy.interpolate.CubicSpline`. This class represents a piecewise cubic polynomial passing through given points and C2 continuous. It is represented in the standard polynomial basis on each segment. A representation of n-dimensional tensor product piecewise polynomials is available as the `scipy.interpolate.NdPPoly` class. Univariate piecewise polynomial classes, `PPoly` and `Bpoly`, can now be evaluated on periodic domains. Use ``extrapolate="periodic"`` keyword argument for this. `scipy.fftpack` improvements - ---------------------------- `scipy.fftpack.next_fast_len` function computes the next "regular" number for FFTPACK. Padding the input to this length can give significant performance increase for `scipy.fftpack.fft`. `scipy.signal` improvements - --------------------------- Resampling using polyphase filtering has been implemented in the function `scipy.signal.resample_poly`. This method upsamples a signal, applies a zero-phase low-pass FIR filter, and downsamples using `scipy.signal.upfirdn` (which is also new in 0.18.0). This method can be faster than FFT-based filtering provided by `scipy.signal.resample` for some signals. `scipy.signal.firls`, which constructs FIR filters using least-squares error minimization, was added. `scipy.signal.sosfiltfilt`, which does forward-backward filtering like `scipy.signal.filtfilt` but for second-order sections, was added. Discrete-time linear systems ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ `scipy.signal.dlti` provides an implementation of discrete-time linear systems. Accordingly, the `StateSpace`, `TransferFunction` and `ZerosPolesGain` classes have learned a the new keyword, `dt`, which can be used to create discrete-time instances of the corresponding system representation. `scipy.sparse` improvements - --------------------------- The functions `sum`, `max`, `mean`, `min`, `transpose`, and `reshape` in `scipy.sparse` have had their signatures augmented with additional arguments and functionality so as to improve compatibility with analogously defined functions in `numpy`. Sparse matrices now have a `count_nonzero` method, which counts the number of nonzero elements in the matrix. Unlike `getnnz()` and ``nnz`` propety, which return the number of stored entries (the length of the data attribute), this method counts the actual number of non-zero entries in data. `scipy.optimize` improvements - ----------------------------- The implementation of Nelder-Mead minimization, `scipy.minimize(..., method="Nelder-Mead")`, obtained a new keyword, `initial_simplex`, which can be used to specify the initial simplex for the optimization process. Initial step size selection in CG and BFGS minimizers has been improved. We expect that this change will improve numeric stability of optimization in some cases. See pull request gh-5536 for details. Handling of infinite bounds in SLSQP optimization has been improved. We expect that this change will improve numeric stability of optimization in the some cases. See pull request gh-6024 for details. A large suite of global optimization benchmarks has been added to ``scipy/benchmarks/go_benchmark_functions``. See pull request gh-4191 for details. Nelder-Mead and Powell minimization will now only set defaults for maximum iterations or function evaluations if neither limit is set by the caller. In some cases with a slow converging function and only 1 limit set, the minimization may continue for longer than with previous versions and so is more likely to reach convergence. See issue gh-5966. `scipy.stats` improvements - -------------------------- Trapezoidal distribution has been implemented as `scipy.stats.trapz`. Skew normal distribution has been implemented as `scipy.stats.skewnorm`. Burr type XII distribution has been implemented as `scipy.stats.burr12`. Three- and four-parameter kappa distributions have been implemented as `scipy.stats.kappa3` and `scipy.stats.kappa4`, respectively. New `scipy.stats.iqr` function computes the interquartile region of a distribution. Random matrices ~~~~~~~~~~~~~~~ `scipy.stats.special_ortho_group` and `scipy.stats.ortho_group` provide generators of random matrices in the SO(N) and O(N) groups, respectively. They generate matrices in the Haar distribution, the only uniform distribution on these group manifolds. `scipy.stats.random_correlation` provides a generator for random correlation matrices, given specified eigenvalues. `scipy.linalg` improvements - --------------------------- `scipy.linalg.svd` gained a new keyword argument, ``lapack_driver``. Available drivers are ``gesdd`` (default) and ``gesvd``. `scipy.linalg.lapack.ilaver` returns the version of the LAPACK library SciPy links to. `scipy.spatial` improvements - ---------------------------- Boolean distances, `scipy.spatial.pdist`, have been sped up. Improvements vary by the function and the input size. In many cases, one can expect a speed-up of x2--x10. New class `scipy.spatial.SphericalVoronoi` constructs Voronoi diagrams on the surface of a sphere. See pull request gh-5232 for details. `scipy.cluster` improvements - ---------------------------- A new clustering algorithm, the nearest neighbor chain algorithm, has been implemented for `scipy.cluster.hierarchy.linkage`. As a result, one can expect a significant algorithmic improvement (:math:`O(N^2)` instead of :math:`O(N^3)`) for several linkage methods. `scipy.special` improvements - ---------------------------- The new function `scipy.special.loggamma` computes the principal branch of the logarithm of the Gamma function. For real input, ``loggamma`` is compatible with `scipy.special.gammaln`. For complex input, it has more consistent behavior in the complex plane and should be preferred over ``gammaln``. Vectorized forms of spherical Bessel functions have been implemented as `scipy.special.spherical_jn`, `scipy.special.spherical_kn`, `scipy.special.spherical_in` and `scipy.special.spherical_yn`. They are recommended for use over ``sph_*`` functions, which are now deprecated. Several special functions have been extended to the complex domain and/or have seen domain/stability improvements. This includes `spence`, `digamma`, `log1p` and several others. Deprecated features =================== The cross-class properties of `lti` systems have been deprecated. The following properties/setters will raise a `DeprecationWarning`: Name - (accessing/setting raises warning) - (setting raises warning) * StateSpace - (`num`, `den`, `gain`) - (`zeros`, `poles`) * TransferFunction (`A`, `B`, `C`, `D`, `gain`) - (`zeros`, `poles`) * ZerosPolesGain (`A`, `B`, `C`, `D`, `num`, `den`) - () Spherical Bessel functions, ``sph_in``, ``sph_jn``, ``sph_kn``, ``sph_yn``, ``sph_jnyn`` and ``sph_inkn`` have been deprecated in favor of `scipy.special.spherical_jn` and ``spherical_kn``, ``spherical_yn``, ``spherical_in``. The following functions in `scipy.constants` are deprecated: ``C2K``, ``K2C``, ``C2F``, ``F2C``, ``F2K`` and ``K2F``. They are superceded by a new function `scipy.constants.convert_temperature` that can perform all those conversions plus to/from the Rankine temperature scale. Backwards incompatible changes ============================== `scipy.optimize` - ---------------- The convergence criterion for ``optimize.bisect``, ``optimize.brentq``, ``optimize.brenth``, and ``optimize.ridder`` now works the same as ``numpy.allclose``. `scipy.ndimage` - --------------- The offset in ``ndimage.iterpolation.affine_transform`` is now consistently added after the matrix is applied, independent of if the matrix is specified using a one-dimensional or a two-dimensional array. `scipy.stats` - ------------- ``stats.ks_2samp`` used to return nonsensical values if the input was not real or contained nans. It now raises an exception for such inputs. Several deprecated methods of `scipy.stats` distributions have been removed: ``est_loc_scale``, ``vecfunc``, ``veccdf`` and ``vec_generic_moment``. Deprecated functions ``nanmean``, ``nanstd`` and ``nanmedian`` have been removed from `scipy.stats`. These functions were deprecated in scipy 0.15.0 in favor of their `numpy` equivalents. A bug in the ``rvs()`` method of the distributions in `scipy.stats` has been fixed. When arguments to ``rvs()`` were given that were shaped for broadcasting, in many cases the returned random samples were not random. A simple example of the problem is ``stats.norm.rvs(loc=np.zeros(10))``. Because of the bug, that call would return 10 identical values. The bug only affected code that relied on the broadcasting of the shape, location and scale parameters. The ``rvs()`` method also accepted some arguments that it should not have. There is a potential for backwards incompatibility in cases where ``rvs()`` accepted arguments that are not, in fact, compatible with broadcasting. An example is stats.gamma.rvs([2, 5, 10, 15], size=(2,2)) The shape of the first argument is not compatible with the requested size, but the function still returned an array with shape (2, 2). In scipy 0.18, that call generates a ``ValueError``. `scipy.io` - ---------- `scipy.io.netcdf` masking now gives precedence to the ``_FillValue`` attribute over the ``missing_value`` attribute, if both are given. Also, data are only treated as missing if they match one of these attributes exactly: values that differ by roundoff from ``_FillValue`` or ``missing_value`` are no longer treated as missing values. `scipy.interpolate` - ------------------- `scipy.interpolate.PiecewisePolynomial` class has been removed. It has been deprecated in scipy 0.14.0, and `scipy.interpolate.BPoly.from_derivatives` serves as a drop-in replacement. Other changes ============= Scipy now uses ``setuptools`` for its builds instead of plain distutils. This fixes usage of ``install_requires='scipy'`` in the ``setup.py`` files of projects that depend on Scipy (see Numpy issue gh-6551 for details). It potentially affects the way that build/install methods for Scipy itself behave though. Please report any unexpected behavior on the Scipy issue tracker. PR `#6240 <https://github.com/scipy/scipy/pull/6240>`__ changes the interpretation of the `maxfun` option in `L-BFGS-B` based routines in the `scipy.optimize` module. An `L-BFGS-B` search consists of multiple iterations, with each iteration consisting of one or more function evaluations. Whereas the old search strategy terminated immediately upon reaching `maxfun` function evaluations, the new strategy allows the current iteration to finish despite reaching `maxfun`. The bundled copy of Qhull in the `scipy.spatial` subpackage has been upgraded to version 2015.2. The bundled copy of ARPACK in the `scipy.sparse.linalg` subpackage has been upgraded to arpack-ng 3.3.0. The bundled copy of SuperLU in the `scipy.sparse` subpackage has been upgraded to version 5.1.1. Authors ======= * @endolith * @yanxun827 + * @kleskjr + * @MYheavyGo + * @solarjoe + * Gregory Allen + * Gilles Aouizerate + * Tom Augspurger + * Henrik Bengtsson + * Felix Berkenkamp * Per Brodtkorb * Lars Buitinck * Daniel Bunting + * Evgeni Burovski * CJ Carey * Tim Cera * Grey Christoforo + * Robert Cimrman * Philip DeBoer + * Yves Delley + * Dávid Bodnár + * Ion Elberdin + * Gabriele Farina + * Yu Feng * Andrew Fowlie + * Joseph Fox-Rabinovitz * Simon Gibbons + * Neil Girdhar + * Kolja Glogowski + * Christoph Gohlke * Ralf Gommers * Todd Goodall + * Johnnie Gray + * Alex Griffing * Olivier Grisel * Thomas Haslwanter + * Michael Hirsch + * Derek Homeier * Golnaz Irannejad + * Marek Jacob + * InSuk Joung + * Tetsuo Koyama + * Eugene Krokhalev + * Eric Larson * Denis Laxalde * Antony Lee * Jerry Li + * Henry Lin + * Nelson Liu + * Loïc Estève * Lei Ma + * Osvaldo Martin + * Stefano Martina + * Nikolay Mayorov * Matthieu Melot + * Sturla Molden * Eric Moore * Alistair Muldal + * Maniteja Nandana * Tavi Nathanson + * Andrew Nelson * Joel Nothman * Behzad Nouri * Nikolai Nowaczyk + * Juan Nunez-Iglesias + * Ted Pudlik * Eric Quintero * Yoav Ram * Jonas Rauber + * Tyler Reddy + * Juha Remes * Garrett Reynolds + * Ariel Rokem + * Fabian Rost + * Bill Sacks + * Jona Sassenhagen + * Marcello Seri + * Sourav Singh + * Martin Spacek + * Søren Fuglede Jørgensen + * Bhavika Tekwani + * Martin Thoma + * Sam Tygier + * Meet Udeshi + * Utkarsh Upadhyay * Bram Vandekerckhove + * Sebastián Vanrell + * Ze Vinicius + * Pauli Virtanen * Stefan van der Walt * Warren Weckesser * Jakub Wilk + * Josh Wilson * Phillip J. Wolfram + * Nathan Woods * Haochen Wu * G Young + A total of 99 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.

2 1

maintenance/0.18.x tagged
by Evgeni Burovski 20 Jun '16

20 Jun '16

Hi, 0.18.x has been tagged and master is now open for 0.19.0 development. I'll upload the source tarballs to GH releases shortly. Cheers, Evgeni

1 0