Hi All,
It's time to look forward to branching 1.17.x and the first rc. Please note
of any issues that you think fixing or PRs that should be merged before the
first release. It would also help if some folks would review the release
notes for completeness. I figure the branch should take place in a week or
so.
Chuck

Hi,
There will be a NumPy Community meeting at 12 pm Pacific Time on May 8/
2019. Anyone is welcome to join and edit the work in progress meeting
document: https://hackmd.io/M-ef_Fu5QOOitACnyoO0kQ?view
Best wishes,
Tyler

Hello,
I’m Bhanu, a third year student of Electronics and Computers Engineering.
I’d like to get started with contributing into the NumPy documentation. I’m
a writer who is actively machine learning research as well, and have used
NumPy extensively for my coding assignments and research work.
Thanks,
Bhanu Bhandari

Hi,
I am Oishika Pradhan, a research student at IIIT Hyderabad, India. I am
interested in machine learning and neural networks and hence have used
numpy very regularly in my projects and assignments. This is why I'm
interested in becoming a contributor to this organization. I have some
prior experience in technical documentation.
I am interested in working on the following project:
Improving the structure and content of https://numpy.org/
Please provide pointers on how to get started with this project.
Thanks,
Oishika Pradhan

Hi,
I'm working on building a number of related custom dtypes, and I'm not sure how to set the type and kind fields in PyArray_Descr. I tried using type='V' and choosing a single unused kind for all my dtypes; this mostly worked, except I found that coercions would sometimes treat values of two different dtypes as if they were the same. But not always... sometimes my registered cast functions would be called.
Through trial and error, I've found that if I choose an unused type code for each dtype, coercion seems to work as I expect it to (no coercion unless I've provided a cast). The kind doesn't seem to matter.
I couldn't find any guidance in the docs for how to choose these values. Apologies if I've overlooked something. Could someone please advise me?
More widely, is there some global registry of these codes? Is the number of NumPy dtypes limited to the number of (UTF-8-encodable) chars? It seems like common practice to use dtype.kind in user code. If I use one or more for my custom dtypes, is there any mechanism to ensure they do not collide with others'? Are there any other semantics for either field I should take into account?
Thanks,
Alex

Thanks for the update — this is great stuff!
-CHB
On May 3, 2019, at 3:13 PM, Joe Harrington <jh(a)physics.ucf.edu> wrote:
Just to keep people in the loop, Ralf and I are in discussion with people
at NASA HQ about a funding stream for core development.ï¿½ Ralf has put
together a short description of the development and funding model (5 core
projects, 10-20 core developers each, nearly all volunteer now, how
NumFOCUS fits in, what we hope to establish from NASA vs. from other
agencies, industry, other countries' science entities, etc.).ï¿½ That will
circulate within the agency, to see what can be scraped together.ï¿½
Program managers in NASA's Science Mission Directorate (SMD) gave
quite-positive feedback on how vital the Python ecosystem is to NASA's
mission.ï¿½ We're emphasizing the need for both new functionality and
maintenance (e.g., docs, web site, bug fixing).ï¿½ If this is ultimately
successful, it can be a model for approaching other agencies in the US and
elsewhere.
To Steve's point, regarding how hard it is for Civil Servants to contribute
to OSS (due to NASA's lengthy internal review process for releasing
software), this problem was clearly called out in the Academies report.ï¿½
We proposed some solutions to streamline things.ï¿½ What's needed now is
for NASA Civil Servants to take that report and the relevant white papers
(cited in the report and posted online) to their center's senior
management, and to NASA HQ, and similarly for others in government
agencies.ï¿½ You may wish to start from NASA's (or your agency's) mission,
which includes sharing technology openly to boost the economy, and how you
are encountering unreasonable barriers to that goal.ï¿½ This is mandated by
the National Air and Space Act of 1958.
For example, there is little reason to conduct an export-control review
with lawyers looking at code emerging from a group that has nothing to do
with anything near an export-controlled topic.ï¿½ Universities and
contractors are subject to the same export-control laws as NASA, and they
have not routinely conducted similar reviews of every line of code
released.ï¿½ This has not led to a pattern of export violations.ï¿½
(Whether there is any benefit at all to the export control laws as applied
to software is debatable, since it's usually easy for coders elsewhere to
write the same codes, but the law is the law.)
--jh--
On 5/3/19 12:48 PM, numpy-discussion-request(a)python.org wrote:
Subject:
Re: [Numpy-discussion] grant proposal for core scientific Python projects
(rejected)
From:
Mark Mikofski <mikofski(a)berkeley.edu> <mikofski(a)berkeley.edu>
Date:
5/3/19, 12:47 PM
To:
Discussion of Numerical Python <numpy-discussion(a)python.org>
<numpy-discussion(a)python.org>
Sorry, that last attachment was just a slide show of the topic 3 recording,
here is the full funding opportunity announcement - letter with 200 word
abstract are due May 7th
On Fri, May 3, 2019 at 8:40 AM Mark Mikofski <mikofski(a)berkeley.edu> wrote:
> Hi Ralf, and others,
>
> Sorry for the late notice, but there is are several funding opportunities
> in solar, including one for $350,000 to develop open source software to
> lower soft costs of solar.
> https://eere-exchange.energy.gov/#FoaId45eda43a-e826-4481-ae7a-cc6e8ed4fdae
> ï¿½
> see topic 3.4 specifically in attached PDF - also note to view the
> recording the password is "*Setofoa2019"*ï¿½it's about 30 minutes long.
>
> I know that this is a extremely niche, but as a few others have said, [the
> DOE] grants tend to be very specific, but perhaps we can creatively think
> of ways to channel funds to NumPy and SciPy.
>
> Also there is a cost share that is typically 20%, which would be a
> non-starter for volunteer projects.
>
> But here's an idea, perhaps partnering with a company, like mine (DNV GL)
> who is applying for the grant, and who uses NumPy,and could pay the cost
> share, and then we collaborate on something that is required to complete
> theï¿½project, which is contributed to NumPy (or SciPy) - but we would have
> to figure what we could align on.
>
> Seems like NumFOCUS, Quantsight, or some other company in the OSS space
> could figure out ways to help connect companies, OSS projects, and funding
> opportunities like these, where there's a possibility of alignment and
> mutual benefit?
>
> The full list of funding opportunities is here:
> https://eere-exchange.energy.gov/ï¿½
>
> Best Regards,
> Markï¿½
> ï¿½
>
> On Thu, May 2, 2019 at 11:52 PM Ralf Gommers <ralf.gommers(a)gmail.com>
> wrote:
>
>>
>>
>> On Fri, May 3, 2019 at 3:49 AM Stephen Waterbury <waterbug(a)pangalactic.us>
>> wrote:
>>
>>> P.S.ï¿½ If anyone wants to continue this discussion at SciPy 2019,
>>> I will be there (on my own nickel!ï¿½ ;) ...
>>>
>>
>> Thanks for the input Stephen, and looking forward to see you at SciPy'19!
>>
>> Ralf
>>
>>
>> Steve
>>>
>>> On 5/2/19 9:45 PM, Stephen Waterbury wrote:
>>>
>>> I am a NASA pythonista (for 20+ years ;), but you can now say you know
>>> yet another person at NASA who has no idea this even exists ... :)
>>> Not only do I not know of that, but I know of NASA policies that make
>>> it very difficult for NASA civil servants to contribute to open source
>>> projects -- quite hypocritical, given the amount of open source
>>> code that NASA (like all other large organizations) depends critically
>>> on, but it's a fact.
>>>
>>> Cheers,
>>> Steve Waterbury
>>>
>>> (CLEARLY **NOT** SPEAKING IN ANY OFFICIAL CAPACITY FOR NASA OR
>>> THE U.S. GOVERNMENT AS A WHOLE!ï¿½ Hence the personal email
>>> address. :)
>>>
>>> On 5/2/19 9:31 PM, Chris Barker - NOAA Federal wrote:
>>>
>>> Sounds like this is a NASA specific thing, in which case, I guess
>>> someone at NASA would need to step up.
>>>
>>> Iï¿½m afraid I know no pythonistas at NASA.ï¿½
>>>
>>> But Iï¿½ll poke around NOAA to see if thereï¿½s anything similar.
>>>
>>> -CHB
>>>
>>> On Apr 25, 2019, at 1:04 PM, Ralf Gommers <ralf.gommers(a)gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> On Sat, Apr 20, 2019 at 12:41 PM Ralf Gommers <ralf.gommers(a)gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 18, 2019 at 10:03 PM Joe Harrington <jh(a)physics.ucf.edu>
>>>> wrote:
>>>>
>>>>
>>>>> 3. There's such a thing as a share-in-savings contract at NASA, in
>>>>> which
>>>>> you calculate a savings, such as from avoided costs of licensing IDL
>>>>> or
>>>>> Matlab, and say you'll develop a replacement for that product that
>>>>> costs
>>>>> less, in exchange for a portion of the savings.ï¿½ These are rare and
>>>>> few
>>>>> people know about them, but one presenter to the committee did discuss
>>>>> them and thought they'd be appropriate.ï¿½ I've always felt that we
>>>>> could
>>>>> get a chunk of change this way, and was surprised to find that the
>>>>> approach exists and has a name.ï¿½ About 3 of 4 people I talk to at
>>>>> NASA
>>>>> have no idea this even exists, though, and I haven't pursued it to its
>>>>> logical end to see if it's viable.
>>>>>
>>>>
>>>> I've heard of these. Definitely worth looking into.
>>>>
>>>
>>> It seems to be hard to find any information about these share-in-savings
>>> contracts. The closest thing I found is this:
>>> https://www.federalregister.gov/documents/2018/06/22/2018-13463/nasa-federa…
>>>
>>> It is called "Shared Savings" there, and was replaced last year by
>>> something called "Value Engineering Change Proposal". If anyone can comment
>>> on whether that's the same thing as Joe meant and whether this is worth
>>> following up on, that would be very helpful.
>>>
>>> Cheers,
>>> Ralf
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion(a)python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing listNumPy-Discussion@python.orghttps://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>>
>>> _______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion(a)python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Hi Ralf,
The rejection is disappointing, for sure. Some good ammo for next time
might be the recommendations in this report from the US National
Academies of Science, Engineering, and Medicine:
http://sites.nationalacademies.org/SSB/CurrentProjects/SSB_178892https://www.nap.edu/read/25217/chapter/1#ii
You can download a free PDF if you click around and give them an email
address. There is some code on the cover that might raise a smile.
Lorena Barba, Kelle Cruz, and many other community members contributed,
both as committee members and as white-paper authors. While it's a
report for NASA, the conclusions are strong and there is explicit
support of investment in community resources like numpy, scipy, astropy,
matplotlib, etc. Other agencies are asking similar questions, so I
expect the report to get somewhat of a look at NSF, etc.
A note on the Academies' process: A consensus study report must only
include statements that no single member of the committee objects to,
and the committee generally only includes senior members or people with
a lot of relevant experience. There were stakeholders from some large
modeling shops for whom openness might be a threat to their business
model, in their eyes, and some of the senior members had never
experienced the open-source environment and had bad experiences sharing
software. This made for an interesting social dynamic, and prevented an
all-out recommendation to forcibly open everything immediately. Given
all that, I was ultimately pleased that we got full agreement on the
recommendations we did make.
So, some general thoughts on fundraising, not specific to this proposal:
1. Try NASA. The Administrator for Space Science, Thomas Zurbuchen, is
pushing "open" very hard, given the success of open data in NASA Earth
Science, and its positive impact on the economy in fields like
agriculture and weather forecasting. He paid for the study above. Many
grant programs specifically solicit proposals for open-source tools.
There are also technology development programs in other parts of NASA
than the Science Mission Directorate. Try contacting Dr. Michael New,
who is Zurbuchen's deputy, and could direct you to appropriate programs.
(Please, let's be coordinated and not all deluge the guy.)
2. As suggested in another message, it's often easier to get support for
a specific, targeted item as part of a big project or institute using
that item, such as LSST or the black-hole group. There's a certain way
to wend into those projects, usually originating from within. STScI has
long devoted programmer resources, for example.
3. There's such a thing as a share-in-savings contract at NASA, in which
you calculate a savings, such as from avoided costs of licensing IDL or
Matlab, and say you'll develop a replacement for that product that costs
less, in exchange for a portion of the savings. These are rare and few
people know about them, but one presenter to the committee did discuss
them and thought they'd be appropriate. I've always felt that we could
get a chunk of change this way, and was surprised to find that the
approach exists and has a name. About 3 of 4 people I talk to at NASA
have no idea this even exists, though, and I haven't pursued it to its
logical end to see if it's viable.
4. I mostly lurk here, since being more actively involved in the early
days of numpy docs, so maybe this one has been tried already, or is in
the works. My apologies if so.
Think of development as a product to buy. You could put chunks of
development up for sale, advertise them, and coordinate one or more
groups buying them together. For something like an efficiency boost,
you could price it according to the avoided cost of CPU resources for a
project of a given size (e.g., somewhat below the net present value of
avoided future AWS cycles for the projects buying it). It would be like
buying a custom-built data pipeline, except that once you buy it,
everyone gets it. This might mean scoping out a roadmap of
improvements, packaging them into fundable projects with teams ready to
go, pricing them, advertising them to specific customers and in trade
media and shows, and making sales pitches.
This sounds really weird to us scientists, but it would work just like a
regular purchase for services, which the government and industry are
much more used to doing than donations to open-source projects.
Don't just sell what the customer is buying, sell in the manner that the
customer likes to buy.
5. And, keep trying grant proposals to NSF!
--jh--
On 4/18/19 6:36 AM, Ralf Gommers <ralf.gommers(a)gmail.com> wrote:
>
> A number of core projects (NumPy, SciPy, Matplotlib, Pandas,
> scikit-learn) got together and put in a proposal to NSF for a large 5
> year grant, and it was unfortunately just rejected. We now published
> the proposal, which may be of interest:
> https://figshare.com/articles/Mid-Scale_Research_Infrastructure_-_The_Scien….

Just to keep people in the loop, Ralf and I are in discussion with
people at NASA HQ about a funding stream for core development. Ralf has
put together a short description of the development and funding model (5
core projects, 10-20 core developers each, nearly all volunteer now, how
NumFOCUS fits in, what we hope to establish from NASA vs. from other
agencies, industry, other countries' science entities, etc.). That will
circulate within the agency, to see what can be scraped together.
Program managers in NASA's Science Mission Directorate (SMD) gave
quite-positive feedback on how vital the Python ecosystem is to NASA's
mission. We're emphasizing the need for both new functionality and
maintenance (e.g., docs, web site, bug fixing). If this is ultimately
successful, it can be a model for approaching other agencies in the US
and elsewhere.
To Steve's point, regarding how hard it is for Civil Servants to
contribute to OSS (due to NASA's lengthy internal review process for
releasing software), this problem was clearly called out in the
Academies report. We proposed some solutions to streamline things.
What's needed now is for NASA Civil Servants to take that report and the
relevant white papers (cited in the report and posted online) to their
center's senior management, and to NASA HQ, and similarly for others in
government agencies. You may wish to start from NASA's (or your
agency's) mission, which includes sharing technology openly to boost the
economy, and how you are encountering unreasonable barriers to that
goal. This is mandated by the National Air and Space Act of 1958.
For example, there is little reason to conduct an export-control review
with lawyers looking at code emerging from a group that has nothing to
do with anything near an export-controlled topic. Universities and
contractors are subject to the same export-control laws as NASA, and
they have not routinely conducted similar reviews of every line of code
released. This has not led to a pattern of export violations. (Whether
there is any benefit at all to the export control laws as applied to
software is debatable, since it's usually easy for coders elsewhere to
write the same codes, but the law is the law.)
--jh--
On 5/3/19 12:48 PM, numpy-discussion-request(a)python.org wrote:
> Subject:
> Re: [Numpy-discussion] grant proposal for core scientific Python
> projects (rejected)
> From:
> Mark Mikofski <mikofski(a)berkeley.edu>
> Date:
> 5/3/19, 12:47 PM
>
> To:
> Discussion of Numerical Python <numpy-discussion(a)python.org>
>
>
> Sorry, that last attachment was just a slide show of the topic 3
> recording, here is the full funding opportunity announcement - letter
> with 200 word abstract are due May 7th
>
> On Fri, May 3, 2019 at 8:40 AM Mark Mikofski <mikofski(a)berkeley.edu
> <mailto:mikofski@berkeley.edu>> wrote:
>
> Hi Ralf, and others,
>
> Sorry for the late notice, but there is are several funding
> opportunities in solar, including one for $350,000 to develop open
> source software to lower soft costs of solar.
> https://eere-exchange.energy.gov/#FoaId45eda43a-e826-4481-ae7a-cc6e8ed4fdae
>
> see topic 3.4 specifically in attached PDF - also note to view the
> recording the password is "*Setofoa2019"* it's about 30 minutes long.
>
> I know that this is a extremely niche, but as a few others have
> said, [the DOE] grants tend to be very specific, but perhaps we
> can creatively think of ways to channel funds to NumPy and SciPy.
>
> Also there is a cost share that is typically 20%, which would be a
> non-starter for volunteer projects.
>
> But here's an idea, perhaps partnering with a company, like mine
> (DNV GL) who is applying for the grant, and who uses NumPy,and
> could pay the cost share, and then we collaborate on something
> that is required to complete the project, which is contributed to
> NumPy (or SciPy) - but we would have to figure what we could align on.
>
> Seems like NumFOCUS, Quantsight, or some other company in the OSS
> space could figure out ways to help connect companies, OSS
> projects, and funding opportunities like these, where there's a
> possibility of alignment and mutual benefit?
>
> The full list of funding opportunities is here:
> https://eere-exchange.energy.gov/
>
> Best Regards,
> Mark
>
>
> On Thu, May 2, 2019 at 11:52 PM Ralf Gommers
> <ralf.gommers(a)gmail.com <mailto:ralf.gommers@gmail.com>> wrote:
>
>
>
> On Fri, May 3, 2019 at 3:49 AM Stephen Waterbury
> <waterbug(a)pangalactic.us <mailto:waterbug@pangalactic.us>> wrote:
>
> P.S. If anyone wants to continue this discussion at SciPy
> 2019,
> I will be there (on my own nickel! ;) ...
>
>
> Thanks for the input Stephen, and looking forward to see you
> at SciPy'19!
>
> Ralf
>
>
> Steve
>
> On 5/2/19 9:45 PM, Stephen Waterbury wrote:
>
>> I am a NASA pythonista (for 20+ years ;), but you can now
>> say you know
>> yet another person at NASA who has no idea this even
>> exists ... :)
>> Not only do I not know of that, but I know of NASA
>> policies that make
>> it very difficult for NASA civil servants to contribute
>> to open source
>> projects -- quite hypocritical, given the amount of open
>> source
>> code that NASA (like all other large organizations)
>> depends critically
>> on, but it's a fact.
>>
>> Cheers,
>> Steve Waterbury
>>
>> (CLEARLY **NOT** SPEAKING IN ANY OFFICIAL CAPACITY FOR
>> NASA OR
>> THE U.S. GOVERNMENT AS A WHOLE! Hence the personal email
>> address. :)
>>
>> On 5/2/19 9:31 PM, Chris Barker - NOAA Federal wrote:
>>
>>> Sounds like this is a NASA specific thing, in which
>>> case, I guess someone at NASA would need to step up.
>>>
>>> I’m afraid I know no pythonistas at NASA.
>>>
>>> But I’ll poke around NOAA to see if there’s anything
>>> similar.
>>>
>>> -CHB
>>>
>>> On Apr 25, 2019, at 1:04 PM, Ralf Gommers
>>> <ralf.gommers(a)gmail.com <mailto:ralf.gommers@gmail.com>>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Apr 20, 2019 at 12:41 PM Ralf Gommers
>>>> <ralf.gommers(a)gmail.com
>>>> <mailto:ralf.gommers@gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Apr 18, 2019 at 10:03 PM Joe Harrington
>>>> <jh(a)physics.ucf.edu <mailto:jh@physics.ucf.edu>> wrote:
>>>>
>>>>
>>>> 3. There's such a thing as a share-in-savings
>>>> contract at NASA, in which
>>>> you calculate a savings, such as from avoided
>>>> costs of licensing IDL or
>>>> Matlab, and say you'll develop a replacement
>>>> for that product that costs
>>>> less, in exchange for a portion of the savings.
>>>> These are rare and few
>>>> people know about them, but one presenter to
>>>> the committee did discuss
>>>> them and thought they'd be appropriate. I've
>>>> always felt that we could
>>>> get a chunk of change this way, and was
>>>> surprised to find that the
>>>> approach exists and has a name. About 3 of 4
>>>> people I talk to at NASA
>>>> have no idea this even exists, though, and I
>>>> haven't pursued it to its
>>>> logical end to see if it's viable.
>>>>
>>>>
>>>> I've heard of these. Definitely worth looking into.
>>>>
>>>>
>>>> It seems to be hard to find any information about these
>>>> share-in-savings contracts. The closest thing I found
>>>> is this:
>>>> https://www.federalregister.gov/documents/2018/06/22/2018-13463/nasa-federa…
>>>>
>>>> It is called "Shared Savings" there, and was replaced
>>>> last year by something called "Value Engineering Change
>>>> Proposal". If anyone can comment on whether that's the
>>>> same thing as Joe meant and whether this is worth
>>>> following up on, that would be very helpful.
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>> _______________________________________________
>>>> NumPy-Discussion mailing list
>>>> NumPy-Discussion(a)python.org
>>>> <mailto:NumPy-Discussion@python.org>
>>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion(a)python.org <mailto:NumPy-Discussion@python.org>
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>

Hi all,
The call for proposals for EuroSciPy 2019 is extended to 12 may 2019.
https://pretalx.com/euroscipy-2019/cfp
EuroSciPy 2019 takes place 2-6 September 2019 in Bilbao, Spain. There will be
two days of tutorials, two days of conference, and one day of sprints!
Find us on the web https://www.euroscipy.org/2019/ and on twitter
https://twitter.com/EuroSciPy
Regards,
The EuroSciPy 2019 team

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
On behalf of the SciPy development team I'm pleased to announce
the release candidate SciPy 1.3.0rc1. Please help us test this pre-release.
Sources and binary wheels can be found at:https://pypi.org/project/scipy/
and at:https://github.com/scipy/scipy/releases/tag/v1.3.0rc1
One of a few ways to install the release candidate with pip:
pip install scipy==1.3.0rc1
==========================
SciPy 1.3.0 Release Notes
==========================
Note: Scipy 1.3.0 is not released yet!
SciPy 1.3.0 is the culmination of 5 months of hard work. It contains
many new features, numerous bug-fixes, improved test coverage and better
documentation. There have been some 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. Before upgrading, we recommend that users check that
their own code does not use deprecated SciPy functionality (to do so,
run your code with ``python -Wd`` and check for ``DeprecationWarning`` s).
Our development attention will now shift to bug-fix releases on the
1.3.x branch, and on adding new features on the master branch.
This release requires Python 3.5+ and NumPy 1.13.3 or greater.
For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required.
Highlights of this release
--------------------------
- Three new ``stats`` functions, a rewrite of ``pearsonr``, and an exact
computation of the Kolmogorov-Smirnov two-sample test
- A new Cython API for bounded scalar-function root-finders in `scipy.optimize`
- Substantial ``CSR`` and ``CSC`` sparse matrix indexing performance
improvements
- Added support for interpolation of rotations with continuous angular
rate and acceleration in ``RotationSpline``
New features
============
`scipy.interpolate` improvements
--------------------------------
A new class ``CubicHermiteSpline`` is introduced. It is a piecewise-cubic
interpolator which matches observed values and first derivatives. Existing
cubic interpolators ``CubicSpline``, ``PchipInterpolator`` and
``Akima1DInterpolator`` were made subclasses of ``CubicHermiteSpline``.
`scipy.io` improvements
-----------------------
For the Attribute-Relation File Format (ARFF) `scipy.io.arff.loadarff`
now supports relational attributes.
`scipy.io.mmread` can now parse Matrix Market format files with empty lines.
`scipy.linalg` improvements
---------------------------
Added wrappers for ``?syconv`` routines, which convert a symmetric matrix
given by a triangular matrix factorization into two matrices and vice versa.
`scipy.linalg.clarkson_woodruff_transform` now uses an algorithm that leverages
sparsity. This may provide a 60-90 percent speedup for dense input matrices.
Truly sparse input matrices should also benefit from the improved sketch
algorithm, which now correctly runs in ``O(nnz(A))`` time.
Added new functions to calculate symmetric Fiedler matrices and
Fiedler companion matrices, named `scipy.linalg.fiedler` and
`scipy.linalg.fiedler_companion`, respectively. These may be used
for root finding.
`scipy.ndimage` improvements
----------------------------
Gaussian filter performances may improve by an order of magnitude in
some cases, thanks to removal of a dependence on ``np.polynomial``. This
may impact `scipy.ndimage.gaussian_filter` for example.
`scipy.optimize` improvements
-----------------------------
The `scipy.optimize.brute` minimizer obtained a new keyword ``workers``, which
can be used to parallelize computation.
A Cython API for bounded scalar-function root-finders in `scipy.optimize`
is available in a new module `scipy.optimize.cython_optimize` via ``cimport``.
This API may be used with ``nogil`` and ``prange`` to loop
over an array of function arguments to solve for an array of roots more
quickly than with pure Python.
``'interior-point'`` is now the default method for ``linprog``, and
``'interior-point'`` now uses SuiteSparse for sparse problems when the
required scikits (scikit-umfpack and scikit-sparse) are available.
On benchmark problems (gh-10026), execution time reductions by factors of 2-3
were typical. Also, a new ``method='revised simplex'`` has been added.
It is not as fast or robust as ``method='interior-point'``, but it is a faster,
more robust, and equally accurate substitute for the legacy
``method='simplex'``.
``differential_evolution`` can now use a ``Bounds`` class to specify the
bounds for the optimizing argument of a function.
`scipy.optimize.dual_annealing` performance improvements related to
vectorisation of some internal code.
`scipy.signal` improvements
---------------------------
Two additional methods of discretization are now supported by
`scipy.signal.cont2discrete`: ``impulse`` and ``foh``.
`scipy.signal.firls` now uses faster solvers
`scipy.signal.detrend` now has a lower physical memory footprint in some
cases, which may be leveraged using the new ``overwrite_data`` keyword argument
`scipy.signal.firwin` ``pass_zero`` argument now accepts new string arguments
that allow specification of the desired filter type: ``'bandpass'``,
``'lowpass'``, ``'highpass'``, and ``'bandstop'``
`scipy.signal.sosfilt` may have improved performance due to lower retention
of the global interpreter lock (GIL) in algorithm
`scipy.sparse` improvements
---------------------------
A new keyword was added to ``csgraph.dijsktra`` that
allows users to query the shortest path to ANY of the passed in indices,
as opposed to the shortest path to EVERY passed index.
`scipy.sparse.linalg.lsmr` performance has been improved by roughly 10 percent
on large problems
Improved performance and reduced physical memory footprint of the algorithm
used by `scipy.sparse.linalg.lobpcg`
``CSR`` and ``CSC`` sparse matrix fancy indexing performance has been
improved substantially
`scipy.spatial` improvements
----------------------------
`scipy.spatial.ConvexHull` now has a ``good`` attribute that can be used
alongsize the ``QGn`` Qhull options to determine which external facets of a
convex hull are visible from an external query point.
`scipy.spatial.cKDTree.query_ball_point` has been modernized to use some newer
Cython features, including GIL handling and exception translation. An issue
with ``return_sorted=True`` and scalar queries was fixed, and a new mode named
``return_length`` was added. ``return_length`` only computes the length of the
returned indices list instead of allocating the array every time.
`scipy.spatial.transform.RotationSpline` has been added to enable interpolation
of rotations with continuous angular rates and acceleration
`scipy.stats` improvements
--------------------------
Added a new function to compute the Epps-Singleton test statistic,
`scipy.stats.epps_singleton_2samp`, which can be applied to continuous and
discrete distributions.
New functions `scipy.stats.median_absolute_deviation` and `scipy.stats.gstd`
(geometric standard deviation) were added. The `scipy.stats.combine_pvalues`
method now supports ``pearson``, ``tippett`` and ``mudholkar_george`` pvalue
combination methods.
The `scipy.stats.ortho_group` and `scipy.stats.special_ortho_group`
``rvs(dim)`` functions' algorithms were updated from a ``O(dim^4)``
implementation to a ``O(dim^3)`` which gives large speed improvements
for ``dim>100``.
A rewrite of `scipy.stats.pearsonr` to use a more robust algorithm,
provide meaningful exceptions and warnings on potentially pathological input,
and fix at least five separate reported issues in the original implementation.
Improved the precision of ``hypergeom.logcdf`` and ``hypergeom.logsf``.
Added exact computation for Kolmogorov-Smirnov (KS) two-sample test, replacing
the previously approximate computation for the two-sided test `stats.ks_2samp`.
Also added a one-sided, two-sample KS test, and a keyword ``alternative`` to
`stats.ks_2samp`.
Backwards incompatible changes
==============================
`scipy.interpolate` changes
---------------------------
Functions from ``scipy.interpolate`` (``spleval``, ``spline``, ``splmake``,
and ``spltopp``) and functions from ``scipy.misc`` (``bytescale``,
``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``,
``imsave``, ``imshow``, ``toimage``) have been removed. The former set has
been deprecated since v0.19.0 and the latter has been deprecated since v1.0.0.
Similarly, aliases from ``scipy.misc`` (``comb``, ``factorial``,
``factorial2``, ``factorialk``, ``logsumexp``, ``pade``, ``info``, ``source``,
``who``) which have been deprecated since v1.0.0 are removed.
`SciPy documentation for
v1.1.0 <https://docs.scipy.org/doc/scipy-1.1.0/reference/misc.html>`__
can be used to track the new import locations for the relocated functions.
`scipy.linalg` changes
----------------------
For ``pinv``, ``pinv2``, and ``pinvh``, the default cutoff values are changed
for consistency (see the docs for the actual values).
`scipy.stats` changes
---------------------
Previously, ``ks_2samp(data1, data2)`` would run a two-sided test and return
the approximated p-value. The new signature, ``ks_2samp(data1, data2,
alternative="two-sided", method="auto")``, still runs the two-sided test by
default but returns the exact p-value for small samples and the approximated
value for large samples. ``method="asymp"`` would be equivalent to the
old version but ``auto`` is the better choice.
Other changes
=============
Our tutorial has been expanded with a new section on global optimizers
There has been a rework of the ``stats.distributions`` tutorials.
`scipy.optimize` now correctly sets the convergence flag of the result to
``CONVERR``, a convergence error, for bounded scalar-function root-finders
if the maximum iterations has been exceeded, ``disp`` is false, and
``full_output`` is true.
`scipy.optimize.curve_fit` no longer fails if ``xdata`` and ``ydata`` dtypes
differ; they are both now automatically cast to ``float64``.
`scipy.ndimage` functions including ``binary_erosion``, ``binary_closing``, and
``binary_dilation`` now require an integer value for the number of iterations,
which alleviates a number of reported issues.
Fixed normal approximation in case ``zero_method == "pratt"`` in
`scipy.stats.wilcoxon`.
Fixes for incorrect probabilities, broadcasting issues and thread-safety
related to stats distributions setting member variables inside ``_argcheck()``.
`scipy.optimize.newton` now correctly raises a ``RuntimeError``, when default
arguments are used, in the case that a derivative of value zero is obtained,
which is a special case of failing to converge.
A draft toolchain roadmap is now available, laying out a compatibility plan
including Python versions, C standards, and NumPy versions.
Authors
=======
* ananyashreyjain +
* ApamNapat +
* Scott Calabrese Barton +
* Christoph Baumgarten
* Peter Bell +
* Jacob Blomgren +
* Doctor Bob +
* Mana Borwornpadungkitti +
* Matthew Brett
* Evgeni Burovski
* CJ Carey
* Vega Theil Carstensen +
* Robert Cimrman
* Forrest Collman +
* Pietro Cottone +
* David +
* Idan David +
* Christoph Deil
* Dieter Werthmüller
* Conner DiPaolo +
* Dowon
* Michael Dunphy +
* Peter Andreas Entschev +
* Gökçen Eraslan +
* Johann Faouzi +
* Yu Feng
* Piotr Figiel +
* Matthew H Flamm
* Franz Forstmayr +
* Christoph Gohlke
* Richard Janis Goldschmidt +
* Ralf Gommers
* Lars Grueter
* Sylvain Gubian
* Matt Haberland
* Yaroslav Halchenko
* Charles Harris
* Lindsey Hiltner
* JakobStruye +
* He Jia +
* Jwink3101 +
* Greg Kiar +
* Julius Bier Kirkegaard
* John Kirkham +
* Thomas Kluyver
* Vladimir Korolev +
* Joseph Kuo +
* Michael Lamparski +
* Eric Larson
* Denis Laxalde
* Katrin Leinweber
* Jesse Livezey
* ludcila +
* Dhruv Madeka +
* Magnus +
* Nikolay Mayorov
* Mark Mikofski
* Jarrod Millman
* Markus Mohrhard +
* Eric Moore
* Andrew Nelson
* Aki Nishimura +
* OGordon100 +
* Petar Mlinarić +
* Stefan Peterson
* Matti Picus +
* Ilhan Polat
* Aaron Pries +
* Matteo Ravasi +
* Tyler Reddy
* Ashton Reimer +
* Joscha Reimer
* rfezzani +
* Riadh +
* Lucas Roberts
* Heshy Roskes +
* Mirko Scholz +
* Taylor D. Scott +
* Srikrishna Sekhar +
* Kevin Sheppard +
* Sourav Singh
* skjerns +
* Kai Striega
* SyedSaifAliAlvi +
* Gopi Manohar T +
* Albert Thomas +
* Timon +
* Paul van Mulbregt
* Jacob Vanderplas
* Daniel Vargas +
* Pauli Virtanen
* VNMabus +
* Stefan van der Walt
* Warren Weckesser
* Josh Wilson
* Nate Yoder +
* Roman Yurchak
A total of 97 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.
Issues closed for 1.3.0
-----------------------
* `#1320 <https://github.com/scipy/scipy/issues/1320>`__:
scipy.stats.distribution: problem with self.a, self.b if they...
* `#2002 <https://github.com/scipy/scipy/issues/2002>`__: members set
in scipy.stats.distributions.##._argcheck (Trac #1477)
* `#2823 <https://github.com/scipy/scipy/issues/2823>`__: distribution
methods add tmp
* `#3220 <https://github.com/scipy/scipy/issues/3220>`__:
Scipy.opimize.fmin_powell direc argument syntax unclear
* `#3728 <https://github.com/scipy/scipy/issues/3728>`__:
scipy.stats.pearsonr: possible bug with zero variance input
* `#6805 <https://github.com/scipy/scipy/issues/6805>`__:
error-in-scipy-wilcoxon-signed-rank-test-for-equal-series
* `#6873 <https://github.com/scipy/scipy/issues/6873>`__:
'stats.boxcox' return all same values
* `#7117 <https://github.com/scipy/scipy/issues/7117>`__: Warn users
when using float32 input data to curve_fit and friends
* `#7632 <https://github.com/scipy/scipy/issues/7632>`__: it's not
possible to tell the \`optimize.least_squares\` solver...
* `#7730 <https://github.com/scipy/scipy/issues/7730>`__:
stats.pearsonr: Potential division by zero for dataset of length...
* `#7933 <https://github.com/scipy/scipy/issues/7933>`__:
stats.truncnorm fails when providing values outside truncation...
* `#8033 <https://github.com/scipy/scipy/issues/8033>`__: Add standard
filter types to firwin to set pass_zero intuitively...
* `#8600 <https://github.com/scipy/scipy/issues/8600>`__:
lfilter.c.src zfill has erroneous header
* `#8692 <https://github.com/scipy/scipy/issues/8692>`__: Non-negative
values of \`stats.hypergeom.logcdf\`
* `#8734 <https://github.com/scipy/scipy/issues/8734>`__: Enable pip
build isolation
* `#8861 <https://github.com/scipy/scipy/issues/8861>`__:
scipy.linalg.pinv gives wrong result while scipy.linalg.pinv2...
* `#8915 <https://github.com/scipy/scipy/issues/8915>`__: need to fix
macOS build against older numpy versions
* `#8980 <https://github.com/scipy/scipy/issues/8980>`__:
scipy.stats.pearsonr overflows with high values of x and y
* `#9226 <https://github.com/scipy/scipy/issues/9226>`__: BUG: signal:
SystemError: <built-in function _linear_filter>...
* `#9254 <https://github.com/scipy/scipy/issues/9254>`__: BUG: root
finders brentq, etc, flag says "converged" even if...
* `#9308 <https://github.com/scipy/scipy/issues/9308>`__: Test failure
- test_initial_constraints_as_canonical
* `#9353 <https://github.com/scipy/scipy/issues/9353>`__:
scipy.stats.pearsonr returns r=1 if r_num/r_den = inf
* `#9359 <https://github.com/scipy/scipy/issues/9359>`__: Planck
distribution is a geometric distribution
* `#9381 <https://github.com/scipy/scipy/issues/9381>`__: linregress
should warn user in 2x2 array case
* `#9406 <https://github.com/scipy/scipy/issues/9406>`__: BUG: stats:
In pearsonr, when r is nan, the p-value must also...
* `#9437 <https://github.com/scipy/scipy/issues/9437>`__: Cannot
create sparse matrix from size_t indexes
* `#9518 <https://github.com/scipy/scipy/issues/9518>`__: Relational
attributes in loadarff
* `#9551 <https://github.com/scipy/scipy/issues/9551>`__: BUG:
scipy.optimize.newton says the root of x^2+1 is zero.
* `#9564 <https://github.com/scipy/scipy/issues/9564>`__: rv_sample
accepts invalid input in scipy.stats
* `#9565 <https://github.com/scipy/scipy/issues/9565>`__: improper
handling of multidimensional input in stats.rv_sample
* `#9581 <https://github.com/scipy/scipy/issues/9581>`__:
Least-squares minimization fails silently when x and y data are...
* `#9587 <https://github.com/scipy/scipy/issues/9587>`__: Outdated
value for scipy.constants.au
* `#9611 <https://github.com/scipy/scipy/issues/9611>`__: Overflow
error with new way of p-value calculation in kendall...
* `#9645 <https://github.com/scipy/scipy/issues/9645>`__:
\`scipy.stats.mode\` crashes with variable length arrays
(\`dtype=object\`)
* `#9734 <https://github.com/scipy/scipy/issues/9734>`__:
PendingDeprecationWarning for np.matrix with pytest
* `#9786 <https://github.com/scipy/scipy/issues/9786>`__:
stats.ks_2samp() misleading for small data sets.
* `#9790 <https://github.com/scipy/scipy/issues/9790>`__: Excessive
memory usage on detrend
* `#9801 <https://github.com/scipy/scipy/issues/9801>`__:
dual_annealing does not set the success attribute in OptimizeResult
* `#9833 <https://github.com/scipy/scipy/issues/9833>`__:
IntegrationWarning from mielke.stats() during build of html doc.
* `#9835 <https://github.com/scipy/scipy/issues/9835>`__:
scipy.signal.firls seems to be inefficient versus MATLAB firls
* `#9864 <https://github.com/scipy/scipy/issues/9864>`__: Curve_fit
does not check for empty input data if called with...
* `#9869 <https://github.com/scipy/scipy/issues/9869>`__:
scipy.ndimage.label: Minor documentation issue
* `#9882 <https://github.com/scipy/scipy/issues/9882>`__: format at
the wrong paranthesis in scipy.spatial.transform
* `#9889 <https://github.com/scipy/scipy/issues/9889>`__:
scipy.signal.find_peaks minor documentation issue
* `#9890 <https://github.com/scipy/scipy/issues/9890>`__: Minkowski
p-norm Issues in cKDTree For Values Other Than 2 Or...
* `#9896 <https://github.com/scipy/scipy/issues/9896>`__:
scipy.stats._argcheck sets (not just checks) values
* `#9905 <https://github.com/scipy/scipy/issues/9905>`__: Memory error
in ndimage.binary_erosion
* `#9909 <https://github.com/scipy/scipy/issues/9909>`__:
binary_dilation/erosion/closing crashes when iterations is float
* `#9919 <https://github.com/scipy/scipy/issues/9919>`__: BUG:
\`coo_matrix\` does not validate the \`shape\` argument.
* `#9982 <https://github.com/scipy/scipy/issues/9982>`__: lsq_linear
hangs/infinite loop with 'trf' method
* `#10003 <https://github.com/scipy/scipy/issues/10003>`__:
exponnorm.pdf returns NAN for small K
* `#10011 <https://github.com/scipy/scipy/issues/10011>`__: Incorrect
check for invalid rotation plane in scipy.ndimage.rotate
* `#10024 <https://github.com/scipy/scipy/issues/10024>`__: Fails to
build from git
* `#10048 <https://github.com/scipy/scipy/issues/10048>`__: DOC:
scipy.optimize.root_scalar
* `#10068 <https://github.com/scipy/scipy/issues/10068>`__: DOC:
scipy.interpolate.splev
* `#10074 <https://github.com/scipy/scipy/issues/10074>`__: BUG:
\`expm\` calculates the wrong coefficients in the backward...
Pull requests for 1.3.0
-----------------------
* `#7827 <https://github.com/scipy/scipy/pull/7827>`__: ENH: sparse:
overhaul of sparse matrix indexing
* `#8431 <https://github.com/scipy/scipy/pull/8431>`__: ENH: Cython
optimize zeros api
* `#8743 <https://github.com/scipy/scipy/pull/8743>`__: DOC: Updated
linalg.pinv, .pinv2, .pinvh docstrings
* `#8744 <https://github.com/scipy/scipy/pull/8744>`__: DOC: added
examples to remez docstring
* `#9227 <https://github.com/scipy/scipy/pull/9227>`__: DOC: update
description of "direc" parameter of "fmin_powell"
* `#9263 <https://github.com/scipy/scipy/pull/9263>`__: ENH: optimize:
added "revised simplex" for scipy.optimize.linprog
* `#9325 <https://github.com/scipy/scipy/pull/9325>`__: DEP: Remove
deprecated functions for 1.3.0
* `#9330 <https://github.com/scipy/scipy/pull/9330>`__: Add note on
push and pull affine transformations
* `#9423 <https://github.com/scipy/scipy/pull/9423>`__: DOC: Clearly
state how 2x2 input arrays are handled in stats.linregress
* `#9428 <https://github.com/scipy/scipy/pull/9428>`__: ENH: parallelised brute
* `#9438 <https://github.com/scipy/scipy/pull/9438>`__: BUG:
Initialize coo matrix with size_t indexes
* `#9455 <https://github.com/scipy/scipy/pull/9455>`__: MAINT: Speed
up get_(lapack,blas)_func
* `#9465 <https://github.com/scipy/scipy/pull/9465>`__: MAINT: Clean
up optimize.zeros C solvers interfaces/code.
* `#9477 <https://github.com/scipy/scipy/pull/9477>`__: DOC: linalg:
fix lstsq docstring on residues shape
* `#9478 <https://github.com/scipy/scipy/pull/9478>`__: DOC: Add
docstring examples for rosen functions
* `#9479 <https://github.com/scipy/scipy/pull/9479>`__: DOC: Add
docstring example for ai_zeros and bi_zeros
* `#9480 <https://github.com/scipy/scipy/pull/9480>`__: MAINT: linalg:
lstsq clean up
* `#9489 <https://github.com/scipy/scipy/pull/9489>`__: DOC: roadmap
update for changes over the last year.
* `#9492 <https://github.com/scipy/scipy/pull/9492>`__: MAINT: stats:
Improve implementation of chi2 ppf method.
* `#9497 <https://github.com/scipy/scipy/pull/9497>`__: DOC: Improve
docstrings sparse.linalg.isolve
* `#9499 <https://github.com/scipy/scipy/pull/9499>`__: DOC: Replace
"Scipy" with "SciPy" in the .rst doc files for consistency.
* `#9500 <https://github.com/scipy/scipy/pull/9500>`__: DOC: Document
the toolchain and its roadmap.
* `#9505 <https://github.com/scipy/scipy/pull/9505>`__: DOC: specify
which definition of skewness is used
* `#9511 <https://github.com/scipy/scipy/pull/9511>`__: DEP:
interpolate: remove deprecated interpolate_wrapper
* `#9517 <https://github.com/scipy/scipy/pull/9517>`__: BUG: improve
error handling in stats.iqr
* `#9522 <https://github.com/scipy/scipy/pull/9522>`__: ENH: Add
Fiedler and fiedler companion to special matrices
* `#9526 <https://github.com/scipy/scipy/pull/9526>`__: TST: relax
precision requirements in signal.correlate tests
* `#9529 <https://github.com/scipy/scipy/pull/9529>`__: DOC: fix
missing random seed in optimize.newton example
* `#9533 <https://github.com/scipy/scipy/pull/9533>`__: MAINT: Use
list comprehension when possible
* `#9537 <https://github.com/scipy/scipy/pull/9537>`__: DOC: add a
"big picture" roadmap
* `#9538 <https://github.com/scipy/scipy/pull/9538>`__: DOC: Replace
"Numpy" with "NumPy" in .py, .rst and .txt doc files...
* `#9539 <https://github.com/scipy/scipy/pull/9539>`__: ENH: add
two-sample test (Epps-Singleton) to scipy.stats
* `#9559 <https://github.com/scipy/scipy/pull/9559>`__: DOC: add
section on global optimizers to tutorial
* `#9561 <https://github.com/scipy/scipy/pull/9561>`__: ENH: remove
noprefix.h, change code appropriately
* `#9562 <https://github.com/scipy/scipy/pull/9562>`__: MAINT: stats:
Rewrite pearsonr.
* `#9563 <https://github.com/scipy/scipy/pull/9563>`__: BUG: Minor bug
fix Callback in linprog(method='simplex')
* `#9568 <https://github.com/scipy/scipy/pull/9568>`__: MAINT: raise
runtime error for newton with zeroder if disp true,...
* `#9570 <https://github.com/scipy/scipy/pull/9570>`__: Correct
docstring in show_options in optimize. Fixes #9407
* `#9573 <https://github.com/scipy/scipy/pull/9573>`__: BUG fixes
range of pk variable pre-check
* `#9577 <https://github.com/scipy/scipy/pull/9577>`__: TST: fix minor
issue in a signal.stft test.
* `#9580 <https://github.com/scipy/scipy/pull/9580>`__: Included blank
line before list - Fixes #8658
* `#9582 <https://github.com/scipy/scipy/pull/9582>`__: MAINT: drop
Python 2.7 and 3.4
* `#9588 <https://github.com/scipy/scipy/pull/9588>`__: MAINT: update
\`constants.astronomical_unit\` to new 2012 value.
* `#9592 <https://github.com/scipy/scipy/pull/9592>`__: TST: Add
32-bit testing to CI
* `#9593 <https://github.com/scipy/scipy/pull/9593>`__: DOC: Replace
cumulative density with cumulative distribution
* `#9596 <https://github.com/scipy/scipy/pull/9596>`__: TST: remove VC
9.0 from Azure CI
* `#9599 <https://github.com/scipy/scipy/pull/9599>`__: Hyperlink DOI
to preferred resolver
* `#9601 <https://github.com/scipy/scipy/pull/9601>`__: DEV: try to
limit GC memory use on PyPy
* `#9603 <https://github.com/scipy/scipy/pull/9603>`__: MAINT: improve
logcdf and logsf of hypergeometric distribution
* `#9605 <https://github.com/scipy/scipy/pull/9605>`__: Reference to
pylops in LinearOperator notes and ARPACK example
* `#9617 <https://github.com/scipy/scipy/pull/9617>`__: TST: reduce
max memory usage for sparse.linalg.lgmres test
* `#9619 <https://github.com/scipy/scipy/pull/9619>`__: FIX: Sparse
matrix addition/subtraction eliminates explicit zeros
* `#9621 <https://github.com/scipy/scipy/pull/9621>`__: bugfix in
rv_sample in scipy.stats
* `#9622 <https://github.com/scipy/scipy/pull/9622>`__: MAINT: Raise
error in directed_hausdorff distance
* `#9623 <https://github.com/scipy/scipy/pull/9623>`__: DOC: Build
docs with warnings as errors
* `#9625 <https://github.com/scipy/scipy/pull/9625>`__: Return the
number of calls to 'hessp' (not just 'hess') in trust...
* `#9627 <https://github.com/scipy/scipy/pull/9627>`__: BUG: ignore
empty lines in mmio
* `#9637 <https://github.com/scipy/scipy/pull/9637>`__: Function to
calculate the MAD of an array
* `#9646 <https://github.com/scipy/scipy/pull/9646>`__: BUG: stats:
mode for objects w/ndim > 1
* `#9648 <https://github.com/scipy/scipy/pull/9648>`__: Add
\`stats.contingency\` to refguide-check
* `#9650 <https://github.com/scipy/scipy/pull/9650>`__: ENH: many
lobpcg() algorithm improvements
* `#9652 <https://github.com/scipy/scipy/pull/9652>`__: Move
misc.doccer to _lib.doccer
* `#9660 <https://github.com/scipy/scipy/pull/9660>`__: ENH: add
pearson, tippett, and mudholkar-george to combine_pvalues
* `#9661 <https://github.com/scipy/scipy/pull/9661>`__: BUG: Fix ksone
right-hand endpoint, documentation and tests.
* `#9664 <https://github.com/scipy/scipy/pull/9664>`__: ENH: adding
multi-target dijsktra performance enhancement
* `#9670 <https://github.com/scipy/scipy/pull/9670>`__: MAINT: link
planck and geometric distribution in scipy.stats
* `#9676 <https://github.com/scipy/scipy/pull/9676>`__: ENH: optimize:
change default linprog method to interior-point
* `#9685 <https://github.com/scipy/scipy/pull/9685>`__: Added
reference to ndimage.filters.median_filter
* `#9705 <https://github.com/scipy/scipy/pull/9705>`__: Fix
coefficients in expm helper function
* `#9711 <https://github.com/scipy/scipy/pull/9711>`__: Release the
GIL during sosfilt processing for simple types
* `#9721 <https://github.com/scipy/scipy/pull/9721>`__: ENH:
Convexhull visiblefacets
* `#9723 <https://github.com/scipy/scipy/pull/9723>`__: BLD: Modify
rv_generic._construct_doc to print out failing distribution...
* `#9726 <https://github.com/scipy/scipy/pull/9726>`__: BUG: Fix small
issues with \`signal.lfilter'
* `#9729 <https://github.com/scipy/scipy/pull/9729>`__: BUG: Typecheck
iterations for binary image operations
* `#9730 <https://github.com/scipy/scipy/pull/9730>`__: ENH: reduce
sizeof(NI_WatershedElement) by 20%
* `#9731 <https://github.com/scipy/scipy/pull/9731>`__: ENH: remove
suspicious sequence of type castings
* `#9739 <https://github.com/scipy/scipy/pull/9739>`__: BUG:
qr_updates fails if u is exactly in span Q
* `#9749 <https://github.com/scipy/scipy/pull/9749>`__: BUG:
MapWrapper.__exit__ should terminate
* `#9753 <https://github.com/scipy/scipy/pull/9753>`__: ENH: Added
exact computation for Kolmogorov-Smirnov two-sample...
* `#9755 <https://github.com/scipy/scipy/pull/9755>`__: DOC: Added
example for signal.impulse, copied from impulse2
* `#9756 <https://github.com/scipy/scipy/pull/9756>`__: DOC: Added
docstring example for iirdesign
* `#9757 <https://github.com/scipy/scipy/pull/9757>`__: DOC: Added
examples for step functions
* `#9759 <https://github.com/scipy/scipy/pull/9759>`__: ENH: Allow
pass_zero to act like btype
* `#9760 <https://github.com/scipy/scipy/pull/9760>`__: DOC: Added
docstring for lp2bs
* `#9761 <https://github.com/scipy/scipy/pull/9761>`__: DOC: Added
docstring and example for lp2bp
* `#9764 <https://github.com/scipy/scipy/pull/9764>`__: BUG: Catch
internal warnings for matrix
* `#9766 <https://github.com/scipy/scipy/pull/9766>`__: ENH: Speed up
_gaussian_kernel1d by removing dependence on np.polynomial
* `#9769 <https://github.com/scipy/scipy/pull/9769>`__: BUG: Fix Cubic
Spline Read Only issues
* `#9773 <https://github.com/scipy/scipy/pull/9773>`__: DOC: Several docstrings
* `#9774 <https://github.com/scipy/scipy/pull/9774>`__: TST: bump
Azure CI OpenBLAS version to match wheels
* `#9775 <https://github.com/scipy/scipy/pull/9775>`__: DOC: Improve
clarity of cov_x documentation for scipy.optimize.leastsq
* `#9779 <https://github.com/scipy/scipy/pull/9779>`__: ENH:
dual_annealing vectorise visit_fn
* `#9788 <https://github.com/scipy/scipy/pull/9788>`__: TST, BUG:
f2py-related issues with NumPy < 1.14.0
* `#9791 <https://github.com/scipy/scipy/pull/9791>`__: BUG: fix amax
constraint not enforced in scalar_search_wolfe2
* `#9792 <https://github.com/scipy/scipy/pull/9792>`__: ENH: Allow
inplace copying in place in "detrend" function
* `#9795 <https://github.com/scipy/scipy/pull/9795>`__: DOC:
Fix/update docstring for dstn and dst
* `#9796 <https://github.com/scipy/scipy/pull/9796>`__: MAINT: Allow
None tolerances in least_squares
* `#9798 <https://github.com/scipy/scipy/pull/9798>`__: BUG: fixes
abort trap 6 error in scipy issue 9785 in unit tests
* `#9807 <https://github.com/scipy/scipy/pull/9807>`__: MAINT: improve
doc and add alternative keyword to wilcoxon in...
* `#9808 <https://github.com/scipy/scipy/pull/9808>`__: Fix PPoly
integrate and test for CubicSpline
* `#9810 <https://github.com/scipy/scipy/pull/9810>`__: ENH: Add the
geometric standard deviation function
* `#9811 <https://github.com/scipy/scipy/pull/9811>`__: MAINT: remove
invalid derphi default None value in scalar_search_wolfe2
* `#9813 <https://github.com/scipy/scipy/pull/9813>`__: Adapt hamming
distance in C to support weights
* `#9817 <https://github.com/scipy/scipy/pull/9817>`__: DOC: Copy
solver description to solver modules
* `#9829 <https://github.com/scipy/scipy/pull/9829>`__: ENH: Add FOH
and equivalent impulse response discretizations...
* `#9831 <https://github.com/scipy/scipy/pull/9831>`__: ENH: Implement
RotationSpline
* `#9834 <https://github.com/scipy/scipy/pull/9834>`__: DOC: Change
mielke distribution default parameters to ensure...
* `#9838 <https://github.com/scipy/scipy/pull/9838>`__: ENH: Use
faster solvers for firls
* `#9854 <https://github.com/scipy/scipy/pull/9854>`__: ENH: loadarff
now supports relational attributes.
* `#9856 <https://github.com/scipy/scipy/pull/9856>`__: integrate.bvp
- improve handling of nonlinear boundary conditions
* `#9862 <https://github.com/scipy/scipy/pull/9862>`__: TST: reduce
Appveyor CI load
* `#9874 <https://github.com/scipy/scipy/pull/9874>`__: DOC: Update
requirements in release notes
* `#9883 <https://github.com/scipy/scipy/pull/9883>`__: BUG: fixed
parenthesis in spatial.rotation
* `#9884 <https://github.com/scipy/scipy/pull/9884>`__: ENH: Use
Sparsity in Clarkson-Woodruff Sketch
* `#9888 <https://github.com/scipy/scipy/pull/9888>`__: MAINT: Replace
NumPy aliased functions
* `#9892 <https://github.com/scipy/scipy/pull/9892>`__: BUG: Fix 9890
query_ball_point returns wrong result when p is...
* `#9893 <https://github.com/scipy/scipy/pull/9893>`__: BUG: curve_fit
doesn't check for empty input if called with bounds
* `#9894 <https://github.com/scipy/scipy/pull/9894>`__:
scipy.signal.find_peaks documentation error
* `#9898 <https://github.com/scipy/scipy/pull/9898>`__: BUG: Set
success attribute in OptimizeResult. See #9801
* `#9900 <https://github.com/scipy/scipy/pull/9900>`__: BUG: Restrict
rv_generic._argcheck() and its overrides from setting...
* `#9906 <https://github.com/scipy/scipy/pull/9906>`__: fixed a bug in
kde logpdf
* `#9911 <https://github.com/scipy/scipy/pull/9911>`__: DOC: replace
example for "np.select" with the one from numpy...
* `#9912 <https://github.com/scipy/scipy/pull/9912>`__: BF(DOC): point
to numpy.select instead of plain (python) .select
* `#9914 <https://github.com/scipy/scipy/pull/9914>`__: DOC: change
ValueError message in _validate_pad of signaltools.
* `#9915 <https://github.com/scipy/scipy/pull/9915>`__: cKDTree
query_ball_point improvements
* `#9918 <https://github.com/scipy/scipy/pull/9918>`__: Update
ckdtree.pyx with boxsize argument in docstring
* `#9920 <https://github.com/scipy/scipy/pull/9920>`__: BUG: sparse:
Validate explicit shape if given with dense argument...
* `#9924 <https://github.com/scipy/scipy/pull/9924>`__: BLD: add back
pyproject.toml
* `#9931 <https://github.com/scipy/scipy/pull/9931>`__: Fix empty constraint
* `#9935 <https://github.com/scipy/scipy/pull/9935>`__: DOC: fix
references for stats.f_oneway
* `#9936 <https://github.com/scipy/scipy/pull/9936>`__: Revert
gh-9619: "FIX: Sparse matrix addition/subtraction eliminates...
* `#9937 <https://github.com/scipy/scipy/pull/9937>`__: MAINT: fix
PEP8 issues and update to pycodestyle 2.5.0
* `#9939 <https://github.com/scipy/scipy/pull/9939>`__: DOC: correct
\`structure\` description in \`ndimage.label\` docstring
* `#9940 <https://github.com/scipy/scipy/pull/9940>`__: MAINT: remove
extraneous distutils copies
* `#9945 <https://github.com/scipy/scipy/pull/9945>`__: ENH:
differential_evolution can use Bounds object
* `#9949 <https://github.com/scipy/scipy/pull/9949>`__: Added 'std' to
add doctstrings since it is a \`known_stats\`...
* `#9953 <https://github.com/scipy/scipy/pull/9953>`__: DOC:
Documentation cleanup for stats tutorials.
* `#9962 <https://github.com/scipy/scipy/pull/9962>`__: __repr__ for Bounds
* `#9971 <https://github.com/scipy/scipy/pull/9971>`__: ENH: Improve
performance of lsmr
* `#9987 <https://github.com/scipy/scipy/pull/9987>`__: CI: pin Sphinx
version to 1.8.5
* `#9990 <https://github.com/scipy/scipy/pull/9990>`__: ENH:
constraint violation
* `#9991 <https://github.com/scipy/scipy/pull/9991>`__: BUG: Avoid
inplace modification of input array in newton
* `#9995 <https://github.com/scipy/scipy/pull/9995>`__: MAINT:
sparse.csgraph: Add cdef to stop build warning.
* `#9996 <https://github.com/scipy/scipy/pull/9996>`__: BUG: Make
minimize_quadratic_1d work with infinite bounds correctly
* `#10004 <https://github.com/scipy/scipy/pull/10004>`__: BUG: Fix
unbound local error in linprog - simplex.
* `#10007 <https://github.com/scipy/scipy/pull/10007>`__: BLD: fix
Python 3.7 build with build isolation
* `#10009 <https://github.com/scipy/scipy/pull/10009>`__: BUG: Make
sure that _binary_erosion only accepts an integer number...
* `#10016 <https://github.com/scipy/scipy/pull/10016>`__: Update link
to airspeed-velocity
* `#10017 <https://github.com/scipy/scipy/pull/10017>`__: DOC: Update
\`interpolate.LSQSphereBivariateSpline\` to include...
* `#10018 <https://github.com/scipy/scipy/pull/10018>`__: MAINT:
special: Fix a few warnings that occur when compiling...
* `#10019 <https://github.com/scipy/scipy/pull/10019>`__: TST: Azure
summarizes test failures
* `#10021 <https://github.com/scipy/scipy/pull/10021>`__: ENH:
Introduce CubicHermiteSpline
* `#10022 <https://github.com/scipy/scipy/pull/10022>`__: BENCH:
Increase cython version in asv to fix benchmark builds
* `#10023 <https://github.com/scipy/scipy/pull/10023>`__: BUG: Avoid
exponnorm producing nan for small K values.
* `#10025 <https://github.com/scipy/scipy/pull/10025>`__: BUG:
optimize: tweaked linprog status 4 error message
* `#10026 <https://github.com/scipy/scipy/pull/10026>`__: ENH:
optimize: use SuiteSparse in linprog interior-point when...
* `#10027 <https://github.com/scipy/scipy/pull/10027>`__: MAINT:
cluster: clean up the use of malloc() in the function...
* `#10028 <https://github.com/scipy/scipy/pull/10028>`__: Fix rotate
invalid plane check
* `#10040 <https://github.com/scipy/scipy/pull/10040>`__: MAINT: fix
pratt method of wilcox test in scipy.stats
* `#10041 <https://github.com/scipy/scipy/pull/10041>`__: MAINT:
special: Fix a warning generated when building the AMOS...
* `#10044 <https://github.com/scipy/scipy/pull/10044>`__: DOC: fix up
spatial.transform.Rotation docstrings
* `#10047 <https://github.com/scipy/scipy/pull/10047>`__: MAINT:
interpolate: Fix a few build warnings.
* `#10051 <https://github.com/scipy/scipy/pull/10051>`__: Add
project_urls to setup
* `#10052 <https://github.com/scipy/scipy/pull/10052>`__: don't set
flag to "converged" if max iter exceeded
* `#10054 <https://github.com/scipy/scipy/pull/10054>`__: MAINT:
signal: Fix a few build warnings and modernize some C...
* `#10056 <https://github.com/scipy/scipy/pull/10056>`__: BUG: Ensure
factorial is not too large in kendaltau
* `#10058 <https://github.com/scipy/scipy/pull/10058>`__: Small
speedup in samping from ortho and special_ortho groups
* `#10059 <https://github.com/scipy/scipy/pull/10059>`__: BUG:
optimize: fix #10038 by increasing tol
* `#10061 <https://github.com/scipy/scipy/pull/10061>`__: BLD: DOC:
make building docs easier by parsing python version.
* `#10064 <https://github.com/scipy/scipy/pull/10064>`__: ENH:
Significant speedup for ortho and special ortho group
* `#10065 <https://github.com/scipy/scipy/pull/10065>`__: DOC: Reword
parameter descriptions in \`optimize.root_scalar\`
* `#10066 <https://github.com/scipy/scipy/pull/10066>`__: BUG: signal:
Fix error raised by savgol_coeffs when deriv > polyorder.
* `#10067 <https://github.com/scipy/scipy/pull/10067>`__: MAINT: Fix
the cutoff value inconsistency for pinv2 and pinvh
* `#10072 <https://github.com/scipy/scipy/pull/10072>`__: BUG: stats:
Fix boxcox_llf to avoid loss of precision.
* `#10075 <https://github.com/scipy/scipy/pull/10075>`__: ENH: Add
wrappers for ?syconv routines
* `#10076 <https://github.com/scipy/scipy/pull/10076>`__: BUG:
optimize: fix curve_fit for mixed float32/float64 input
* `#10077 <https://github.com/scipy/scipy/pull/10077>`__: DOC: Replace
undefined \`k\` in \`interpolate.splev\` docstring
* `#10079 <https://github.com/scipy/scipy/pull/10079>`__: DOC: Fixed
typo, rearranged some doc of stats.morestats.wilcoxon.
* `#10080 <https://github.com/scipy/scipy/pull/10080>`__: TST: install
scikit-sparse for full TravisCI tests
* `#10083 <https://github.com/scipy/scipy/pull/10083>`__: Clean
\`\`_clean_inputs\`\` in optimize.linprog
* `#10088 <https://github.com/scipy/scipy/pull/10088>`__: ENH:
optimize: linprog test CHOLMOD/UMFPACK solvers when available
* `#10090 <https://github.com/scipy/scipy/pull/10090>`__: MAINT: Fix
CubicSplinerInterpolator for pandas
* `#10091 <https://github.com/scipy/scipy/pull/10091>`__: MAINT:
improve logcdf and logsf of hypergeometric distribution
* `#10095 <https://github.com/scipy/scipy/pull/10095>`__: MAINT: Clean
\`\`_clean_inputs\`\` in linprog
Checksums
=========
MD5
~~~
5a71a217fa4ff372097f501daf816f3b
scipy-1.3.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_int
el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
c154ca8eee9ebafe04575b316e41ed85 scipy-1.3.0rc1-cp35-cp35m-manylinux1_i686.whl
36a91fa4ae6eeceeb79bf97b9bd013eb
scipy-1.3.0rc1-cp35-cp35m-manylinux1_x86_64.whl
f1f4259b373332d6edc6bef123b0dc7c scipy-1.3.0rc1-cp35-cp35m-win32.whl
c81d78bed8e2176cf0168785b7e1b692 scipy-1.3.0rc1-cp35-cp35m-win_amd64.whl
c43dd24f349c9d37a6c996e7c0674141
scipy-1.3.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_int
el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
8188210e0fd710f4544f314306b76313 scipy-1.3.0rc1-cp36-cp36m-manylinux1_i686.whl
0cf317ee185a8f5736b479d1c8b5f415
scipy-1.3.0rc1-cp36-cp36m-manylinux1_x86_64.whl
e46e5b38288d79321d8d6ffa15a8f54e scipy-1.3.0rc1-cp36-cp36m-win32.whl
85a79e9be408de72056c6efc1eef7d46 scipy-1.3.0rc1-cp36-cp36m-win_amd64.whl
2436169658f74e03b4037142e51a8f86
scipy-1.3.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_int
el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
1b9e2caa5994ee227b4ad8e46b45ad7e scipy-1.3.0rc1-cp37-cp37m-manylinux1_i686.whl
05a51b40471abdf4e9020183ad449bf2
scipy-1.3.0rc1-cp37-cp37m-manylinux1_x86_64.whl
debecbc0e54fe4e737971b0a6d9f24f5 scipy-1.3.0rc1-cp37-cp37m-win32.whl
79c725144fa59566d8ebd3bf556533aa scipy-1.3.0rc1-cp37-cp37m-win_amd64.whl
0b9fa3583bcf2c8190b277cddb287132 scipy-1.3.0rc1.tar.gz
d22a40e138ecd6bb26990e22d4a1ac1b scipy-1.3.0rc1.tar.xz
9cc12f26980587900befabafaac2078b scipy-1.3.0rc1.zip
SHA256
~~~~~~
3491e5453acec48ff8bc1e96980a9ca225bf653eb8e2fad2efe44ca54fd61230
scipy-1.3.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
b04fed432d0d2b7aa52fb83c87390f22e34407baa404385e6c804c6d2f9fe3dc
scipy-1.3.0rc1-cp35-cp35m-manylinux1_i686.whl
71c236d8b036caa84a018b056c6ced101bcb3efb160fab18957daf5a41c7319c
scipy-1.3.0rc1-cp35-cp35m-manylinux1_x86_64.whl
6fa6a341ab6920f9233ce5da16572e3e403540f90c17269e27a7a7451e05d40e
scipy-1.3.0rc1-cp35-cp35m-win32.whl
7ec09797276d26c74234c056415234a7168e536011767af984b1700410806699
scipy-1.3.0rc1-cp35-cp35m-win_amd64.whl
55fcdd1ea9bb3d5461477391d924e24c56c8fa3cb3aba98c2ee2c47e3ccd6ce2
scipy-1.3.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
b149d330d0a8219b68d2839cc49a37df163b0ec0b56194f8f0aa6878c1e7c2a4
scipy-1.3.0rc1-cp36-cp36m-manylinux1_i686.whl
9fed021210077c2e183f621d84bef428762b0b226f8f6da2b03a7d93628e3089
scipy-1.3.0rc1-cp36-cp36m-manylinux1_x86_64.whl
5c9c9a47e914fbf8edc9a1da1e10a9f5204b3dfc89c93b721b658290884bfe45
scipy-1.3.0rc1-cp36-cp36m-win32.whl
09b2c3e099b6274b142e7e05132e79efbbe4daa9dd593a226a3bc9820adf966a
scipy-1.3.0rc1-cp36-cp36m-win_amd64.whl
4e93edc6d4c1296ac39ae4be2e8d9336a37a3e5c6e104801a288db0f18d5dbd1
scipy-1.3.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
1edafef721c859848b8575e7313fba062903f3c256661304f488b96fff4f759d
scipy-1.3.0rc1-cp37-cp37m-manylinux1_i686.whl
2fe186fff442d3f54f8e6950e809c571ea29db8333ed30608c4074a843d5cdf1
scipy-1.3.0rc1-cp37-cp37m-manylinux1_x86_64.whl
7c59ec7d5148538978da6c66059c9e3240ae9cf17b803b15354fffc8d3320961
scipy-1.3.0rc1-cp37-cp37m-win32.whl
2ab6d6f940b6b09cbee6d7cb2de5914a50f459cbc612b4328b033f67452fd1d6
scipy-1.3.0rc1-cp37-cp37m-win_amd64.whl
d09e6fae7434aa9e1422d95bbee28f0b66ba97ab770fec24f31c75a873823cd6
scipy-1.3.0rc1.tar.gz
ba49645a693f6e70e690cf6e2175865b7bf0182cf59bdce872968f47546f4269
scipy-1.3.0rc1.tar.xz
f1cdb4651f3d150f5c145dc930a627f09aa2afc5275c6c5da97a9a5df274c531
scipy-1.3.0rc1.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJcw54gAAoJELD/41ZX0J71zbEQAKaapoUb0gbLvljeLL+FZmaZ
Ha8OecYf7Fsdgj9kiGk2kKgrvz5nkoRyJDpxi4BOzPua+HBUhECoH3DBL5kA6sbv
VsMAhTb5HFPiKmC78LHEUNSY1fPJrdK7s99pIgedjQFR5diODHqqtB54awbRsTOs
Vdq45I7JoCd+DUMqQWIA3TZyjrZzw2V1KBFS8mHFdcop71Q1RqRNf3rVw7Rpydob
uegbae42cJ2Hej4+viU8hsCM+JIgkCuZaQEN2wp4W9pmHsDCzJcoyQjulTjZQAeG
W3L/F5O1p9A9nHIPk+wvS3D2ageKOhYmVSgB6dznXnFRsjwIKH4O4k0TCzYAamsd
HvcKnncGAzc+95o2k+v46575O3pBPRYCmOKz6LlFfFGNr/PWkxPYuG49nGIwQZU+
/w0RYvu2NIPyd05gQQfwyEAATmwbYQfCelbQtHtPehDrtwMINZF4ZCqVg8D7d2ns
c2mUUC72Iq62R17CdQOjp/zkvU4Xo6KGm0TPQY7xuJwXOaiM5cJ49iY+/Z6eBfBM
JS0MoIZ8PRzhzQ6gKTPt4exil75ybNpCeL/Ny/LY5dgkfaOdTuplmxwxgngxaECG
W4SaGw4P0SiATwyz7hMprv/Xkq59iK6IsF6Ki7uxPuMps+nbYhvVIUXqh8Y5iVxx
piFfF2ct8rgxkVm3qBmN
=KK2K
-----END PGP SIGNATURE-----