WIP: API and type hierarchy

[gummif]

API suggestion for high level functions: For DiscreteWavelet boundary treatment is controlled by type parameter T<:WaveletBoundary. For cwtft boundaries are naturally periodic and for cwt boundaries are specified explicitly as an input.

# for DWT (discrete wavelet transform)
dwt(::AbstractVector, ::DiscreteWavelet)
idwt(::AbstractVector, ::DiscreteWavelet)

# for SWT (stationary wavelet transform)
swt(::AbstractVector, ::DiscreteWavelet)
iswt(::AbstractVector, ::DiscreteWavelet)

# for WPT (wavelet packet transform)
wpt(::AbstractVector, ::DiscreteWavelet)
iwpt(::AbstractVector, ::DiscreteWavelet)

# for CWT (continuous wavelet transform)
cwt(::AbstractVector, ::ContinuousWavelet)
icwt(::AbstractVector, ::ContinuousWavelet)

# for CWTFT (continuous wavelet transform via FFT)
cwtft(::AbstractVector, ::ContinuousWavelet)
icwtft(::AbstractVector, ::ContinuousWavelet)

The wavelet type structure under abstract WaveletType. Strikethrough types are not included in the package (yet).

• abstract FilterWavelet
  • OrthoFilter
  • BiOrthoFilter
• abstract LSWavelet
  • GLS
• abstract ContinuousWavelet
  • abstract MotherWavelet (maybe?)
• typealias DiscreteWavelet Union(FilterWavelet, LSWavelet)

The type parameter (e.g. OrthoFilter{T<:WaveletBoundary}) determines the treatment of boundary extensions. PerBoundary is default.

The wavelet types are created either directly (OrthoFilter{T<:WaveletBoundary}(name::String)) or using the wavelet contructors.

wavelet(name::String; transform::String="filter", boundary::String="per")
waveletfilter(name::String; boundary::String="per")
waveletls(name::String; boundary::String="per")
#waveletcontinuous(name::String; boundary::String="per")

Both can also accept input of type (class::String, n::Union(Integer,String)).

I believe this is a quite intuitive and simple API which is consistent for all transforms. Having boundary types as a parameter is also in the style of julia and can potentially simplify some of the code. Suggestions and criticism welcome.

[simonster]

What's the rationale for having two ways to construct the wavelet types? I would prefer just to create them directly. Also for continuous wavelets the scales (or frequencies or periods) and wavenumber must be specifiable. Otherwise, this looks good to me, although my knowledge of discrete wavelets is limited.

[gummif]

Well, for those who might not be familiar with what kind of wavelet a cdf9/7 is, it can be constructed in a user friendly way with wavelet("cdf9/7"). It can e.g. not be constructed using OrthoFilter("cdf9/7"), but rather BiOrthoFilter("cdf9/7"). But I guess it is not stricly necessary.

I'm not sure what you mean, but your cwt code could be used almost verbatim, with minor changes:

abstract MotherWavelet{T<:Real} <: ContinuousWavelet{T}
# or maybe replace all MotherWavelet by ContinuousWavelet
function cwtft{T <: Real}(signal::Vector{T}, w::ContinuousWavelet{T}, fs::Real=1)
    t = ContinuousWaveletTransform(w, nextfastfft(length(signal)), fs)
    evaluate!(Array(Complex{T}, length(signal), size(t.bases, 2)), t, signal)
end

[coveralls]

Coverage decreased (-0.46%) when pulling d2d204e5e83a688d5383ed19941ab716c6b4e87d on gfa/types into 027c8dc9418d66275dd66e85130df0cf84641f1a on master.

[coveralls]

Coverage decreased (-0.36%) when pulling eb86dc85ab821b7f8525191a8357e0732f22f5e8 on gfa/types into 027c8dc9418d66275dd66e85130df0cf84641f1a on master.

[coveralls]

Coverage decreased (-0.36%) when pulling 2174677c4ecfae81fe27bc627307904a1de6ef19 on gfa/types into 027c8dc9418d66275dd66e85130df0cf84641f1a on master.