Re: [Numpy-discussion] PyData Barcelona this May

[Sebastian Berg]

On Thu, 2017-03-09 at 15:45 +0100, Jaime Fernández del Río wrote:
> There will be a PyData conference in Barcelona this May:
> 
> http://pydata.org/barcelona2017/
> 
> I am planning on attending, and was thinking of maybe proposing to
> organize a numpy-themed workshop or tutorial.
> 
> My personal inclination would be to look at some advanced topic that
> I know well, like writing gufuncs in Cython, but wouldn't mind doing
> a more run of the mill thing. Anyone has any thoughts or experiences
> on what has worked well in similar situations? Any specific topic you
> always wanted to attend a workshop on, but were afraid to ask?
> 
> Alternatively, or on top of the workshop, I could propose to do a
> talk: talking last year at PyData Madrid about the new indexing was a
> lot of fun! Thing is, I have been quite disconnected from the project
> this past year, and can't really think of any worthwhile topic. Is
> there any message that we as a project would like to get out to the
> larger community?
> 

Francesc already pointed out the temporary optimization. From what I
remember, my personal highlight would probably be Pauli's work on the
memory overlap detection. Though both are rather passive improvements I
guess (you don't really have to learn them to use them), its very cool!
And if its about highlighting new stuff, these can probably easily fill
a talk.

> And if you are planning on attending, please give me a shout.
> 

Barcelona :). Maybe I should think about it, but probably not.


> Thanks,
> 
> Jaime
> 
> -- 
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus
> planes de dominación mundial.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

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] PyData Barcelona this May

[Francesc Alted]

Hola Jaime!

2017-03-09 15:45 GMT+01:00 Jaime Fernández del Río :

> There will be a PyData conference in Barcelona this May:
>
> http://pydata.org/barcelona2017/
>
> I am planning on attending, and was thinking of maybe proposing to
> organize a numpy-themed workshop or tutorial.
>
> My personal inclination would be to look at some advanced topic that I
> know well, like writing gufuncs in Cython, but wouldn't mind doing a more
> run of the mill thing. Anyone has any thoughts or experiences on what has
> worked well in similar situations? Any specific topic you always wanted to
> attend a workshop on, but were afraid to ask?
>

