Re: [Numpy-discussion] Building master issues on Windows

[G Young]

Hello all,

Turns out I needed to do a complete re-installation of essentially
everything that was involved in my Numpy setup.  Now everything is working
just fine!

Cheers,

Greg

On Tue, Jan 5, 2016 at 7:45 AM, G Young  wrote:

> Sure.  I'm running Windows 7 with Python 2.7.11, gcc 4.8.1, and GNU
> Fortran 5.2.0.  It's very similar to the Appveyor Python 2 build.  When I
> am in the numpy root directory, I run "*python setup.py build_ext -i*".
> I've attached the output I get from the terminal.  Perhaps that might
> illuminate some issues that I'm not seeing.
>
> Greg
>
> On Mon, Jan 4, 2016 at 8:17 PM, Jaime Fernández del Río <
> jaime.f...@gmail.com> wrote:
>
>> On Tue, Jan 5, 2016 at 3:15 AM, G Young  wrote:
>>
>>> Hello all,
>>>
>>> I've recently encountered issues building numpy off master on Windows in
>>> which setup.py complains that it can't find the Advapi library in any
>>> directories (which is an empty list).  I scanned the DLL under System32 and
>>> ran /sfc scannow as Administrator, and both came up clean.  Is anyone else
>>> encountering (or can reproduce) this issue, or is it just me?  Any
>>> suggestions about how to resolve this problem?
>>>
>>
>> Can you give more details on your setup?
>>
>> 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
>>
>>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Numpy 1.10.4 release.

[Charles R Harris]

Hi All,

I'm pleased the release of the Numpy 1.10.4 (bugs stomped) release. This
release was motivated by a reported segfault, but a few additional fixes
were made:

* gh-6922 BUG: numpy.recarray.sort segfaults on Windows,
* gh-6937 BUG: busday_offset does the wrong thing with modifiedpreceding
roll,
* gh-6949 BUG: Type is lost when slicing a subclass of recarray,

together with one minor enhancement

* gh-6950 BUG trace is not subclass aware, np.trace(ma) != ma.trace().

The sources and documentation are available on Sourceforge, but no
binaries. The usual windows binaries were ommitted due to problems with the
toolchain. We hope that will be remedied in the future. Mac binaries can be
installed from pypi.

"Where is numpy 1.10.3?", you may ask. There were glitches with the uploads
to pypi for that version that necessitated a version upgrade. A release
manager's life is not a happy one.

Many thanks to  Marten van Kerkwijk, Sebastian Seberg, and Mark Wiebe for
the quick bug fixes.

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

Re: [Numpy-discussion] Numpy 1.10.4 release.

[Charles R Harris]

On Thu, Jan 7, 2016 at 12:01 PM, Erik Bray 
wrote:

> On Thu, Jan 7, 2016 at 1:39 PM, Charles R Harris
>  wrote:
>
> > "Where is numpy 1.10.3?", you may ask. There were glitches with the
> uploads
> > to pypi for that version that necessitated a version upgrade. A release
> > manager's life is not a happy one.
>
> Ah, okay, I was confused about that when I pip installed Numpy just a
> few minutes ago :)
>
> Has the Numpy project opted to not do .postN releases?  I'm curious
> since I had to do one of these for Astropy recently and it was not the
> most pleasant experience...
>

Yes, we opted out after an experience of trying to fix up the 1.10.0
release uploads (not signed) with a `.post1` release. The main problem for
us was that NumpyVersion did not deal with that form, plus pypi went ahead
and created a new release, so it was simpler to just make a real new
release.


> Anyways thanks for the release!
>

I confess to being a bit nervous about not making an rc release. Of course,
no one tests those anyway ;) Let us know how things work out.

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

[Numpy-discussion] ANN: second release candidate for scipy 0.17.0

[Evgeni Burovski]

Hi,

I'm pleased to announce the availability of the second release
candidate for Scipy 0.17.0. It's two days ahead of the original
schedule: based on typical development patterns, I'd like to have two
weekends and a full working week before January 17th, when this rc2 is
supposed to become the final release.

