@Carl Love 

No. f does not matter. It has nothing to to do with f. All you did was align the bounds between the two animations so they both start and stop together. That is ok, but that doesn't solve the problem of mapping t->g(t) making the animation take 100x longer.

It would be easier to compute the values for t myself per frame and input them in

T := [seq(2^(k/10),k=0..10]

animate(plot, [fourier(f(x,t),x,w)/2^t, w= 0..100], t= T)

Now the fourier trasnform will run at full speed since it isn't trying to figure out 2^t dependence.

The point is that 2^t should not cause the fourier transform to crap out. The CAS should be able to handle it and even make the substitution of u = 2^t and take the same time to compute fourier(f(x,u),x,w);

If fourier(f(x,u),x,w) is fast then

fourier(f(x,2^t),x,w) should be fast.

This really isn't a problem with the animation, except that I'm specifically mapping t to 2^t to make the animation "smoother"(since it counters the log[2] dependence of t in f(x,t).

@acer 

@acer 

The second one was about insequence and I said I tried that and it did not work. It just plotted every frame individually with no animation.

I did not try the first as it seems a bit of a pain... it should be something VERY easy for maple to do... surely there is a proper way. This is not an NP hard problem. It is simple interpolation. N frames and M frames, we want them to finish at the same time, hence N/M is the ratio, modify frame rate by that amount and volia. It doesn't have to be perfect and if one frame is played half a ms sooner than it should then it's not going to end the world.

@Mariusz Iwaniuk 

An example is an example, an example is not general. I gave erf because it did not work in general using the general method. The reason why erf works is PRECISELY because it is defined by an integeral of a gaussian so the derivative simply returns a gaussian AND then the fourier transform of a gaussian is a gaussian.

For functions that are not defined by an integeral, the derivative wont necessarily simplify it in to somethign that has a fourier transform.  You want a specific case as if that is a general solution.

For something to be general means that it works for all inputs. What happens when I want to try a different function? Your method fails, you come up with a new one. I try it, it works, then I try a new function and your method fails... and the process is not general.

It is not about calculating a derivative symbolically, it is about taking the inverse transform of a function in general... seems you fail to understand that.

Your method works ONLY because of the special nature of erf. It does not work in general. How many functions do I have to show you to prove that? And how many will it take for you to realize that?

You want a function? Zeta(s), happy? Now try your derivative method!

Oh, maybe you figured out a trick with Zeta(s)? What about Zeta(s*Zeta(s + 1))? Oh, another trick? What about Zeta(s*cos(Zeta(s + erf(s^2 -sin(Zeta(s)))))*Zeta(s^2)^3. Ok, you found a trick! Great, you are now famous!

To plot something does not require symbolic manipulation. I realize maple is a CAS, but plotting functions should be possible and easy, even transforms of functions. Plotting helps visualize functions and it is an important area of mathematics. To limit plotting of functions to only those that are symbolically computable is nonsense.

@Mariusz Iwaniuk 

But this is not going to work in general, is it? You can take the derivative to erf because it is simply a gaussian and maple then can take the transform of a guassian... but in general the derivative may not be symbolically computable... so then what?

@acer 

First thing I tried was insequence but it failed and just showed all the frames as individual plots... Any two animations will do

animate(plot,[f(x*t),x=-5..5],t=0..1)

animate(plot,[g(x*t),x=-15..15],t=0..1)

They have the same number of frames, and same time range... just different x and y scale which is irrelevant since they will be on different plots.

@Christopher2222 

The reason to use numpoints is that it helps evaluate discontinuous or "noisy" graphs more accurately... but then one ends up with a curve that looks worse off visually.

It seems to be aliasing and line thickness. As if there is some check that if numpoints > threshold it doesn't anti-alias it.

It may be that with fewer points maple is building a spline for the points and that it uses a thinner line... but if the points are large enough it just draws the points, and uses thick points. That is most likely going on. I guess I could find the exact threshold:

plot(sin(x),x=1..4,numpoints=100);<- good

plot(sin(x),x=1..4,numpoints=1000);<- good

plot(sin(x),x=1..4,numpoints=2000); <- bad

plot(sin(x),x=1..4,numpoints=1999); <- good

So, in fact, it is 2000. Internally when setting numpoints > 2000 the curve looks to be unaliased.

This almost definitely means that it is an internal issue with plot and numpoints. Anyone can bring this to the attention of the maple dev team?

@Carl Love 

It seems to be working, although I get a strange result with a cut off sinc function.

I didn't realize maple had such issues with piecewise. Maybe fourier function should do the conversion internally.

Thanks

@Carl Love 

Because they are not the same functions.  The function is used in other places where it does matter.

I also use the piecewise for other reasons such as clamping the functions to a finite range to see the transform effect. So all you have successfully done is pushed the issue in to handling another special case. I would like a general case so that no matter what function I have, as long as it has a fourier transform, I would like to be able to plot it.

What happens when I stick more complicated functions in and it keeps crapping out? Why is it doing it? Surely it can sample the function numerically and coompute the fft to plot it if necessary?