The Z transform in maple is called 'ztrans', and its inverse is 'invztrans'. However, are you sure that what you are doing is a z-transform? A simpler way to achieve your computation is

trans := proc(expr, oldvar, newvar)
    evalindets(expand(convert(expr, exp)), 'exp'(anything),
    proc(e) local r;
        r := normal(op(1,e)/(oldvar*I)); 
        if type(r,'rational') then newvar^r else e end if
    end proc);
end proc;

which when executed gives for example

> trans(cos(13*w) + cos(w/2), w, z);
                      13            1/2
                     z       1     z        1
                     --- + ----- + ---- + ------
                      2       13    2        1/2
                           2 z            2 z

This appears to be a bug in `limit/range1`, more specifically in the case for powering, where there is missing logic for raising a number which is < 1 (in absolute value) to an infinity large exponent. The other two cases are actually computed (correctly) by `limit/mrv/MrvLimit`, but it requires the leading term to have a computable constant sign, which is not the case here. The theory behind those routines really do require that sign to be constant.

However, take a look at the help page ?maple which gives you many other ways of getting at 'similar' functionality via different options.

For these types of questions, ask support@maplesoft.com, you will get a faster answer.

For non-linear equations, fsolve often just returns some solutions (when they exist), where 'some' can be just one, as you show. You can then find others by using the avoid= option to fsolve. [Whether that is a good design or not is another question for another day].

This was a fun problem, so I kept at it, and now I have a closed-form!

> assume(Z>0, rho::real):
> int(exp(-Z*eta)*BesselJ(0,rho*eta)*cos(eta),eta = 0 .. infinity)-int(exp(-Z*eta)*BesselJ(0,rho*eta)*sin(eta)/eta,eta = 0 .. infinity)+Z*int(eta*exp(-Z*eta)*BesselJ(0,rho*eta)*cos(eta),eta = 0 .. infinity)-Z*int(exp(-Z*eta)*BesselJ(0,rho*eta)*sin(eta),eta = 0 .. infinity):
> ii := simplify(combine(%,int)):
> f := op(1,ii):
> ww := inttrans[laplace](f, eta, s):
> ans := eval(ww,s=0);
           3         2                       2         2
         Z~  I + 4 Z~  - 1 - 4 I Z~ + Z~ rho~  I + rho~
  ans := ----------------------------------------------- + (
                               2       2 3/2
                    2 ((Z~ - I)  + rho~ )

        Z~ (Z~ + I - rho~ I) + 2 I rho~ (Z~ + I - rho~ I)

         + 2 Z~ rho~ (Z~ + I - rho~ I) + Z~ rho~ I)/(2

                 2       2 3/2
        ((Z~ + I)  + rho~ )   )

                             2       2 1/2
                    ((Z~ + I)  + rho~ )    + Z~ + I
         + 1/2 I ln(-------------------------------)
                             2       2 1/2
                    ((Z~ - I)  + rho~ )    + Z~ - I

                                           1/2
           1/2 I (Z~ + I) (Z~ + I - rho~ I)
         - -----------------------------------
                                   3/2
                  (Z~ + I + rho~ I)

where I assumed Z>0 and rho::real. Now your numerical computations can be blindingly fast... (although there are a lot of cancelling parts in the above, especially in the imaginary parts).

Zeta is already used in Maple, and this may make things worse. Rewriting that as Z, and combining your integrals, I would suggest trying to compute Int(exp(-Z*eta)*BesselJ(0,rho*eta)*(Z*eta^2*cos(eta)-sin(eta)-Z*sin(eta)*eta+cos(eta)*eta)/eta,eta = 0 .. infinity) (ie int(exp(-Z*eta)*BesselJ(0,rho*eta)*(Z*eta^2*cos(eta)-sin(eta)-Z*sin(eta)*eta+cos(eta)*eta)/eta,eta = 0 .. infinity) ) instead.

As you have it, the computation will first proceed symbolically (which can be rather intensive), and then numerically. If you use Int (the inert form of int), then all the computation will proceed numerically, which is likely to be faster.

The command 'isolate' will do this [and isolate is just a wrapped for 'solve'].

What I would try is, from (9), derive an equation for cos(phi(s)), 'directly'. What seems to be happening (and why I can't just show you how to do it in Maple), is that 1) assumptions on phi(s) do not seem to 'work' quite right. One thing to do might be to substitute phi_s for phi(s) in your equations once the s-dependence is not so important anymore 2) arcsin(sin(something)) <> something unless 'something' is in a restricted range (like 0..Pi/2 for example), and Maple knows this. The 'trick' for these identities is usually to *never* go through arctrig functions, but to derive things about cos/sin relations directly.

Note that Ruth Hardy, through the Maple-PVS link can access QEPCAD via the PVS-QEPCAD link. Tortuous, yes, but still effective. Her web page contains some linkds with interesting applications of that combination to control engineering. Fascinating and useful stuff.

If you are familiar with other programming languages from the LISP family, unapply is usually called 'lambda' in those languages. Also, be aware that things like (1) are completely GUI-level creations, and 'unapply' is completely in the kernel, and that mixing the two can be somewhat dangerous [ie there are still some bugs in that area of Maple since this functionality is so new]. I am not saying don't do this, just be a little extra wary, that's all.

As far as I know, subs is the only way. But you're right, there are times where doing the inverse of 'value' would be useful.

It depends on how you have your data. In the GUI, the Context Menu for both a Matrix and for spreadsheets contain various Export options. There is also ExportMatrix (in the LinearAlgebra package). Or you can use fprintf and a loop to output csv "by hand".

>yy := (1/4)*x^3*BesselY(0,x)*BesselK(0,x):
> mel := inttrans[mellin](yy,x,s);

               s                 2                      Pi (s + 3)
              2  GAMMA(s/2 + 3/2)  GAMMA(s/4 + 3/4) cos(----------)
                                                            4
  mel := -1/4 -----------------------------------------------------
                                       Pi

> limit(mel,s=1);

                                  1
                                 ----
                                 2 Pi

This actually generalizes nicely, and one can get a closed-form with x^3 replaced by x^a. If a+1 is congruent to 0 mod 4, the answer simplifies a lot. The prettiest easy generalization along those lines (that I could find easily) is

> yy := (1/4)*x^a*BesselY(nu,x)*BesselK(nu,x):
> mel := inttrans[mellin](yy,x,s);

               (s + a - 3)                                     nu
  mel := -1/4 2            GAMMA(s/2 + a/2) GAMMA(s/2 + a/2 + ----)
                                                               2

                           nu       Pi (s + a - 2 nu)
        GAMMA(s/4 + a/4 - ----) cos(-----------------)/Pi
                           2                4

> eval(mel,s=1);

        (-2 + a)                                     nu
  -1/4 2         GAMMA(1/2 + a/2) GAMMA(1/2 + a/2 + ----)
                                                     2

                           nu       Pi (1 + a - 2 nu)
        GAMMA(1/4 + a/4 - ----) cos(-----------------)/Pi
                           2                4