Re: [Numpy-discussion] f2py, numpy.distutils and multiple Fortran source files

On Thu, Dec 3, 2015 at 4:07 PM David Verelst wrote: > Hi, > > For the wafo [1] package we are trying to include the extension > compilation process in setup.py [2] by using setuptools and > numpy.distutils [3]. Some of the extensions have one Fortran interface > source file, but it depends on sev

Re: [Numpy-discussion] future of f2py and Fortran90+

On Tue, Jul 14, 2015 at 10:13 PM Sturla Molden wrote: > Eric Firing wrote: > > > I'm curious: has anyone been looking into what it would take to enable > > f2py to handle modern Fortran in general? And into prospects for > > getting such an effort funded? > > No need. Use Cython and Fortran 200

Re: [Numpy-discussion] When to stop supporting Python 2.6?

pandas is going to drop 2.6 and 3.3 next release at end of Jan (3.2 dropped in 0.17, in October) I can be reached on my cell 917-971-6387 > On Dec 3, 2015, at 6:00 PM, Bryan Van de Ven wrote: > > >> On Dec 3, 2015, at 4:59 PM, Eric Firing wrote: >> >> Chuck, >> >> I would support droppin

Re: [Numpy-discussion] When to stop supporting Python 2.6?

> On Dec 3, 2015, at 4:59 PM, Eric Firing wrote: > > Chuck, > > I would support dropping the old versions now. As a related data point, > matplotlib is testing master on 2.7, 3.4, and 3.5--no more 2.6 and 3.3. Ditto for Bokeh. ___ NumPy-Discussion

Re: [Numpy-discussion] When to stop supporting Python 2.6?

On 2015/12/03 12:47 PM, Charles R Harris wrote: Hi All, Thought I would raise the topic apropos this post . There is not a great advantage to dropping 2.6, OTOH, 2.7 has more features (memoryview) and we could clean u

[Numpy-discussion] When to stop supporting Python 2.6?

Hi All, Thought I would raise the topic apropos this post . There is not a great advantage to dropping 2.6, OTOH, 2.7 has more features (memoryview) and we could clean up the code a bit. Along the same lines, dropping

Re: [Numpy-discussion] future of f2py and Fortran90+

On 2015/12/03 11:08 AM, Yuxiang Wang wrote: Too add to Sturla - I think this is what he mentioned but in more details: http://www.fortran90.org/src/best-practices.html#interfacing-with-python Right, but for each function that requires writing two wrappers, one in Fortran and a second one in c

Re: [Numpy-discussion] future of f2py and Fortran90+

Too add to Sturla - I think this is what he mentioned but in more details: http://www.fortran90.org/src/best-practices.html#interfacing-with-python Shawn On Tue, Jul 14, 2015 at 9:45 PM, Sturla Molden wrote: > Eric Firing wrote: > >> I'm curious: has anyone been looking into what it would take

[Numpy-discussion] f2py, numpy.distutils and multiple Fortran source files

Hi, For the wafo [1] package we are trying to include the extension compilation process in setup.py [2] by using setuptools and numpy.distutils [3]. Some of the extensions have one Fortran interface source file, but it depends on several other Fortran sources (modules). The manual compilation proc

Re: [Numpy-discussion] future of f2py and Fortran90+

f90wrap [1] extends the functionality of f2py, and can automatically generate sensible wrappers for certain cases. [1] https://github.com/jameskermode/f90wrap On 15 July 2015 at 03:45, Sturla Molden wrote: > Eric Firing wrote: > > > I'm curious: has anyone been looking into what it would take t

Re: [Numpy-discussion] Recognizing a cycle in a vector

On 12/03/15 at 05:39am, Eric Firing wrote: > On 2015/12/02 10:45 PM, Manolo Martínez wrote: > >1) this func sorts the absolute value of the amplitudes to find the two > >most important components, and this seems overkill for large vectors. > > Try > > inds = np.argpartition(-np.abs(ft), 2)[:2] >

Re: [Numpy-discussion] Recognizing a cycle in a vector

On 12/03/15 at 12:50pm, Oscar Benjamin wrote: > In terms of out of the box software I can recommend auto and xpp. Each > is esoteric and comes with a clunky interface. XPP has a strange GUI > and auto is controlled through Python bindings using IPython as > frontend. Thanks again, Oscar. I'll tr

Re: [Numpy-discussion] Recognizing a cycle in a vector

On 2015/12/02 10:45 PM, Manolo Martínez wrote: 1) this func sorts the absolute value of the amplitudes to find the two most important components, and this seems overkill for large vectors. Try inds = np.argpartition(-np.abs(ft), 2)[:2] Now inds holds the indices of the two largest components

Re: [Numpy-discussion] Recognizing a cycle in a vector

On 3 December 2015 at 11:58, Manolo Martínez wrote: >> > This is doing the job for me at the moment, but there are, that I can >> > see, a couple of things that could be improved (and surely more that I >> > cannot see): > >> If what you have works out fine for you then feel free to ignore this bu

Re: [Numpy-discussion] Recognizing a cycle in a vector

Dear Oscar, > > > This is doing the job for me at the moment, but there are, that I can > > see, a couple of things that could be improved (and surely more that I > > cannot see): > If what you have works out fine for you then feel free to ignore this but... > [snip] Talk about things I cannot

Re: [Numpy-discussion] Recognizing a cycle in a vector

On 3 December 2015 at 08:45, Manolo Martínez wrote: >> > >> Is there any way to check for cycles in this situation? >> > >> > > Fast fourier transform (fft)? >> > >> > +1 For using a discrete Fourier transform, as implemented by numpy.fft.fft. >> > You mentioned that you sample at points which do

Re: [Numpy-discussion] Recognizing a cycle in a vector

> > >> Is there any way to check for cycles in this situation? > > > > > Fast fourier transform (fft)? > > > > +1 For using a discrete Fourier transform, as implemented by numpy.fft.fft. > > You mentioned that you sample at points which do not correspond with the > > period of the signal; this in