25 Reputation

3 Badges

0 years, 74 days

MaplePrimes Activity

These are replies submitted by Stretto



That is what I was looking for, Thanks!

@tomleslie  I should never have mentioned erf or any other specific function, it has nothing to do with the real problem and has only gotten the problem off on a tangent. I don't care about erf, I was just using it as a placeholder to specify a real function for simplicity.


The point is that

fourier: Entering fourier with erf(t)
inttrans/fourier/lookup: Enter with  erf(t) t v
inttrans/fourier/lookup: Returning  FAIL
inttrans/fourier/main: Entering with erf(t) t v
inttrans/fourier/lookup: Enter with  erf(t) t _S
inttrans/fourier/lookup: Returning  FAIL

inttrans/fourier/main: Leaving(3) with fourier(erf(t) t v)




Fails FOR some functions such... For some very complex functions it will always fail since there is no closed form solution. In those cases I want to evaulate numerically. I could do this by computing the fourier transform or even the fft but I would expect maple to have the machinery inside it to do this stuff for me... since all I want to do is plot.


In matlab I can do this basically with the fft command.. I can even define an arbitrary function and use it to compute the values.


Maple is symbolic, but plotting has nothing to do with symbols... since all I want to do is plot there should be some way to plot complex functions without having to go in to another program or wait years for it to complete.



@Mariusz Iwaniuk 


I should never have mentioned erf or any other specific function, it has nothing to do with the real problem and has only gotten the problem off on a tangent. I don't care about erf, I was just using it as a placeholder to specify a real function for simplicity.


@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).






Ok, I did not see those items in the list because of the coloration... THe main menu items at the top are so dominant and questions are the first one. It's obvious after one see's it.



Some of the maple coloration is a bit hard to see. Medium Grey with White text and such... Might be my browser or monitor or eyes... I rather have a more contrasting color theme.



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?



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





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.




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.



@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?

Page 1 of 1