Re: [Numpy-discussion] Numpy 1.11.0b1 is out

[Sebastian Berg]

On Sa, 2016-01-30 at 20:27 +0100, Derek Homeier wrote:
> On 27 Jan 2016, at 1:10 pm, Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > 
> > On Mi, 2016-01-27 at 11:19 +, Nadav Horesh wrote:
> > > Why the dot function/method is slower than @ on python 3.5.1?
> > > Tested
> > > from the latest 1.11 maintenance branch.
> > > 
> > 
> > The explanation I think is that you do not have a blas
> > optimization. In
> > which case the fallback mode is probably faster in the @ case
> > (since it
> > has SSE2 optimization by using einsum, while np.dot does not do
> > that).
> 
> I am a bit confused now, as A @ c is just short for A.__matmul__(c)
> or equivalent
> to np.matmul(A,c), so why would these not use the optimised blas?
> Also, I am getting almost identical results on my Mac, yet I thought
> numpy would
> by default build against the VecLib optimised BLAS. If I build
> explicitly against
> ATLAS, I am actually seeing slightly slower results.
> But I also saw these kind of warnings on the first timeit runs:
> 
> %timeit A.dot(c)
> The slowest run took 6.91 times longer than the fastest. This could
> mean that an intermediate result is being cached
> 
> and when testing much larger arrays, the discrepancy between matmul
> and dot rather
> increases, so perhaps this is more an issue of a less memory
> -efficient implementation
> in np.dot?

Sorry, I missed the fact that one of the arrays was 3D. In that case I
am not even sure which if the functions call into blas or what else
they have to do, would have to check. Note that `np.dot` uses a
different type of combinging high dimensional arrays. @/matmul
broadcasts extra axes, while np.dot will do the outer combination of
them, so that the result is:

As = A.shape
As.pop(-1)
cs = c.shape
cs.pop(-2)  # if possible
result_shape = As + cs

which happens to be identical if only A.ndim > 2 and c.ndim <= 2.

- Sebastian


> 
> Cheers,
>   Derek
> 
> ___
> 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] Numpy 1.11.0b2 released

[Julian Taylor]

On 01/30/2016 06:27 PM, Ralf Gommers wrote:
> 
> 
> On Fri, Jan 29, 2016 at 11:39 PM, Nathaniel Smith  > wrote:
> 
> It occurs to me that the best solution might be to put together a
> .travis.yml for the release branches that does: "for pkg in
> IMPORTANT_PACKAGES: pip install $pkg; python -c 'import pkg;
> pkg.test()'"
> This might not be viable right now, but will be made more viable if
> pypi starts allowing official Linux wheels, which looks likely to
> happen before 1.12... (see PEP 513)
> 
> On Jan 29, 2016 9:46 AM, "Andreas Mueller"  > wrote:
> >
> > Is this the point when scikit-learn should build against it?
> 
> Yes please!
> 
> > Or do we wait for an RC?
> 
> This is still all in flux, but I think we might actually want a rule
> that says it can't become an RC until after we've tested
> scikit-learn (and a list of similarly prominent packages). On the
> theory that RC means "we think this is actually good enough to
> release" :-). OTOH I'm not sure the alpha/beta/RC distinction is
> very helpful; maybe they should all just be betas.
> 
> > Also, we need a scipy build against it. Who does that?
> 
> Like Julian says, it shouldn't be necessary. In fact using old
> builds of scipy and scikit-learn is even better than rebuilding
> them, because it tests numpy's ABI compatibility -- if you find you
> *have* to rebuild something then we *definitely* want to know that.
> 
> > Our continuous integration doesn't usually build scipy or numpy, so it 
> will be a bit tricky to add to our config.
> > Would you run our master tests? [did we ever finish this discussion?]
> 
> We didn't, and probably should... :-)
> 
> Why would that be necessary if scikit-learn simply tests pre-releases of
> numpy as you suggested earlier in the thread (with --pre)?
> 
> There's also https://github.com/MacPython/scipy-stack-osx-testing by the
> way, which could have scikit-learn and scikit-image added to it.
> 
> That's two options that are imho both better than adding more workload
> for the numpy release manager. Also from a principled point of view,
> packages should test with new versions of their dependencies, not the
> other way around.


It would be nice but its not realistic, I doubt most upstreams that are
not themselves major downstreams are even subscribed to this list.

Testing or delegating testing of least our major downstreams should be
the job of the release manager.
Thus I also disagree with our more frequent releases. It puts too much
porting and testing effort on our downstreams and it gets infeaseble for
a volunteer release manager to handle.
I fear by doing this we will end up in an situation where more
downstreams put upper bounds on their supported numpy releases like e.g.
astropy already did.
This has bad consequences like the subclass breaking of linspace that
should have been caught month ago but was not because upstreams were
discouraging users from upgrading numpy because they could not keep up
with porting.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Downstream integration testing

[Pauli Virtanen]

31.01.2016, 12:57, Julian Taylor kirjoitti:
[clip]
> Testing or delegating testing of least our major downstreams should be
> the job of the release manager.
> Thus I also disagree with our more frequent releases. It puts too much
> porting and testing effort on our downstreams and it gets infeaseble for
> a volunteer release manager to handle.
> I fear by doing this we will end up in an situation where more
> downstreams put upper bounds on their supported numpy releases like e.g.
> astropy already did.
> This has bad consequences like the subclass breaking of linspace that
> should have been caught month ago but was not because upstreams were
> discouraging users from upgrading numpy because they could not keep up
> with porting.

I'd suggest that some automation could reduce the maintainer burden
here. Basically, I think being aware of downstream breakage is something
that could be determined without too much manual intervention.

For example, automated test rig that does the following:

- run tests of a given downstream project version, against
  previous numpy version, record output

- run tests of a given downstream project version, against
  numpy master, record output

- determine which failures were added by the new numpy version

- make this happen with just a single command, eg "python run.py",
  and implement it for several downstream packages and versions.
  (Probably good to steal ideas from travis-ci dependency matrix etc.)

This is probably too time intensive and waste of resources for
Travis-CI, but could be run by the Numpy maintainer or someone else
during release process, or periodically on some ad-hoc machine if
someone is willing to set it up.

Of course, understanding the cause of breakages would take some
understanding of the downstream package, but this would at least ensure
we are aware of stuff breaking. Provided it's covered by downstream test
suite, of course.

-- 
Pauli Virtanen

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

Re: [Numpy-discussion] Downstream integration testing

[Daπid]

On 31 Jan 2016 13:08, "Pauli Virtanen"  wrote:
> For example, automated test rig that does the following:
>
> - run tests of a given downstream project version, against
>   previous numpy version, record output
>
> - run tests of a given downstream project version, against
>   numpy master, record output
>
> - determine which failures were added by the new numpy version
>
> - make this happen with just a single command, eg "python run.py",
>   and implement it for several downstream packages and versions.
>   (Probably good to steal ideas from travis-ci dependency matrix etc.)

A simpler idea: build the master branch of a series of projects and run the
tests. In case of failure, we can compare with Travis's logs from the
project when they use the released numpy. In most cases, the master branch
is clean, so an error will likely be a change in behaviour.

This can be run automatically once a week, to not hog too much of Travis,
and counting the costs in hours of work, is very cheap to set up, and free
to maintain.

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

Re: [Numpy-discussion] Downstream integration testing

[Pauli Virtanen]

31.01.2016, 14:41, Daπid kirjoitti:
> On 31 Jan 2016 13:08, "Pauli Virtanen"  wrote:
>> For example, automated test rig that does the following:
>>
>> - run tests of a given downstream project version, against
>>   previous numpy version, record output
>>
>> - run tests of a given downstream project version, against
>>   numpy master, record output
>>
>> - determine which failures were added by the new numpy version
>>
>> - make this happen with just a single command, eg "python run.py",
>>   and implement it for several downstream packages and versions.
>>   (Probably good to steal ideas from travis-ci dependency matrix etc.)
> 
> A simpler idea: build the master branch of a series of projects and run the
> tests. In case of failure, we can compare with Travis's logs from the
> project when they use the released numpy. In most cases, the master branch
> is clean, so an error will likely be a change in behaviour.

If you can assume the tests of a downstream project are in an OK state,
then you can skip the build against existing numpy.

But it's an additional and unnecessary burden for the Numpy maintainers
to compare the logs manually (and check the built versions are the same,
and that the difference is not due to difference in build environments).
I would also avoid depending on the other projects' Travis-CI
configurations, since these may change.

I think testing released versions of downstream projects is better than
testing their master versions here, as the master branch may contain
workarounds for Numpy changes and not be representative of what people
get on their computers after Numpy release.

> This can be run automatically once a week, to not hog too much of Travis,
> and counting the costs in hours of work, is very cheap to set up, and free
> to maintain.

It may be that such project could be runnable on Travis, if split to
per-project runs to work around the 50min timeout.

I'm not aware of Travis-CI having support for "automatically once per
week" builds.

Anyway, having any form of central automated integration testing would
be better than the current situation where it's mostly all-manual and
relies on the activity of downstream project maintainers.

-- 
Pauli Virtanen

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

[Numpy-discussion] Numpy pull requests getting out of hand.

[Charles R Harris]

Hi All,

There are now 130 open numpy pull requests and it seems almost impossible
to keep that number down. My personal decision is that I am going to ignore
any new enhancements for the next couple of months and only merge bug
fixes, tests, house keeping (style, docs, deprecations), and old PRs. I
would also request that other maintainers start looking a taking care of
older PRs, either cleaning them up and merging, or closing them.

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

Re: [Numpy-discussion] Numpy pull requests getting out of hand.

[Jeff Reback]

FYI also useful to simply close by time - say older than 6 months with a 
message for the writer to reopen if they want to work on it

then u don't get too many stale ones 

my 2c

> On Jan 31, 2016, at 2:10 PM, Charles R Harris  
> wrote:
> 
> Hi All,
> 
> There are now 130 open numpy pull requests and it seems almost impossible to 
> keep that number down. My personal decision is that I am going to ignore any 
> new enhancements for the next couple of months and only merge bug fixes, 
> tests, house keeping (style, docs, deprecations), and old PRs. I would also 
> request that other maintainers start looking a taking care of older PRs, 
> either cleaning them up and merging, or closing them.
> 
> Chuck
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numpy 1.11.0b2 released

[Marten van Kerkwijk]

Hi Julian,

While the numpy 1.10 situation was bad, I do want to clarify that the
problems we had in astropy were a consequence of *good* changes in
`recarray`, which solved many problems, but also broke the work-arounds
that had been created in `astropy.io.fits` quite a long time ago (possibly
before astropy became as good as it tries to be now at moving issues
upstream and perhaps before numpy had become as responsive to what happens
downstream as it is now; I think it is fair to say many project's attitude
to testing has changed rather drastically in the last decade!).

I do agree, though, that it just goes to show one has to try to be careful,
and like Nathaniel's suggestion of automatic testing with pre-releases -- I
just asked on our astropy-dev list whether we can implement it.

All the best,

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