MathGroup Archive 1997

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

Search the Archive

Re: Fourier Transforms and Integers

  • To: mathgroup at smc.vnet.net
  • Subject: [mg6549] Re: [mg6507] Fourier Transforms and Integers
  • From: David Withoff <withoff>
  • Date: Mon, 31 Mar 1997 23:01:48 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

> I am posting this for general interest, not necessarily as a question, but for
> general interest.
> 
> Recently, the question came up about the mathematica function Fourier not giving 
> the expected results when given integers as arguments.  I recently ran in to a
> more advanced example of the same phenomena.
> 
> I am currently preparing to solve a system of coupled non-linear differential
> equations.  Terms in the equations include first partial derivatives and Laplacians. 
> I thought that the most convenient way to take the derivatives of a 2-D array of
> data would be to take advantage of the fourier transform theorem which says
> that Fourier[(2 Pi nu  j)^n F[nu]]=nth partial of f(t).  The code for the first partial of
> a square 2-D array "profile" is:
> 
>            NN=Length[profile];
> 
>         k=-I 2. N[Pi](1/NN/deltax  Outer[Plus,
>         RotateRight[Table[0,{i,1,NN}],NN/2+1],
>         RotateRight[Table[i,{i,1,NN}]-NN/2.,NN/2+1]];
> 
>         newprofile=InverseFourier[k Fourier[profile]];
> 
> This code works OK, but introduces an extraneous imaginary component
> proportional to the array "profile" so that for real input, I can separate the real part
> out and have a first partial derivative.  After much pencil and paper work to
> explain the imaginary part and some playing around with parameters in the code, I
> found that the problem was in the integer input to the two Table statements.  The
> following code only replaces a 0 with a 0.0, but this invokes the real addition and
> mathematica interprets everything in  the symbol k as real.  The extraneous
> imaginary components go away, the sun comes out and the world is right again.
> 
>            NN=Length[profile];
> 
>         k=-I 2. N[Pi](1/NN/deltax  Outer[Plus,
>         RotateRight[Table[0.0,{i,1,NN}],NN/2+1],
>         RotateRight[Table[i,{i,1,NN}]-NN/2.,NN/2+1]];
> 
>         newprofile=InverseFourier[k Fourier[profile]];
> 
> This just goes to show you that in a computer language that doesn't have type
> declaration statements, you have to be careful.

I am puzzled both by this example and by the conclusion.

I am puzzled by the example because, if I make up a value for NN,
and insert an apparently missing parentheses, then the two expressions
that you gave for k are identical:

In[1]:= NN = 10;  (* for example *)

In[2]:= k1 = -I 2. N[Pi](1/NN/deltax) Outer[Plus,
            RotateRight[Table[0,{i,1,NN}],NN/2+1],
            RotateRight[Table[i,{i,1,NN}]-NN/2.,NN/2+1]];

In[3]:= k2 = -I 2. N[Pi](1/NN/deltax)  Outer[Plus,
            RotateRight[Table[0.0,{i,1,NN}],NN/2+1],
            RotateRight[Table[i,{i,1,NN}]-NN/2.,NN/2+1]];

In[4]:= SameQ[k1, k2]

Out[4]= True

which of course makes me wonder how you could have observed such
strikingly different results for these two values of k.  Are you sure
there wasn't some other difference between your two calculations?

Also, are you sure that the differences that you observed had something
to do with type declarations?   That sounds very strange to me.  If
the input is mathematically correct, I wouldn't have expected the
typelessness of the language to have any visible effect.

Dave Withoff
Wolfram Research


  • Prev by Date: Coupled ODEs: not solving [REPOST]
  • Next by Date: Re: solving simple ODE using NDSolve
  • Previous by thread: Coupled ODEs: not solving [REPOST]
  • Next by thread: Re: solving simple ODE using NDSolve