Please try this rc and report any issues on Github tracker or
scipy-dev mailing list.
Source tarballs and full release notes are available from Github
Releases: https://github.com/scipy/scipy/releases/tag/v0.17.0rc2

Compared to rc1, the following PRs were merged:

- - `#5624 `__: FIX: Fix interpolate
- - `#5625 `__: BUG: msvc9
binaries crash when indexing std::vector of size 0
- - `#5635 `__: BUG:
misspelled __dealloc__ in cKDTree.
- - `#5642 `__: STY: minor
fixup of formatting of 0.17.0 release notes.
- - `#5643 `__: BLD: fix a
build issue in special/Faddeeva.cc with isnan.
- - `#5661 `__: TST: linalg
tests used stdlib random instead of numpy.random.

There is a bit of an unusual change in this rc. In short, in testing
rc1 we found that 1) interpolate.interp1d had an undocumented feature
of allowing an array-valued fill_value to be broadcast against the
data being interpolated, and  2) we broke it in 0.17.0rc1. (See PR
5624 for details.)
We now *think* we fixed it so that no existing code is broken.
Nevertheless, I would like to encourage everyone to test their code
against this rc2, especially all code which uses interp1d.

Cheers,

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

[Numpy-discussion] Should I use pip install numpy in linux?

[Yuxiang Wang]

Dear all,

I know that in Windows, we should use either Christoph's package or
Anaconda for MKL-optimized numpy. In Linux, the fortran compiler issue
is solved, so should I directly used pip install numpy to get numpy
with a reasonable BLAS library?

Thanks!

Shawn

-- 
Yuxiang "Shawn" Wang
Gerling Haptics Lab
University of Virginia
yw...@virginia.edu
+1 (434) 284-0836
https://sites.google.com/a/virginia.edu/yw5aj/
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should I use pip install numpy in linux?

[Nathaniel Smith]

On Thu, Jan 7, 2016 at 6:18 PM, Yuxiang Wang  wrote:
> Dear all,
>
> I know that in Windows, we should use either Christoph's package or
> Anaconda for MKL-optimized numpy. In Linux, the fortran compiler issue
> is solved, so should I directly used pip install numpy to get numpy
> with a reasonable BLAS library?

pip install numpy should work fine; whether it gives you a reasonable
BLAS library will depend on whether you have the development files for
a reasonable BLAS library installed, and whether numpy's build system
is able to automatically locate them. Generally this means that if
you're on a regular distribution and remember to install a decent BLAS
-dev or -devel package, then you'll be fine.

On Debian/Ubuntu, 'apt install libopenblas-dev' is probably enough to
ensure something reasonable happens.

Anaconda is also an option on linux if you want MKL (or openblas).

-n

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

Re: [Numpy-discussion] ANN: second release candidate for scipy 0.17.0

[Matthew Brett]

Hi,

On Thu, Jan 7, 2016 at 11:24 PM, Evgeni Burovski
 wrote:
> Hi,
>
> I'm pleased to announce the availability of the second release
> candidate for Scipy 0.17.0. It's two days ahead of the original
> schedule: based on typical development patterns, I'd like to have two
> weekends and a full working week before January 17th, when this rc2 is
> supposed to become the final release.
>
> Please try this rc and report any issues on Github tracker or
> scipy-dev mailing list.
> Source tarballs and full release notes are available from Github
> Releases: https://github.com/scipy/scipy/releases/tag/v0.17.0rc2
>
> Compared to rc1, the following PRs were merged:
>
> - - `#5624 `__: FIX: Fix interpolate
> - - `#5625 `__: BUG: msvc9
> binaries crash when indexing std::vector of size 0
> - - `#5635 `__: BUG:
> misspelled __dealloc__ in cKDTree.
> - - `#5642 `__: STY: minor
> fixup of formatting of 0.17.0 release notes.
> - - `#5643 `__: BLD: fix a
> build issue in special/Faddeeva.cc with isnan.
> - - `#5661 `__: TST: linalg
> tests used stdlib random instead of numpy.random.
>
> There is a bit of an unusual change in this rc. In short, in testing
> rc1 we found that 1) interpolate.interp1d had an undocumented feature
> of allowing an array-valued fill_value to be broadcast against the
> data being interpolated, and  2) we broke it in 0.17.0rc1. (See PR
> 5624 for details.)
> We now *think* we fixed it so that no existing code is broken.
> Nevertheless, I would like to encourage everyone to test their code
> against this rc2, especially all code which uses interp1d.

