You can not really do that, as soon as you type 3*(x+y) Maple expands it automatically
and so it will do if displaying whatever you have done before to have it in your form.

A kind of fake is algsubs(x+y=z,3*(x+y)):  eval(%,z=`(x+y)`);  giving

                               3 (x+y)

but here the sum is actually a variable, you get it back by `(x+y)`:=x+y;

May be one can use 'frontend', but I am not used to it.

I have not looked into the algorithm, but it seems that Maple expands the expression and after that can not successfully simplify it again (which ins general is not surprising). What I was: simplify first (which is _not_ always the best way), then take an antiderivate and use it to evaluate the integral. For the last step Maple _must_ know about continuity and in case of doubts it would not do it (this would be a point where assumptions would be needed and in case of undefinite integrals it may not be obvious). Anyway: fine if it solves your problem :-) Gleichfalls Guten Rutsch, Schönes Neues!

may be maple is missing assumptions on your variables, but this works:

  Transfunc(t-tau)*Inpfunc(tau): 
  expand(%): combine(%,exp):
  Int(%,tau):
  value(%):
  eval(%,tau=t) - eval(%,tau=0):
  collect(%,exp);

  / c a     e a     d a \
  |----- + ----- + -----| exp(-k t)
  \u - k   w - k   v - k/

           / c b     d b     e b \
         + |----- + ----- + -----| exp(-m t)
           \u - m   v - m   w - m/

           /   c a     c b \             /   d a     d b \
         + |- ----- - -----| exp(-u t) + |- ----- - -----| exp(-v t)
           \  u - k   u - m/             \  v - k   v - m/

           /   e a     e b \
         + |- ----- - -----| exp(-w t)
           \  w - k   w - m/

restart; interface(version);
hypergeom([1,4],[2],3/2); evalf(%);

  Classic Worksheet Interface, Maple 10.06, Windows, Oct 2 2006 Build ID 255401

                     hypergeom([1, 4], [2], 3/2)

Error, (in evalf/hypergeom/one_f_II) invalid assignment to Digits

Your integrand DR contains 2 symbolic variables, D and S. I explained what happens by applying evalf to such an integrand - use eval instead. If possible - but I do not know whether you will get symbolic solutions here. Just note: you built a long expression, so the answer has not much reason to become simple. Try to use it with numerical values. At least in b:= there is a typo, missing '=' ... An important point in any system is to get known to specific names. And a very important one is D, it stands for the differentiation operator. Always try to avoid that, it may give troubles (not here I think) and produce (false) results which are difficult to clear. Mostly I write theD or theI or similar. Also I would not type kappa||0, but kappa0 - but it's on you to know there are no side-effects. But i can not help you here, it would need more time (for me) than I want to spent additionally :-) Perhaps I would start at the end (just insert a restart before A), you will see a fraction * exp(-2*I*alpha*H) as integrand and may be I would try to work from there. Good luck :-) What is the source for the problem?

Maple can do it, but it needs some exercise to get used to a CAS. That needs
time and practicing, so I do not simply post the result.

First note that evalf is to compute floating point numbers. But your S is
a variable, so the result (usually) can not be a number, using evalf(Int)
makes Maple to evaluate all constants to floating point numbers - but it
will not evaluate the integral numerical (as that makes not sense).

For this check the help under ?evalf and find the topic about int and Int.

In your case evalf(Int) is an un-evaluated integral, you would see that
through the displayed result (I prefer the classical interface, for me it
is easier to handle).

To get the value of it use eval. It will need some time and the result an
expression with rational functions in S (polynom/polynom) with quite ugly
coefficients (.3141592654e-5010^-50 or 0.190493357210^61).

Even if Maple is able to handle such stuff (for some chosen numerical S)
it indicates, that in a CAS one should try to work with symbolics and at
the end pass to numerics.

This sounds vague, yes. In your case it is simple: instead of writing 0.05
just use 5/100. In that case Maple will treat it as a 'symbolic' number,
not as a floating point number.

Simply replace the definition of your h by h:=5/100, do it at the definition
of your alpha as well (if you mean h there just use h there).

That is: use rational numbers, read convert/rational in the help pages.

This already should give you a reasonable answer for int(e,theta=0..Pi/2),

But a bit more about that:

In case of troubles for such try to use assume for the integration variable
before integration (Maple does it not automatically, even if this should be
done in Math, I think it is due to the algorithms used. Additionally working
with assumptions slows down the system).

Next (a bit specific for Maple) do not write n[0]:=1. Index 0 may be messy
and you have it only once, so use n0:=1.

Working with indexed variables is a bit risky, but as you do it through arrays
it is ok.

Another thing is 'simplify'. Yes, all should be simple. But actually it makes
it complicated here (the system works mechanically), so use it only if needed.

If you do NOT use it for your f's and NOT for your d and e at the end of your
code it IS already very simple, it is a sum of 3 terms:

The first term only depends on S, so the integral is const*Int(1, theta ...).

The second is like int(sin(theta)^2,theta=0..Pi/2) = Pi/4.

Only the 3rd term remains, 1/(I*Pi*sin(theta)+(400-Pi^2*sin(theta)^2)^(1/2))^2 =
(-1/320000*Pi^2+1/800-1/8000*I)*Pi+(1/320000*Pi^2-1/800)*(ln(Pi+20)-ln(-Pi+20))*I
after simplication (using manual help).

