Re: Re: Mathematica etc.

*To*: mathgroup at smc.vnet.net*Subject*: [mg5500] Re: [mg5472] Re: [mg5385] Mathematica etc.*From*: Mark Evans <evans at gte.net>*Date*: Sat, 14 Dec 1996 19:26:05 -0500*Sender*: owner-wri-mathgroup at wolfram.com

Yes, I concur. Mathematica is excellent for prototyping, probably the best program ever for that purpose. However you need to be careful to keep the size of the data set small, maybe less than 5000 points or so. Invent a data set this size if you don't already have one small enough. Be sure to turn the data into machine numbers, not exact integers or symbols. The math is faster that way. One of the problems with using MMA for production analysis is that the file I/O is too slow. If that is fixed in a new version, and the array memory bloat is addressed, it might work quite well for production work. I think WRI should implement standard FIR and IIR filtering operations as native kernel routines, just like the DFT and FFT. Autocorrelation, power spectra, and convolution would also be useful, not to mention Gabor spectrogram and wavelet analysis, as compiled kernel routines. I have found that when I can develop a MMA-based DSP routine that depends only on DFT's, it is generally fast enough for my purposes. That's because the DFT is a native kernel routine, not MMA code. But as soon as I need to convolve something, it bogs down in a hurry because the code is interpreted MMA language, not compiled kernel binary. As an example, I developed an autocorrelation routine based on convolution that was not fast enough. Then I found a tricky back-door technique in Oppenheim & Schafer, "Discrete-Time Signal Processing," pp. 746-748, that relies exclusively on DFT's. That one worked well. If WRI wants to be really general about it, the company could implement these filtering routines inside the kernel for arbitrary array dimensions. The case of image processing requires 2D versions of the filters, for example, and seismic work could well require 3D versions. I hope they give us an option of where to put the DC term because in image processing, it belongs in the middle, not in the corner. -- Mark Evans ______________________________________________________________________ > Mark Evans has posted another reply to your message that is also correct. > This note just quantifies my earlier reply. Mma is not a good production > language, by that I mean, if you are going to execute a lot of experiments, > then Mma, for the > most part is not appropriate. Mma is excellent for prototyping any problem, > because the language of programming is the language of Mathematics, but > rarely is > as prototying language any good for production runs. I can think of at > least five or six languages that are excellent for specific problems, none > of which is worth learning for exploration. > > Sherman Reed