RE: Soliciting Comments on DSP Library
Matthew Donadio writes:
Since it's populated, I think my current snapshot is a proposal.
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. 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 contains functions for mean, median, variance, and std. dev.
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, ...
PDF = Adobe Portable Document Format? No? Then what? My guess is Psomething Distribution Function, so how about 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
Simon Marlow wrote:
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.
Cool.
... I'd go with the longer names. ... 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. ... In this case there might be better names though - Numeric.Random.Distribution sounds good to me.
I am going to make the naming changes mentioned in the last few emails in this thread. The potential names can be found at http://users.snip.net/~donadio/haskell/proposal.html On question, though. Is it better to have a flat hierarchy, or a descriptive, but deep one? For example, I currently have DSP IIR FIR Is it better to have DSP Filter IIR FIR so that as I implement other filtering modules, such as Adaptive and Homomorphic, they have a "proper" home and be grouped together? Thanks. -- Matthew Donadio (m.p.donadio@ieee.org)
Matthew Donadio
On question, though. Is it better to have a flat hierarchy, or a descriptive, but deep one?
Flat. I suppose the question is a bit complicated, but the main purpose of the hierarchy is IMHO to avoid name clashes, so make it deep enough to do that, but not (much) deeper. Deep hierarchies inevitably end up with ambigous orderings of categories, which I think is something to avoid. Just MHO. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Matthew Donadio
I am going to make the naming changes mentioned in the last few emails in this thread. The potential names can be found at
OK, I like the proposed new arrangement. Just a couple of very minor nitpicks, as always, with abbreviations. DSP Corr.hs FastConv.hs Conv.hs Cov.hs These four are confusing to me at the moment, especially because they all begin "Co..". How about using Correlate, Correspond, Convolve, Covalent, or whatever they actually stand for. The name doesn't have to be very much longer, e.g. Convolve rather than Convolution.
On question, though. Is it better to have a flat hierarchy, or a descriptive, but deep one?
In general, I agree with Ketil that deeper can be untidy and lead to false classification just for the sake of it. However, the particular case you cite, DSP Filter IIR FIR Adaptive Homomorphic is not very deep, and seems eminently descriptive. There are several kinds of filter technique, which are conveniently separated from estimation techniques, etc. So I would go with it. Regards, Malcolm
participants (4)
-
Ketil Z Malde -
Malcolm Wallace -
Matthew Donadio -
Simon Marlow