This might help you to analyze the overall solution in case you need that.

Hope that helps.

May be that eval may be expensive, but I find that the most clear way
and I do that with an extra local variable (may be for later use in a
longer code) as:

inc := proc (x) local xi; xi := eval(x); xi := xi+1; return xi end proc;


inc(x+1);
                                x + 2

A:=10: inc(A);
                                  11

inc(infinity-1);
                               infinity

inc(Int(x^2,x=0..1));
                               1
                              /
                             |    2
                             |   x  dx + 1
                             |
                            /
                              0

inc(Int(xi*GAMMA(1,xi),xi=0..1)); 

                          1
                         /
                        |
                        |   xi exp(-xi) dxi + 1
                        |
                       /
                         0

For purely numerics (like Pascal) one could do evalf or evalhf as well.

A bit buggy - at least according to the online docu - is to use copy
instead of eval, the examples above work as well.

Int((diff( f(t) ,t)^2+1)^(1/2),t=1..3); evalf(%); 3.784498236 Looking at the plot it should actually be the length of the approximating spline.

x:=[1,2,3];
y:=[1,0,2];
with(CurveFitting):
S:=spline(x,y,t,cubic);

f:= unapply(S,t);

plot(f(t), t=1..3);

int(f(t), t=1..3);
                                 9/8

int((diff(f,t)^2+1)^(1/2),t=1..3);
                                  2

At least for the first linear transform I think one can do the following numerics (note the transforms are used to continue numerics to the whole plane [cut along 1 GT z], here it is to shift the unit circle around 1 to the one around 0) as follows:

Digits:=16:

MPL_2F1:=proc(a,b,c, z) evalf(hypergeom([a,b],[c],z)); end proc:

exceptional_15_3_6_numerical := proc(a,b,c,z) # for A&S 15.3.11
  local g, m, M;
  m:=round(c-a-b);
  M:=C-a-b;
  g:=1/GAMMA(-M+1)*hypergeom([a, b],[-M+1],1-z)/GAMMA(C-a)/GAMMA(C-b)-
    1/GAMMA(1+M)*hypergeom([C-a, C-b],[1+M],1-z)*(1-z)^(M)/GAMMA(a)/GAMMA(b);
  GAMMA(c) * (-1)^m * fdiff(g, C=c, workprec=3/2);
  return evalf(%);
end proc;

tstData:=[a=1,b=2,c=3,z=1. + I/2]:
TstData:= op(eval([a,b,c,z], tstData));

            TstData := 1, 2, 3, 1. + 0.5000000000000000 I

exceptional_15_3_6_numerical(TstData);
MPL_2F1(tstData);

               1.076040591635015 + 1.420736082606371 I
               1.076040591635015 + 1.420736082606371 I


tstData:=[a=1,b=2,c=7,z=1 - SFloat(1, -Digits+2) - I*SFloat(1, -Digits+2)]:
TstData:= op(eval([a,b,c,z], tstData));
                                                       -13
          TstData := 1, 2, 7, 0.99999999999999 - 0.1 10    I

exceptional_15_3_6_numerical(TstData);
MPL_2F1(tstData); 
                                                     -14
            1.499999999999990 - 0.9999999999999698 10    I
                                                     -14
            1.499999999999990 - 0.9999999999999700 10    I

I do not know how expensive numerical differentiation is in Maple, but would guess it is cheaper than summing digamma functions.

Abramowitz & Stegun, p. 559 I mean the degenerated cases for 15.3.6, which is 15.3.11 (note that 15.3.10 is a trivial case of 15.3.11 and 15.3.12 follows by Euler's identity from the later). Similar for 15.3.7 where the degenerated cases are 15.3.14, 15 and the final comment at that section.

for your example you just type the formula in Maple, mark whole input and output, copy that to clipboard (may be paste it into a text processor to check) and paste it between the "pre" statements:

r^2*e^2*cos(phi)^2/a^2;
                            2  2         2
                           r  e  cos(phi)
                           ---------------
                                  2
                                 a

i do not want to re-type your formula from the picture (even if it is nice to see it, you may want to include the usual input ...), but i would try to use taylor(foo,r). for the 2nd: if i understand you correctly then try to use some html formatting

here comes your text

to make it work choose input format as html (just below the input box) but note, that you can not use "<" or ">" in the text, but have to replace that by code (Alec posted s.th. for that 1 month ago edited to note also: using the pre command will no longer wrap lines to visible size, so take care for your readers.

sorry for being possibly somewhat rude: your notations have almost nothing to do with conventional Maple, use functions your problem is numerical ill-posed, try to use an abstract version (values at the end) Please try to re-post: the exact form of the problem in Maples notation (or 'friendly Math'). What is going on: it seems that Maple finds some solution in terms of Psi (if i get you right) and hangs up for the numerics, your values are beyond usual precison ( ~ 10^-14), so a symbolic solution may be an idea (to be evaluated later or after a scaling transformation).

anyway - if looking in texts with 'oldish' notations like Abramowitz et al i always have to use (at least mentally) paper & pencil to translate to notations i am used to ... finding s.th. like |(arg(1-z)| < Pi really ugly