[SciPy-User] [Numpy-discussion] ANN: NumPy 1.6.2 release candidate 1

[Charles R Harris]

On Fri, May 11, 2012 at 8:05 AM, Benjamin Root <ben.root at ou.edu> wrote:

>
>
> On Sat, May 5, 2012 at 2:15 PM, Ralf Gommers <ralf.gommers at googlemail.com>wrote:
>
>> Hi,
>>
>> I'm pleased to announce the availability of the first release candidate
>> of NumPy 1.6.2.  This is a maintenance release. Due to the delay of the
>> NumPy 1.7.0, this release contains far more fixes than a regular NumPy
>> bugfix release.  It also includes a number of documentation and build
>> improvements.
>>
>> Sources and binary installers can be found at
>> https://sourceforge.net/projects/numpy/files/NumPy/1.6.2rc1/
>>
>> Please test this release and report any issues on the numpy-discussion
>> mailing list.
>>
>> Cheers,
>> Ralf
>>
>>
>>
>> ``numpy.core`` issues fixed
>> ---------------------------
>>
>> #2063  make unique() return consistent index
>> #1138  allow creating arrays from empty buffers or empty slices
>> #1446  correct note about correspondence vstack and concatenate
>> #1149  make argmin() work for datetime
>> #1672  fix allclose() to work for scalar inf
>> #1747  make np.median() work for 0-D arrays
>> #1776  make complex division by zero to yield inf properly
>> #1675  add scalar support for the format() function
>> #1905  explicitly check for NaNs in allclose()
>> #1952  allow floating ddof in std() and var()
>> #1948  fix regression for indexing chararrays with empty list
>> #2017  fix type hashing
>> #2046  deleting array attributes causes segfault
>> #2033  a**2.0 has incorrect type
>> #2045  make attribute/iterator_element deletions not segfault
>> #2021  fix segfault in searchsorted()
>> #2073  fix float16 __array_interface__ bug
>>
>>
>> ``numpy.lib`` issues fixed
>> --------------------------
>>
>> #2048  break reference cycle in NpzFile
>> #1573  savetxt() now handles complex arrays
>> #1387  allow bincount() to accept empty arrays
>> #1899  fixed histogramdd() bug with empty inputs
>> #1793  fix failing npyio test under py3k
>> #1936  fix extra nesting for subarray dtypes
>> #1848  make tril/triu return the same dtype as the original array
>> #1918  use Py_TYPE to access ob_type, so it works also on Py3
>>
>>
>> ``numpy.f2py`` changes
>> ----------------------
>>
>> ENH:   Introduce new options extra_f77_compiler_args and
>> extra_f90_compiler_args
>> BLD:   Improve reporting of fcompiler value
>> BUG:   Fix f2py test_kind.py test
>>
>>
>> ``numpy.poly`` changes
>> ----------------------
>>
>> ENH:   Add some tests for polynomial printing
>> ENH:   Add companion matrix functions
>> DOC:   Rearrange the polynomial documents
>> BUG:   Fix up links to classes
>> DOC:   Add version added to some of the polynomial package modules
>> DOC:   Document xxxfit functions in the polynomial package modules
>> BUG:   The polynomial convenience classes let different types interact
>> DOC:   Document the use of the polynomial convenience classes
>> DOC:   Improve numpy reference documentation of polynomial classes
>> ENH:   Improve the computation of polynomials from roots
>> STY:   Code cleanup in polynomial [*]fromroots functions
>> DOC:   Remove references to cast and NA, which were added in 1.7
>>
>>
>> ``numpy.distutils`` issues fixed
>> -------------------------------
>>
>> #1261  change compile flag on AIX from -O5 to -O3
>> #1377  update HP compiler flags
>> #1383  provide better support for C++ code on HPUX
>> #1857  fix build for py3k + pip
>> BLD:   raise a clearer warning in case of building without cleaning up
>> first
>> BLD:   follow build_ext coding convention in build_clib
>> BLD:   fix up detection of Intel CPU on OS X in system_info.py
>> BLD:   add support for the new X11 directory structure on Ubuntu & co.
>> BLD:   add ufsparse to the libraries search path.
>> BLD:   add 'pgfortran' as a valid compiler in the Portland Group
>> BLD:   update version match regexp for IBM AIX Fortran compilers.
>>
>>
>>
> I just noticed that my fix for the np.gradient() function isn't listed.
> https://github.com/numpy/numpy/pull/167
>
> Not critical, but if a second rc is needed for any reason, it would be
> nice to have that in there.
>
>
If there is a second rc I'll put in in.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20120511/64e98ea4/attachment.html>