Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1996
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 1996

[Date Index] [Thread Index] [Author Index]

Search the Archive

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



  • Prev by Date: Re: Inverse????
  • Next by Date: LaTeX COMPATIBLE MATHEMATICA FRONT END ?
  • Previous by thread: Re: Mathematica etc.
  • Next by thread: Re: Argument types