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)