When solve does this, it puts assumptions on the variables. You can use the about command to find out what the assumptions are. Example:

solve(sin(x), allsolutions);

about(_Z1);

Originally _Z1, renamed _Z1~:
  is assumed to be: integer

Note that the tilde is not used in the about command.

These global variables do not have assumptions until you execute a solve command (or other command) that makes the assumptions.

For real x, the Taylor series for sin(x) is an alternating series, and for |x| < 1 (x in radians), the terms decrease in magnitude, approaching 0. The truncation error for such a series is less in magnitude than the magnitude of the first unused term. This is very easy to implement, like this:

ApproximateSine:= proc(deg::realcons, err::positive:= 0.00005)
local term:= evalf(deg*Pi/180.), x2:= term^2, S:= term, n;
   for n while abs(term) >= err do
      term:= -term*x2/2/n/(2*n+1);
      S:= S+term
   od;
   S
end proc:

#Make the table:
d:= <[$0..45]>:
S:= ApproximateSine~(d):
Err:= S - map[evalhf](sin, d*Pi/180.): 
interface(rtablesize= infinity):
< d | S | Err >;

Download Sine.mw
 

The name stem of an indexed name n can be extracted by op(0, n). Therefore, the set that you want can be constructed by map2(op, 0, U).

One thing that I see as a true new functionality is the ability to overload operators (such as `+`) and builtin procedures (such as member) (*footnote). In the expression A + B, when an operand is an object, then that object's module is searched for procedure `+`. Without the newer objects, you'd need to use with to overload `+`, which'd effectively limit you to only one overload of `+`. See sections 9.5 and 9.6 of the Maple Programming Guide.

(*footnote) Only a very limited set of builtin procedures can be overloaded by objects.

If you use evala instead simplify, then you'll get precisely the form that you propose. I don't know why simplify doesn't do it; I think that that should be considered a bug.

What's the point in trying  to calculate it? You're trying to compute the Taylor series about x = 0 for a function which isn't even defined for x = 0 (it's not even defined in a removable singularity sense). The result would be meaningless garbage.

On top of that, the result of the symbolic-order differentiation seems to be garbage. For every n that I tried, it simplifies to 0 for all x.

For the vast majority of Maple procedures (including simplify), the procedure's arguments are first evaluated, then the evaluated results are passed to the procedure. I think that you're expecting the simplify(..., symbolic) to do something with the sqrt(z^2) before that is seen by diff.

If you haven't already, please read ?diff,symbolicorder. This'll explain the pochhammers and how you can get symbolic-order derivatives using factorials instead of them.

There are two ways. You can change the print commands to lprint commands, or you can give the command

interface(prettyprint= 0);

at the start of your session. Both of these methods work in both cmaple and in GUI (both Standard and Classic) Maple.

The first command to try would be fsolve. If you can't make it work, then you should post your equations.

Here is a translation of the Mathematica code

restart:
f:= z-> 1 + 2^(z+1) + 3^z:
L:= 20:
Digits:= 25: #eqv to Mma 'N[..., 25]'
zeros:= table():
for k to 300 do   #eqv to Mma 'Table[..., {k, 300}]'
   lprint('k'=k); #eqv to Mma 'Monitor'
   zeros[k]:= RootFinding:-Analytic(f(z), z, re= k*L..(k+1)*L, im= -10..10);
end do:
zeros:= [entries(zeros, 'nolist')]: #eqv to Mma 'Flatten'
sort(zeros, 'key'= Re);

However, the given function apparently doesn't have any zeros in the given range.

Mathematica's N[..., d] is generally equivalent to Maple's evalf(..., d). However, since Analytic already works in floating point, no evalf is needed in this case.

Such polynomial inequalities should (IMO) be solved with the parametric option:

p:= x^3 + a*x + 2:
solve({p > 0}, {x}, 'parametric');

plots:-display(
   [seq(
      plot(p, x= -3..3, y= -10..10, color= COLOR(HUE, (a+5)/10*.85)),
      a= -5..5
   )],
   thickness= 2
);

It doesn't make sense to me to solve for both a and x. Solving for a alone is trivial. The only interesting case is solving for x.

The quartic:

p:= x^4 + a*x + 1:
solve({p > 0}, {x}, 'parametric');

[Same plot command]:

Perhaps this parametric option should be the default when solve gets a polynomial inequality with a parameter.

seq(seq(N[10*i+j], j= 1..3), i= 1..3);

You need to change

end module()

to

end module;

Here's how to get numeric dsolve to return the integral of a function of the dependent variable(s).

Download IntByDsolve.mw

In this case the result will always be FAIL by Preben's reasoning. But for other ODEs, you'll generally get numeric values where those FAILs are.

Yes, you can do that with a try statement, like this:

for j from 1 to 10 do
     try
          Sol_set[j]:= solve(f(x,a)=0, x)
     catch:
          Sol_set[j]:= FAIL
     end try
end do;
       

You may replace FAIL with 0 if you really want to.