​Writing gufuncs in Cython seems a quite advanced​ topic for a workshop,
but an interesting one indeed.  Numba also supports creating gufuncs (
http://numba.pydata.org/numba-doc/dev/reference/numpysupported.html), so
this perhaps may work as a first approach before going deeper into Cython.


>
> Alternatively, or on top of the workshop, I could propose to do a talk:
> talking last year at PyData Madrid about the new indexing was a lot of fun!
> Thing is, I have been quite disconnected from the project this past year,
> and can't really think of any worthwhile topic. Is there any message that
> we as a project would like to get out to the larger community?
>

​Not a message in particular, but perhaps it would be nice talking about
the temporaries removal ​in expressions that Julian implemented recently (
https://github.com/numpy/numpy/pull/7997) and that is to be released in
1.13.  It is a really cool (and somewhat scary) patch ;)


>
> And if you are planning on attending, please give me a shout.
>

​It would be nice to attend and see you again, but unfortunately I am quite
swamped.  Will see.​

​Have fun in Barcelona!​

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

[Numpy-discussion] ANN: SciPy 0.19.0

[Evgeni Burovski]

On behalf of the Scipy development team I am pleased to announce the
availability of Scipy 0.19.0. This release contains several great new
features and a large number of bug fixes and various improvements, as
detailed in the release notes below.
121 people contributed to this release over the course of seven months.

Thanks to everyone who contributed!

This release requires Python 2.7 or 3.4-3.6 and NumPy 1.8.2 or
greater. Source tarballs and release notes can be found at
https://github.com/scipy/scipy/releases/tag/v0.19.0.

OS X and Linux wheels are available from PyPI. For security-conscious,
the wheels themselves are signed with my GPG key. Additionally, you
can checksum the wheels and verify the checksums with those listed
below or in the README file at
https://github.com/scipy/scipy/releases/tag/v0.19.0.

Cheers,

Evgeni



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

==
SciPy 0.19.0 Release Notes
==

.. contents::

SciPy 0.19.0 is the culmination of 7 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.6 and NumPy 1.8.2 or greater.

Highlights of this release include:

- - A unified foreign function interface layer, `scipy.LowLevelCallable`.
- - Cython API for scalar, typed versions of the universal functions from
  the `scipy.special` module, via `cimport scipy.special.cython_special`.


New features


Foreign function interface improvements
- ---

`scipy.LowLevelCallable` provides a new unified interface for wrapping
low-level compiled callback functions in the Python space. It supports
Cython imported "api" functions, ctypes function pointers, CFFI function
pointers, ``PyCapsules``, Numba jitted functions and more.
See `gh-6509 `_ for details.


`scipy.linalg` improvements
- ---

The function `scipy.linalg.solve` obtained two more keywords ``assume_a`` and
``transposed``. The underlying LAPACK routines are replaced with "expert"
versions and now can also be used to solve symmetric, hermitian and positive
definite coefficient matrices. Moreover, ill-conditioned matrices now cause
a warning to be emitted with the estimated condition number information. Old
``sym_pos`` keyword is kept for backwards compatibility reasons however it
is identical to using ``assume_a='pos'``. Moreover, the ``debug`` keyword,
which had no function but only printing the ``overwrite_`` values, is
deprecated.

The function `scipy.linalg.matrix_balance` was added to perform the so-called
matrix balancing using the LAPACK xGEBAL routine family. This can be used to
approximately equate the row and column norms through diagonal similarity
transformations.

The functions `scipy.linalg.solve_continuous_are` and
`scipy.linalg.solve_discrete_are` have numerically more stable algorithms.
These functions can also solve generalized algebraic matrix Riccati equations.
Moreover, both gained a ``balanced`` keyword to turn balancing on and off.

`scipy.spatial` improvements
- 

`scipy.spatial.SphericalVoronoi.sort_vertices_of_regions` has been re-written in
Cython to improve performance.

`scipy.spatial.SphericalVoronoi` can handle > 200 k points (at least 10 million)
and has improved performance.

The function `scipy.spatial.distance.directed_hausdorff` was
added to calculate the directed Hausdorff distance.

``count_neighbors`` method of `scipy.spatial.cKDTree` gained an ability to
perform weighted pair counting via the new keywords ``weights`` and
``cumulative``. See `gh-5647 `_ for
details.

`scipy.spatial.distance.pdist` and `scipy.spatial.distance.cdist` now support
non-double custom metrics.

`scipy.ndimage` improvements
- 

The callback function C API supports PyCapsules in Python 2.7

Multidimensional filters now allow having different extrapolation modes for
different axes.

`scipy.optimize` improvements
- -

The `scipy.optimize.basinhopping` global minimizer obtained a new keyword,
`seed`, which can be used to seed the random number generator and obtain
repeatable minimizations.

The keyword `sigma` in `scipy.optimize.curve_fit` was overloaded to also accept
the covariance matrix of errors in the data.

`scipy.signal` improvements
- ---

The function `scipy.signal.correlate` and `scipy.signal.convolve` have a new
optional parameter `method`. The 

[Numpy-discussion] PyData Barcelona this May

[Jaime Fernández del Río]

There will be a PyData conference in Barcelona this May:

http://pydata.org/barcelona2017/

I am planning on attending, and was thinking of maybe proposing to organize
a numpy-themed workshop or tutorial.

My personal inclination would be to look at some advanced topic that I know
well, like writing gufuncs in Cython, but wouldn't mind doing a more run of
the mill thing. Anyone has any thoughts or experiences on what has worked
well in similar situations? Any specific topic you always wanted to attend
a workshop on, but were afraid to ask?

Alternatively, or on top of the workshop, I could propose to do a talk:
talking last year at PyData Madrid about the new indexing was a lot of fun!
Thing is, I have been quite disconnected from the project this past year,
and can't really think of any worthwhile topic. Is there any message that
we as a project would like to get out to the larger community?

And if you are planning on attending, please give me a shout.

Thanks,

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] float16/32: wrong number of digits?

[Anne Archibald]

On Thu, Mar 9, 2017, 11:27 Nico Schlömer  wrote:

> Hi everyone,
>
> I wondered how to express a numpy float exactly in terms of format, and
> found `%r` quite useful: `float(repr(a)) == a` is guaranteed for Python
> `float`s. When trying the same thing with lower-precision Python floats, I
> found this identity not quite fulfilled:
> ```
> import numpy
> b = numpy.array([1.0 / 3.0], dtype=np.float16)
> float(repr(b[0])) - b[0]
> Out[12]: -1.953125093259e-06
> ```
> Indeed,
> ```
> b
> Out[6]: array([ 0.33325195], dtype=float16)
> ```
> ```
> repr(b[0])
> Out[7]: '0.33325'
> ```
> When counting the bits, a float16 should hold 4.8 decimal digits, so
> `repr()` seems right. Where does the garbage tail -1.953125093259e-06
> come from though?
>

Even more troubling, the high precision numpy types - np.longdouble and its
complex version - lose intimation when used with repr.

The basic problem is (roughly) that all floating-point numbers are
converted to python floats before printing. I put some effort into cleaning
this up, but the code is messy (actually there are several independent code
paths for converting numbers to strings) and the algorithms python uses to
make repr work out nicely are nontrivial.

Anne


> Cheers,
> Nico
> ___
> 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] float16/32: wrong number of digits?

[Nico Schlömer]

Hi everyone,