Thanks for doing this.  Testing builds of OSX wheels via
https://github.com/MacPython/scipy-wheels, I found this problem :
https://github.com/scipy/scipy/issues/5689

Cheers,

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

Re: [Numpy-discussion] ENH: Add the function 'expand_view'

[John Kirkham]

First, off sorry for the long turnaround on responding to these
questions. Below I have tried to respond to everyone's questions and
comments. I have restructured the order of the messages so that my
responses are a little more structured. If anybody has more thoughts
or questions, please let me know.


 Takes an array and tacks on arbitrary dimensions on either side, which
>>> is returned as a view always. Here are the relevant features:

 * Creates a view of the array that has the dimensions before and after
>>> tacked on to it.
 * Takes the before and after arguments independent of each other and
>>> the current shape.
 * Allows for read and write access to the underlying array.
>>>
>>> Can you expand this with some discussion of why you want this function,
>>> and why you chose these specific features? (E.g. as mentioned in the PR
>>> comments already, the reason broadcast_to returns a read-only array is that
>>> it was decided that this was less confusing for users, not because of any
>>> technical issue.)

Sometimes I find that broadcasting is insufficient or gets confused
with some more complex cases. Even adding the extra dimensions using
`np.newaxis`/`None` doesn't always cut it. So, being able to add the
dimensions with the right shape and without copying is very nice.
However, I wanted to do this in a way where this would always be a
view onto the original data to avoid any copying penalty.

It also came in handy when I didn't know how many dimensions I would
be dealing with. The alternative would be to do something doing things
like `a[..., (b.ndim-1)*(None,)]` and possibly something similar with
`b`, which end up being pretty gross and unreadable as opposed to
doing `expand_view(a, reps_after=b.shape[1:])`, which is quite clear.
The latter also conveys to reader what those dimensions are doing.

Finally in cases where `None` or `np.newaxis` work fine, it is
possible for you to combine them in some operation you are doing in
way which you did not intend. If broadcasting would have worked in
this case, you won't get an error, but you will get the wrong answer,
which you may discover later than you would like. When using
`expand_view` an explicit shape can be set, which when mismatched will
give you an error allowing you discover the problem as soon as you run
the code as opposed after when you are trying to figure out your
answer is wrong.

The write option I never actually use so making it readonly is fine. I
just never blocked that behavior. Perhaps it would be preferable as
has been suggested.

Ensuring a view is nice because this remains performant for large
arrays. Using a view seems reasonable here based on the fact that we
are never trying to restructure the data here. Instead, we are trying
to make it appear as if its shape were different.


> How is this different from using np.newaxis and broadcasting? Or am I
> misunderstanding this?

I hope the description above also helps clarify this a bit. To be more
succinct and explicit:

* This can always be used even when broadcasting may get confused.
* Works cleanly and easily with variable numbers of dimensions unlike
`np.newaxis`/`None`.
* Using explicit shapes more tightly constrains behavior with the
resulting view (helping catch bugs).
* Provides the reader more information about how the other dimensions
should work.


>> Why is this a stride_trick?
>>
>> I thought this looks similar to expand_dims and could maybe be implemented
>> with some extra options there.

So, `expand_dims` adds a single dimension with a length of 1 where
specified, but not multiple. Though I am going to infer by extra
options you mean change it some way that it can add multiple axes.

Though I suppose you could do this and it may even be worth pursing,
it ends up being a similar idea to using `np.newaxis`/`None` a few
times and so I have basically the same points to make here as I made
in the last section's response.

Also, I feel like using `expand_dims` with more axes specified might
make it a little harder to follow than just using `np.newaxis`/`None`,
but it could have its merrits.

>From a performance standpoint, `expand_dims` using `reshape` to add
these extra dimensions. So, it has the possibility of not returning a
view, but a copy, which could take some time to build if the array is
large. By using our method, we guarantee a view will always be
returned; so, this allocation will never be encountered.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion