as 'argument' does not produce the two argument arctan when assumed real:

argument(z) assuming real;



                 2  2       2                3  2            2  2
          R omega  C      (R  omega C + omega  C  L + R omega  C ) I
argument( -------------- + ----------------------------------------)
               2  2    2                      2  2    2
          omega  C  + R                  omega  C  + R

On the other hand, the resistance, capacitance, etc, are positive magnitudes. So the expression in terms of the two argument 'arctan' is unnecessary complicated in this context.

Related or not to this particular issue, there is no verification checksum available in the download page. So, download corruption should be taken into account.

Sure, algebraic operations should be made for a "normal" representation, with terms like sin(n*x) or cos(n*x), say. What I mean is to include a facility to transform between this normal form and an alternative one.

So, to add a series in non-normal representation you convert it first to the
normal one.
 

need also to be addressed. Apparently, this example shows that they are not used:

simplify([ceil,floor](a)) assuming 0 <a, a < 1

                         [ceil(a), floor(a)]

Yes, it works for these particular expressions. However, transforming 'ceil' to 'floor' should be avoided, I think, when simplifying an expression involving 'ceil' but not 'floor'. Eg, this should also simplify to 0:

restart:
g := ceil(1/2*(y-Pi)/Pi)+1/2*(-y+arctan(sin(y),cos(y)))/Pi;

                     /y - Pi\   -y + arctan(sin(y), cos(y))
                 ceil|------| + ---------------------------
                     \ 2 Pi /              2 Pi

`simplify/ceil` := proc(ex)
    evalindets(ex, 'specfunc(anything,ceil)', x -> -floor(-op(x)));
end proc:
simplify(g);

                      /-y + Pi\
               2 floor|-------| Pi + y - arctan(sin(y), cos(y))
                      \ 2 Pi  /
             - ------------------------------------------------
                                     2 Pi

But this transformation is more for a 'convert' operation here and is probably useless in regards to simplification.

I believe that this issue deserves some more thinking as eg. expressions involving 'ceil' and 'floor' are produced for some integrals like:

_EnvAllSolutions:=true:
int(1/(2+sin(x)),x=0..u);

I see, by tracing it with:

infolevel[all]:=5:
trace(`evalf/Limit`):
evalf(Limit( (ceil(x)+floor(-x)), x=1));

a rather long calculation involving large arrays. But I do not understand yet what it is doing.

I find this info so limited and biased that is close to useless. In particular, something so basic as new (sub)packages introduced in each version, is not even mentioned in most cases.

I think that a casual reader of this page would get an image of Maple and its evolution much more poor than reality.

I find this info so limited and biased that is close to useless. In particular, something so basic as new (sub)packages introduced in each version, is not even mentioned in most cases.

I think that a casual reader of this page would get an image of Maple and its evolution much more poor than reality.

For instance, it would be useful a command to change the index for cases like the example in ?FourierTrigSeries[ExploreFourierSeriesCoefficients], where the function signum(sin(2*x)) has symmetries that make some coefficients vanish, rewriting the series to look like:

Sum(4/Pi/(2*k+1)*sin((4*k+2)*x),k = 0 .. infinity);

(by the way, there is no command to convert this sum to a sin series).

You may rewrite the loop this way:

for k from 1 to nmax+1 do
  F[k-1]:=unapply(rhs(dsolve({evalf(des[k]),bcs(k-1)},
 'convert_to_exact'=false)),eta);
end do;

But 'dsolve' seems to be much more inefficient with this option 'convert_to_exact'=false (cf ?dsolve,details)

You may rewrite the loop this way:

for k from 1 to nmax+1 do
  F[k-1]:=unapply(rhs(dsolve({evalf(des[k]),bcs(k-1)},
 'convert_to_exact'=false)),eta);
end do;

But 'dsolve' seems to be much more inefficient with this option 'convert_to_exact'=false (cf ?dsolve,details)

This recent thread is somewhat related.

This recent thread is somewhat related.

I would delay the use of floats to the last stage, after the algebraic manipulations are completed:

e1:=a* x3 + b* y3 + c* z3 - d = 0:
e2 := cos(theta)* x3 + sin(theta)* y3 - 1 = 0:x3s := solve(e2, {x3});

                                 sin(theta) y3 - 1
                  x3s := {x3 = - -----------------}
                                    cos(theta)

subs([a=0.6907,b=0.3336,c=0.6415,d=2.203],solve(subs(x3s,e1),y3));

           0.6907 + 0.6415 z3 cos(theta) - 2.203 cos(theta)
           ------------------------------------------------
                0.6907 sin(theta) - 0.3336 cos(theta)

I would delay the use of floats to the last stage, after the algebraic manipulations are completed:

e1:=a* x3 + b* y3 + c* z3 - d = 0:
e2 := cos(theta)* x3 + sin(theta)* y3 - 1 = 0:x3s := solve(e2, {x3});

                                 sin(theta) y3 - 1
                  x3s := {x3 = - -----------------}
                                    cos(theta)

subs([a=0.6907,b=0.3336,c=0.6415,d=2.203],solve(subs(x3s,e1),y3));

           0.6907 + 0.6415 z3 cos(theta) - 2.203 cos(theta)
           ------------------------------------------------
                0.6907 sin(theta) - 0.3336 cos(theta)