Any 'proof' needs to somehow introduce ln(a) in a non-artificial way.  Using derivatives, as Alex points out, is not the way.

However, we know that a^h = exp(h*ln(a)).  If we expand that exp into a series to 2 terms, we get 1+h*ln(a)+O(h^2).  Now we're nearly there!  Plug that in to the limit expression and we get

(1+h*ln(a)+O(h^2)-1)/h = ln(a) + O(h), which is a valid computation as h>0.

FAIL is not wrong, although it is also not the best answer.  FAIL says that Maple can't do this (yet).

Those things made Maple geeky, not cool.

The basic issue is that those early adopters who were visionary enough to see Maple's potential in the 90s are not that big a market.  And so, to widen the market, a move away from geek-cool to mainstream terminology was a reasonable move.  The MathWorks did the same thing with Matlab.  And Mathematica was only geek-cool when it released on the NeXT.

I am pretty sure that most of the Maplesoft executives will see your claim that Maple stopped being cool in the 2000s as a sign of success!

On problems like this, which are essentially just manipulation of lots of terms with nice normalization properties, Maple used to really shine.  It was much faster than Mathematica, which translated to a lot of other parts of Maple that are manipulation-heavy also being faster.

Now, it could be that this one algorithm is badly written, so suffers from massive overhead.  Or it could be that the state-of-the-practice has moved, and Maple has not.  What about other systems? 

First, Mathematica's answer is not particularly useful.  The first one is 0 for w>0, which seems weird.  The second one has all 3 of its hypergeometric functions formally divergent -- which is not really surprising!

Why are you trying to find the Fourier transform of this function at all?  Especially since it is unlikely to be well-defined.

Your approach however, to splitting f(t) into pieces, seems like a good idea.

If you want to try a purely formal method, I would get MGfun (from algo.inria.fr), then follow Salvy's method.

Your MyProc will look like

proc(args1, args2, args3, h)
    local v1, v2; # and more as needed

    statements; # these set things up
    proc(x) ssss end proc; # ssss uses v1, v2 and also args1, args2, etc
end proc;

This is how dsolve/numeric works.

Try the 'size' option.  But don't expect miracles!

Instead of fooling around with op, why not use the solution directly?  For example

x1 := eval(x, e[1]);

will work just as well. It will work over expressions in x too, which is the whole point of having the output of solve being in that format, it can be fed as input to eval as is.

convert/base will give you, for a given integer, a list of the digits in any base.  Getting a polynomial from that is an easy Maple exercise.

Without an actual system for us to 'play' with, we are not likely to be able to help you.

I agree with what has been previously said on this topic.

Do notice that you are not the 'questioner' with the most points!  What this does show though is that you are quite serious about learning Maple.  I tend to go out of my way to give thorough answers (when I have them) to questions from 'serious learners'.

The short answer is no, it can't be done.

The long answer is that if you are willing to use functions other than the Maple built-ins (like * and +), or other similar work-arounds, it is possible [there are many posts on this site showing such hacks, search for them].  But the results are a lot less appealing.

Now, it is possible to do something that comes close, via using modules and overloading.  You'll find information about this in the Advanced Programming Guide.

I believe that OrProp(RealRange(2,5),RealRange(3,6)) is what you are after. This relates to a post of yesterday - RealRange is not a set, but a property.

In Maple, 2..5 is closer to being an interval (although for obscure historical reasons, the interval arithmetic function evalr uses INTERVAL(2..5)).

See my blog post about using dsolve on this problem.  While I do not show a complete solution, at least things get 'closer'.

The Maple Application Center is thought to be useful enough to people that they won't mind a bit of pain to get to it.  The pain is there because 'becoming a member' is a (small) barrier to entry that qualifies you as actually 'interested in Maple'.  That is extremely valuable marketing information for Maplesoft.  They use the list of members to populate various mailing lists for their marketing material.

If the barrier is higher than the reward of access, then it becomes self-defeating, and the usefulness of the Maple Application Center nose-dives. 

The membership-based idea was quite popular on the Internet a few years ago [and still is in some niches].  But in other circumstances, even such a low barrier has been found to be ``too high'' and removed.  It is probably time for Maplesoft to revisit that idea - is their need of email addresses for spam campaigns more important than having more Maple users find the information they need to properly use Maple to its fullest?