[SciPy-Dev] scikit-signal or Similar
Wed Feb 8 15:37:11 CST 2012
On 02/06/12 03: 13, Stuart Mumford wrote:
> Sorry - I've been off the list for awhile as I was transitioning to my
> first 'real world' job. Now that I'm back - hello! This was my first
> attempt at object oriented programming - I'll need to take a look
> at the
> code again to see what I was (or was not) thinking at the time :-)
> Nice to have you around to help and I am glad you now have some time
> to help out! For a first attempt at OOP it's very good! (well much
> better than my first attempt was!) I was thinking about how would be
> best to implement it, we want to try and mirror as closely as possible
> the calling sequence of PyWavelets and it's DWT routines. They use the
> approach of
> >>> cA, cD = pywt.dwt(data,mother)
> where mother is either a string or an instance of a mother class.
I completely agree.
> So I was thinking would the best code structure to be have a "Wavelet"
> class which is subclassed for cwt, icwt ccwt etc. and a Mother class
> which is subclassed for each family like Morlet, DOG etc.
> Then into the Wavelet instance you can pass either a subclass of
> mother or a string and go from there.
> This is pretty close to how your code is structured at the moment,
> just need to make the main cwt etc. functions subclasses of Wavelet?
Yes, I think that will work nicely.
> As for results I think it would be best to return a class when cwt
> etc. is called and then have attributes such as power, data,
> coefficients etc.
> wave = scipy.signal.wavelet.cwt.cwt(data,'morlet')
> pwr = wave.power
That makes sense too.
> > I shall work on improving that code, I can implement more and
> more general
> > Mother wavelets and also write some examples and update the plotting
> > routine to use mpl's make_axes_locatable if people think that is
> a better
> > way to go.
> I'd be happy to start working on this again. I'm still finishing up my
> PhD, but I am now working as a developer at UCAR / Unidata and
> have some
> time I can officially spend on 'guerrilla projects' like this
> (especially since it can/will benefit the atmospheric science
> I am also doing a Solar Physics PhD so this stuff gets used in lots of
> places!! I think as a todo list things that need doing are:
> * Agree on a calling and code structure and implement.
Would you like to do the quick restructure?
> * Implement other wavelet families and make all general in order m (ie
> Mexican hat is just m=2 of DOG)
I started on that path, but ran into a few speed bumps because the
admissibility constants can be quite tricky to determine without using
numerical integration. Maybe not too big of a deal in reality, but the
two mother wavelets I implemented did the trick for my dissertation needs.
> * Implement a significance contouring routine.
This was on my to-do list as well. However, I don't think we need to
implement a contouring routine for SciPy, as that should go to
Matplotlib or a wavelet cookbook (let's not worry too much about that
right now - we can use what's there for testing and strip it out later).
> * Develop some tests to show it works!
I've been wanting to come up with some simple analytical tests but just
have not had time. You are welcome to take a crack at that, but I will
eventually get to it.
> There will probably be many little things to find on the way along,
> but I think they are the major points? One other question, do we want
> a plotting routine inside the module or keep it as an example in the
> documentation? I ask because I don't know what is the norm.
> SciPy-Dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev