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): Matrix[x, y] = 0.1 + ((x*y)%1000)/1000.

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

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 > > measured heap peak is still the same. > > You're applying t

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 memory use during the computation

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 immediately discarded. > >

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 function. > > The Code for numpy version:

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 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 implementation. > The heap is measured with

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 can see > that the heap peak is mu

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] 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 e

[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] 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 i

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 lov

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: > Hi, > > Can someon

[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

[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 t

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 > https://travis-ci.org/MacPython/scipy-wheels > htt

[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 https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rac