[Numpy-discussion] Daily numpy wheel builds - prefer to per-commit builds?

Hi, I've been working to get daily travis-ci cron-job manylinux builds working for numpy and scipy wheels. They are now working OK: https://travis-ci.org/MacPython/numpy-wheels https://travis-ci.org/MacPython/scipy-wheels

[Numpy-discussion] ANN: SfePy 2017.1

I am pleased to announce release 2017.1 of SfePy. Description --- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (limited support). It is distributed under

Re: [Numpy-discussion] Daily numpy wheel builds - prefer to per-commit builds?

On Tue, Feb 28, 2017 at 9:43 PM, Matthew Brett wrote: > Hi, > > I've been working to get daily travis-ci cron-job manylinux builds > working for numpy and scipy wheels. They are now working OK: > > https://travis-ci.org/MacPython/numpy-wheels >

[Numpy-discussion] Arrays and format()

Hi, Can someone take a look at: https://github.com/numpy/numpy/issues/7978 The crux of the issue is that this: # This works a = "%0.3g" % np.array(2) a '2' # This does not a = "{0:0.3g}".format(np.array(2)) TypeError: non-empty format string passed to object.__format__ I've now hit this in my

Re: [Numpy-discussion] Arrays and format()

See this issue: https://github.com/numpy/numpy/issues/5543 There was also a very thorough discussion of this recently on this mailing list: http://numpy-discussion.10968.n7.nabble.com/Proposal-to-support-format-td43931.html On Tue, Feb 28, 2017 at 11:32 AM Ryan May wrote: >

[Numpy-discussion] Numpy Overhead

Hello everyone, I'm interested in the numpy project and tried a lot with the numpy array. I'm wondering what is actually done that there is so much overhead when I call a function in Numpy. What is the reason? Thanks in advance. Regards Sebastian Kaster

Re: [Numpy-discussion] Numpy Overhead

Thank you for your answer. For example a very simple algorithm is a matrix multiplication. I can see that the heap peak is much higher for the numpy version in comparison to a pure python 3 implementation. The heap is measured with the libmemusage from libc: *heap peak*

Re: [Numpy-discussion] Arrays and format()

Gustav, I had seen this discussion, but completely blanked when I posted my problem. I looked over the proposal and nothing jumped out at me on a quick read-through; it seemed straightforward and would meet my needs. I'll try to carve out some time to think a bit more about it and let you know

Re: [Numpy-discussion] Numpy Overhead

You are going to need to provide much more context than that. Overhead compared to what? And where (io, cpu, etc.)? What are the size of your arrays, and what sort of operations are you doing? Finally, how much overhead are you seeing? There can be all sorts of reasons for overhead, and some can

Re: [Numpy-discussion] Numpy Overhead

It would really help to see the code you are using in both cases as well as some heap usage numbers... -Joe On Tue, Feb 28, 2017 at 5:12 PM, Sebastian K wrote: > Thank you for your answer. > For example a very simple algorithm is a matrix multiplication. I

Re: [Numpy-discussion] Numpy Overhead

Hi, On Tue, Feb 28, 2017 at 2:12 PM, Sebastian K wrote: > Thank you for your answer. > For example a very simple algorithm is a matrix multiplication. I can see > that the heap peak is much higher for the numpy version in comparison to a > pure python 3

Re: [Numpy-discussion] Numpy Overhead

Thank you! That is the information I needed. 2017-03-01 0:18 GMT+01:00 Matthew Brett : > Hi, > > On Tue, Feb 28, 2017 at 3:04 PM, Sebastian K > wrote: > > Yes you are right. There is no need to add that line. I deleted it. But > the > >

Re: [Numpy-discussion] Numpy Overhead

Yes it is true the execution time is much faster with the numpy function. The Code for numpy version: def createMatrix(n): Matrix = np.empty(shape=(n,n), dtype='float64') for x in range(n): for y in range(n): Matrix[x, y] = 0.1 + ((x*y)%1000)/1000.0 return Matrix if __name__ == '__main__': n

Re: [Numpy-discussion] Numpy Overhead

Hi, On Tue, Feb 28, 2017 at 3:04 PM, Sebastian K wrote: > Yes you are right. There is no need to add that line. I deleted it. But the > measured heap peak is still the same. You're applying the naive matrix multiplication algorithm, which is ideal for minimizing

Re: [Numpy-discussion] Numpy Overhead

For one thing, `C = np.empty(shape=(n,n), dtype='float64')` allocates 10^4 extra elements before being immediately discarded. -Joe On Tue, Feb 28, 2017 at 5:57 PM, Sebastian K wrote: > Yes it is true the execution time is much faster with the numpy

Re: [Numpy-discussion] Numpy Overhead

Yes you are right. There is no need to add that line. I deleted it. But the measured heap peak is still the same. 2017-03-01 0:00 GMT+01:00 Joseph Fox-Rabinovitz : > For one thing, `C = np.empty(shape=(n,n), dtype='float64')` allocates 10^4 > extra elements before being

Re: [Numpy-discussion] Daily numpy wheel builds - prefer to per-commit builds?

+1 as well. -- Olivier ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numpy Overhead

On Feb 28, 2017 2:57 PM, "Sebastian K" wrote: Yes it is true the execution time is much faster with the numpy function. The Code for numpy version: def createMatrix(n): Matrix = np.empty(shape=(n,n), dtype='float64') for x in range(n): for y in range(n):

Re: [Numpy-discussion] Arrays and format()

I am hoping to submit a PR for a __format__ numpy enhancement proposal this weekend. I will be a slightly revised version of my original draft posted here two weeks ago. Ryan, if you have any thoughts on the writeup so far, I'd