Soliciting Comments on DSP Library

Simon Marlow simonmar@microsoft.com
Wed, 28 May 2003 11:24:35 +0100


Matthew Donadio writes:
> Since it's populated, I think my current snapshot is a proposal.=20

Then I'm happy for your library to be the reference for the DSP
hierarchy.  Unless there are any objections, I'll add that to the list.

> 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

It's better to go straight for the final names, rather than have to move
modules around in the hierarchy at a later date.  The interface can
always be marked 'experimental' if it is likely to change.

> It may make sense for the FFT library to live outside the DSP tree.=20
> 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).

I'd go with the longer names.

    Numeric
       Transform
           Fourier
           Cosine
           ...

'DiscreteTranform' is a bit of a mouthful, so I'd go with just
'Tranform'.

Malcolm Wallace writes:
> > The Stat library could really live anywhere.  It only=20
> contains functions
> > for mean, median, variance, and std. dev.
>=20
> I suggest the fuller name 'Statistics', and indeed it does not belong
> under DSP.  Possibly under Numeric, but maybe at the top level?

Agreed.  The choice about whether to put Statistics at the top level or
not depends on whether it is likely to evolve into a deep hierarchy
itself; if not, then Numeric.Statistics should be fine.

> >   Numeric
> >     Random
> >       Generators -- MT19937, DRAND48, ...
> >       PDF        -- Uniform, Normal, Poisson, Rayleigh, ...
> >       Spectral?  -- White, Pink, Red, ...
>=20
> PDF =3D Adobe Portable Document Format?  No?  Then what? My guess is
> Psomething Distribution Function, so how about=20
> Numeric.Random.Distribution?

On the subject of acronyms, they don't necessarily have to be
unambiguous on their own as long as the meaning is clear from the
context.  That is, while PDF on its own is ambiguous, Numeric.Random.PDF
might not be.

In this case there might be better names though -
Numeric.Random.Distribution sounds good to me.

Cheers,
	Simon