[Numpy-discussion] ANN: scipy 0.17.0 release

[Evgeni Burovski]

Hi,

On behalf of the Scipy development team I am pleased to announce the
availability of Scipy 0.17.0. This release contains several new features,
detailed in the release notes below. 101 people contributed to this
release over the course of six months.

This release requires Python 2.6, 2.7 or 3.2-3.4 and NumPy 1.6.2 or
greater. Source tarballs and release notes can be found at
https://github.com/scipy/scipy/releases/tag/v0.17.0.

Thanks to everyone who contributed to this release.

Cheers,

Evgeni


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

==
SciPy 0.17.0 Release Notes
==

.. contents::

SciPy 0.17.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.17.x branch, and on adding
new features on the master branch.

This release requires Python 2.6, 2.7 or 3.2-3.5 and NumPy 1.6.2 or greater.

Release highlights:

- New functions for linear and nonlinear least squares optimization with
  constraints: `scipy.optimize.lsq_linear` and
  `scipy.optimize.least_squares`
- Support for fitting with bounds in `scipy.optimize.curve_fit`.
- Significant improvements to `scipy.stats`, providing many functions with
  better handing of inputs which have NaNs or are empty, improved
  documentation, and consistent behavior between `scipy.stats` and
  `scipy.stats.mstats`.
- Significant performance improvements and new functionality in
  `scipy.spatial.cKDTree`.


New features


`scipy.cluster` improvements
- 

A new function `scipy.cluster.hierarchy.cut_tree`, which determines a cut tree
from a linkage matrix, was added.

`scipy.io` improvements
- ---

`scipy.io.mmwrite` gained support for symmetric sparse matrices.

`scipy.io.netcdf` gained support for masking and scaling data based on data
attributes.

`scipy.optimize` improvements
- -

Linear assignment problem solver


`scipy.optimize.linear_sum_assignment` is a new function for solving the
linear sum assignment problem.  It uses the Hungarian algorithm (Kuhn-Munkres).

Least squares optimization
~~

A new function for *nonlinear* least squares optimization with constraints was
added: `scipy.optimize.least_squares`.  It provides several methods:
Levenberg-Marquardt for unconstrained problems, and two trust-region methods
for constrained ones.  Furthermore it provides different loss functions.
New trust-region methods also handle sparse Jacobians.

A new function for *linear* least squares optimization with constraints was
added: `scipy.optimize.lsq_linear`.  It provides a trust-region method as well
as an implementation of the Bounded-Variable Least-Squares (BVLS) algorithm.

`scipy.optimize.curve_fit` now supports fitting with bounds.

`scipy.signal` improvements
- ---

A ``mode`` keyword was added to `scipy.signal.spectrogram`, to let it return
other spectrograms than power spectral density.

`scipy.stats` improvements
- --

Many functions in `scipy.stats` have gained a ``nan_policy`` keyword, which
allows specifying how to treat input with NaNs in them: propagate the NaNs,
raise an error, or omit the NaNs.

Many functions in `scipy.stats` have been improved to correctly handle input
arrays that are empty or contain infs/nans.

A number of functions with the same name in `scipy.stats` and
`scipy.stats.mstats` were changed to have matching signature and behavior.
See `gh-5474 `__ for details.

`scipy.stats.binom_test` and `scipy.stats.mannwhitneyu` gained a keyword
``alternative``, which allows specifying the hypothesis to test for.
Eventually all hypothesis testing functions will get this keyword.

For methods of many continuous distributions, complex input is now accepted.

Matrix normal distribution has been implemented as `scipy.stats.matrix_normal`.

`scipy.sparse` improvements
- ---

The `axis` keyword was added to sparse norms, `scipy.sparse.linalg.norm`.

`scipy.spatial` improvements
- 

`scipy.spatial.cKDTree` was partly rewritten for improved performance and
several new features were added to it:

- - the ``query_ball_point`` method became significantly faster
- - ``query`` and ``query_ball_point`` gained an ``n_jobs`` keyword for parallel
  execution
- - build and query methods now release the GIL
- - full pickling support
- - support for periodic spaces
- - the ``sparse_distance_matrix`` method can 

Re: [Numpy-discussion] ANN: scipy 0.17.0 release

[Evgeni Burovski]

23.01.2016 22:12 пользователь "Kiko"  написал:
>
> is it python3.5 compatible? your message and github don't say the same.

It is indeed --- thanks for catching it. My typo, my bad.

Evgeni

> 2016-01-23 19:12 GMT+01:00, Charles R Harris :
> > 
> >
> > Congratulations.
> >
> > Chuck
> >
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: scipy 0.17.0 release

[Charles R Harris]

Congratulations.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: scipy 0.17.0 release

[Kiko]

is it python3.5 compatible? your message and github don't say the same.