I wondered how to express a numpy float exactly in terms of format, and
found `%r` quite useful: `float(repr(a)) == a` is guaranteed for Python
`float`s. When trying the same thing with lower-precision Python floats, I
found this identity not quite fulfilled:
```
import numpy
b = numpy.array([1.0 / 3.0], dtype=np.float16)
float(repr(b[0])) - b[0]
Out[12]: -1.953125093259e-06
```
Indeed,
```
b
Out[6]: array([ 0.33325195], dtype=float16)
```
```
repr(b[0])
Out[7]: '0.33325'
```
When counting the bits, a float16 should hold 4.8 decimal digits, so
`repr()` seems right. Where does the garbage tail -1.953125093259e-06
come from though?

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

Re: [Numpy-discussion] Why do mgrid and meshgrid not return broadcast arrays?

[Per.Brodtkorb]

The reason for returning copies from meshgrid as default instead of views into 
to input arrays, was to not break backwards compatibility.
The old meshgrid returned copied arrays, which is safe if you need to write to 
those arrays.
If you use copy=False, a view into the original arrays are returned in order to
conserve memory, but will likely return non-contiguous  arrays.  Furthermore, 
more than one element of a broadcast array
may refer to a single memory location.

Per A

From: NumPy-Discussion [mailto:numpy-discussion-boun...@scipy.org] On Behalf Of 
Juan Nunez-Iglesias
Sent: 9. mars 2017 08:34
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Why do mgrid and meshgrid not return broadcast 
arrays?

Ah, fantastic, thanks Per!

I'd still be interested to hear from the core devs as to why this isn't the 
default, both with meshgrid and mgrid...

Juan.

On 9 Mar 2017, 6:29 PM +1100, 
per.brodtk...@ffi.no, wrote:

Hi, Juan.

Meshgrid can actually give what you want, but you must use the options: 
copy=False  and indexing=’ij’.

In [7]: %timeit np.meshgrid(np.arange(512), np.arange(512))
1000 loops, best of 3: 1.24 ms per loop

In [8]: %timeit np.meshgrid(np.arange(512), np.arange(512), copy=False)
1 loops, best of 3: 27 µs per loop

In [9]: %timeit np.meshgrid(np.arange(512), np.arange(512), copy=False, 
indexing='ij')
1 loops, best of 3: 23 µs per loop

Best regards
Per A. Brodtkorb

From: NumPy-Discussion [mailto:numpy-discussion-boun...@scipy.org] On Behalf Of 
Juan Nunez-Iglesias
Sent: 9. mars 2017 04:20
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Why do mgrid and meshgrid not return broadcast 
arrays?

Hi Warren,

ogrid doesn’t solve my problem. Note that my code returns arrays that would 
evaluate as equal to the mgrid output. It’s just that they are copied in mgrid 
into a giant array, instead of broadcast:


In [176]: a0, b0 = np.mgrid[:5, :5]

In [177]: a1, b1 = th.broadcast_mgrid((np.arange(5), np.arange(5)))

In [178]: a0
Out[178]:
array([[0, 0, 0, 0, 0],
   [1, 1, 1, 1, 1],
   [2, 2, 2, 2, 2],
   [3, 3, 3, 3, 3],
   [4, 4, 4, 4, 4]])

In [179]: a1
Out[179]:
array([[0, 0, 0, 0, 0],
   [1, 1, 1, 1, 1],
   [2, 2, 2, 2, 2],
   [3, 3, 3, 3, 3],
   [4, 4, 4, 4, 4]])

In [180]: a0.strides
Out[180]: (40, 8)

In [181]: a1.strides
Out[181]: (8, 0)



On 9 Mar 2017, 2:05 PM +1100, Warren Weckesser 
>, wrote:


On Wed, Mar 8, 2017 at 9:48 PM, Juan Nunez-Iglesias 
> wrote:
I was a bit surprised to discover that both meshgrid nor mgrid return fully 
instantiated arrays, when simple broadcasting (ie with stride=0 for other axes) 
is functionally identical and happens much, much faster.


Take a look at ogrid: 
https://docs.scipy.org/doc/numpy/reference/generated/numpy.ogrid.html
Warren
I wrote my own function to do this:


def broadcast_mgrid(arrays):
shape = tuple(map(len, arrays))
ndim = len(shape)
result = []
for i, arr in enumerate(arrays, start=1):
reshaped = np.broadcast_to(arr[[...] + [np.newaxis] * (ndim - i)],
   shape)
result.append(reshaped)
return result


For even a modest-sized 512 x 512 grid, this version is close to 100x faster:


In [154]: %timeit th.broadcast_mgrid((np.arange(512), np.arange(512)))
1 loops, best of 3: 25.9 µs per loop

In [156]: %timeit np.meshgrid(np.arange(512), np.arange(512))
100 loops, best of 3: 2.02 ms per loop

In [157]: %timeit np.mgrid[:512, :512]
100 loops, best of 3: 4.84 ms per loop


Is there a conscious design decision as to why this isn’t what meshgrid/mgrid 
do already? Or would a PR be welcome to do this?

Thanks,

Juan.

___
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 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