Soliciting Comments on DSP Library

[Matthew Donadio]

Simon Marlow wrote:
> Would you like to submit a proposal - or does the library snapshot you
> posted constitute a proposal?  Would anyone else interested in DSPs care
> to comment on possible names for these libraries?

Since it's populated, I think my current snapshot is a proposal.  I will
be adding more modules, but I don't really see adding any more
sub-categories in the short term.  I will probably need the categories
	
	DSP.IO
	DSP.Homomorphic

but I'm not sure when I will get around to this.

> In the current hierarchy design we have:
> 
>   Numeric
>      DSP
>         FastFourierTransform
>         Noise
>         Oscillator
> 
> but given the size of your DSP library, perhaps moving it to the top
> level would be justified?

I am fine either way about DSP living at the top level, or under
Numeric.  I will submit to the consensus of Those Who Know Better, but
here are my thoughts...

I looked through the library archives for the discussions about the
Numeric.DSP hierarchy, and it looks like the divisions listed above were
based on my dormant, pre-resurrection library (I was buried under a rock
at the time, someone please correct me if I am wrong).  When I started
working on the project again, I needed a way to organize everything, so
my snapshot represents what I came up with.

The Stat library could really live anywhere.  It only contains functions
for mean, median, variance, and std. dev.

The Poly library could have a home somewhere else because it could be of
use to people outside of DSP.  Some people had suggested making it a
subclass of Num.  If this is the right thing to do, then there needs to
be a discussion (or a little guidance) on how to implement it.  My
implementation is tailored to what I need and to make my life easier.

The Matrix library should really be an FFI interface to the BLAS and
LAPACK packages (or maybe GSL?).  I think this is a huge undertaking,
though.  I implemented only what I needed to support the DSP library.

Perhaps nodes in the hierarchy should have a Pending for
modules/libraries that are needed and should have a standard interface,
but don't yet.  The caveat would be that users should not use the
X.Y.Z.Pending functions directly.  So, I would have

  DSP
    Pending
      Stat
      Poly
      Matrix

The various groupings under DSP are a little arbitrary, but make sense
to me.  They are basically arranged the way they would be grouped in a
DSP text.  Unfortunately, because of overlap between fields, we could
debate endlessly about where libraries live.  For example, correlation
is a central concept to DSP, but is really a statistical concept.  The
DFT and FFT have chapters dedicated to them in DSP texts, but are also
concepts found in fast multidigit multiplication applications.  Spectral
estimation is an application of statistics theory, and has use in fields
from DSP to financial market analysis.  That said, I think what I have
is fine, except as noted below.

It may make sense for the FFT library to live outside the DSP tree. 
Among DSP practitioners, the terms "FFT" and "DFT" are used almost
interchangeably, but DFT is probably a better name.  A proper solution
could be

  Numeric
     Transform
        DFT -- Discrete Fourier Transform
	DCT -- Discrete Cosine Transform
	DST -- Discrete Sine Transform
	DHT -- Discrete Hartley Transform
	...

Long names could be better to avoid confusion (there are several
transforms that begin with H).

The DSP.Signal portion could probably be split up.  I'm not sure if
anyone outside of DSP really needs the Oscillator functions, but the
modules related to random numbers could live under Numeric.  <insert
sound of can opening and Lumbrici crawling out>  Perhaps

  Numeric
    Random
      Generators -- MT19937, DRAND48, ...
      PDF        -- Uniform, Normal, Poisson, Rayleigh, ...
      Spectral?  -- White, Pink, Red, ...

and possibly a standard way to glue them together.  System.Random is
probably fine for general purpose random numbers, but the above may be
better for people who need tight control over what is generated.

> The other question to ask is whether this is will be *the* DSP library,
> or whether there are other competing designs.  If there are multiple
> designs, then the pattern we usually follow is to do something similar
> to the Text.PrettyPrint hierarchy, where we have
> Text.PrettyPrint.HughesPJ, Text.PrettyPrint.Wadler and so on.

If anyone has something similar, please speak up; I hate duplicating
work.  I think it would be best to have one library, and will gladly
accept comments and code improvements.  But if someone has objections, I
will make my public version live under User (or wherever).

Thanks all.

-- 
Matthew Donadio (m.p.donadio@ieee.org)