2016-01-23 19:12 GMT+01:00, Charles R Harris :
> 
>
> Congratulations.
>
> Chuck
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: scipy 0.17.0 release

[Kiko]

BTW, congratulations and thanks for the hard work

2016-01-23 20:12 GMT+01:00, Kiko :
> is it python3.5 compatible? your message and github don't say the same.
>
> 2016-01-23 19:12 GMT+01:00, Charles R Harris :
>> 
>>
>> Congratulations.
>>
>> Chuck
>>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Make as_strided result writeonly

[Juan Nunez-Iglesias]

I've used as_strided before to create an "endless" output array when I
didn't care about the result of an operation, just the side effect. See eg
here
.
So I would certainly like option to remain to get a writeable array. In
general, I'm sceptical about whether the benefits outweigh the costs.

On Sun, Jan 24, 2016 at 9:20 AM, Nathaniel Smith  wrote:

> On Sat, Jan 23, 2016 at 1:25 PM, Sebastian Berg
>  wrote:
> >
> > Hi all,
> >
> > I have just opened a PR, to make as_strided writeonly (as default). The
>
> I think you meant readonly :-)
>
> > reasoning for this change is that an `as_strided` array often have self
> > overlapping memory. However, writing to an array where multiple
> > elements have the identical memory address can be confusing, and the
> > results are typically unpredictable.
> >
> > Considering the danger, the proposal is to add a `readonly=True`. A
> > poweruser (who that function is designed for anyway), could thus still
> > get a writeable array.
> >
> > For the moment, writing to the result would raise a FutureWarning with
> > `readonly="warn"`.
>
> This should just be a deprecation warning, right? (Because switching
> an array from writeable->readonly might cause previously correct code
> to error out, but not to silently start returning different results.)
>
> > Do you agree with this, or would it be a major inconvenience?
>
> AFAIK the only use cases for as_strided involve self-overlap (for
> non-self-overlap you can generally use reshape / indexing / etc. and
> it's much simpler). So +1 from me.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Make as_strided result writeonly

[Sebastian Berg]

Hi all,

I have just opened a PR, to make as_strided writeonly (as default). The
reasoning for this change is that an `as_strided` array often have self
overlapping memory. However, writing to an array where multiple
elements have the identical memory address can be confusing, and the
results are typically unpredictable.

Considering the danger, the proposal is to add a `readonly=True`. A
poweruser (who that function is designed for anyway), could thus still
get a writeable array.

For the moment, writing to the result would raise a FutureWarning with
`readonly="warn"`.

Do you agree with this, or would it be a major inconvenience?

- Sebastian


signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Make as_strided result writeonly

[Nathaniel Smith]

On Sat, Jan 23, 2016 at 1:25 PM, Sebastian Berg
 wrote:
>
> Hi all,
>
> I have just opened a PR, to make as_strided writeonly (as default). The

I think you meant readonly :-)

> reasoning for this change is that an `as_strided` array often have self
> overlapping memory. However, writing to an array where multiple
> elements have the identical memory address can be confusing, and the
> results are typically unpredictable.
>
> Considering the danger, the proposal is to add a `readonly=True`. A
> poweruser (who that function is designed for anyway), could thus still
> get a writeable array.
>
> For the moment, writing to the result would raise a FutureWarning with
> `readonly="warn"`.

This should just be a deprecation warning, right? (Because switching
an array from writeable->readonly might cause previously correct code
to error out, but not to silently start returning different results.)

> Do you agree with this, or would it be a major inconvenience?

AFAIK the only use cases for as_strided involve self-overlap (for
non-self-overlap you can generally use reshape / indexing / etc. and
it's much simpler). So +1 from me.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] PR #7090: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

[Joseph Fox-Rabinovitz]

As someone very new to relatively large projects such as numpy, I was
wondering how the process works. I have announced my PR with some
small enhancements to the histogram function and fixed up all of the
comments that were made (originally to PR 7083). What happens next?
All I have to go on is
http://docs.scipy.org/doc/numpy-1.10.1/dev/gitwash/development_workflow.html#asking-for-your-changes-to-be-merged-with-the-main-repo,
but that does not go into detail about what happens after the point I
have already reached.

Regards,

-Joe


On Thu, Jan 21, 2016 at 3:37 PM, Joseph Fox-Rabinovitz
 wrote:
> Due to a mistake I made in my branch structure, I have replaced this
> PR with #7090: https://github.com/numpy/numpy/pull/7090. All of the
> changes and fixes so far are squashed into the new request.
>
> -Joe
>
> On Thu, Jan 21, 2016 at 1:51 AM, Joseph Fox-Rabinovitz
>  wrote:
>> Please let me know if there is anything wrong or missing. I have added
>> a couple of estimators that I find useful sometimes.
>>
>> -Joe
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion