[Date Index]
[Thread Index]
[Author Index]
Re: Re: Re: FFT
*To*: mathgroup at smc.vnet.net
*Subject*: [mg12982] Re: [mg12849] Re: [mg12834] Re: FFT
*From*: David Withoff <withoff>
*Date*: Sun, 28 Jun 1998 02:52:06 -0400
*Sender*: owner-wri-mathgroup at wolfram.com
> David Withoff wrote:
>
> > Regarding the comments about theorems and quantitative work and such,
> > all of these transforms are fairly standard, and so will satisfy all
> > relevant theorems, and other than the care that one should always
> > exercise in quantitative work, no special effort is needed when using
> > these transforms.
> >
> > Dave Withoff
> > Wolfram Research
>
> I have tried to explain these theorems to mathematicians and computer
> science types, but to no avail. To a mathematician, all mathematically
> valid definitions of fourier transform are equally valid. To
> physicists, engineers and mother nature, this is not quite the case.
> For example, the central ordinate theorem states that the integral of a
> function is equal to the value of its transform at the origin. For
> standard fft's, it is equal to 1/(N-1) times that value. This is
> trivial to correct, but still must be done to every fft that one plans
> on using. In any event, the standard fft routines do not satisfy several
> standard properties of 2-D physical transforms as are implemented by
> nature in the form of lenses and linear propagation systems of E-M
> radiation. The results of the standard fft are easily modifiable to
> satisfy all properties of physical fourier transforms by simple linear
> transformations and I think it is fair to point out to a beginner that
> the results of an fft are not physically, quantitatively valid without
> some slight modification or at least with strict attention paid to scale
> and units of the transformed axes.
>
> Note that I am not stating or implying that something is "wrong" with
> fft's or mathematicas implementation of them.
Probably this thread can be dropped from mathgroup, since it seems that
Mathematica is no longer part of it.
[I agree - further discussion not directly about Mathematica can now be
taken elsewhere - moderator]
Regarding the mathematical issues, however, no I do not think it is fair
to point out any of this to a beginner. I think it will lead to
confusion, and to the common but unproductive habit of blaming
computational blunders on vaguely-defined deficiencies in the
definitions.
I am not a mathematician type. All of my background is in physics and
engineering. I have for the most part studied mathematics only when it
was necessary to do problems in physics and engineering. In the course
of that work I have come to understand Fourier transforms quite well. I
nevertheless do not know what is meant by a "physical Fourier
transform" or what it means to say that a Fourier transform is or is
not physically or quantitatively valid.
Does "physical Fourier transform" refer to a particular definition of a
Fourier transform? Your statement of the central ordinate theorem is
essentially a statement about the choice of normalization constant in
the definition of a Fourier integral. Are you saying that this choice
is somehow more physical than other choices, that this choice is more
convenient than other choices, or something else? And what exactly is
a "standard fft", and what exactly is it that must be done to correct
it?
The issue of quantitative validity is even more troubling. Fourier
transforms are just definitions. What does it mean to say that a
definition is or is not quantitatively valid? Fourier transforms by
construction satisfy all theorems that they could possibly satisfy. If
those theorems don't happen to match up with physical behaviors, it is
because the physicist or engineer made a mistake in applying those
theorems. How can a definition be unphysical?
I don't understand what you are saying, and I don't think any beginner
will either.
Dave Withoff
Wolfram Research
Prev by Date:
**Re: Re: Strange behavior of Sort**
Next by Date:
**Re: Strange behavior of Sort**
Previous by thread:
**Re: Re: Re: FFT**
Next by thread:
**Gridlines**
| |