It was pointed out to me that type(infinity+infinity*x,polynom(constant,x)) returns 'true' by design. I had forgotten that 'constant' means "maple constant" rather than "numerical constant". In other words, type(true+false*x, polynom(constant, x)) is also true, by design. It is the use of that particular type check which is ill-suited to its purpose, rather than the type-check being ``wrong''. As others have mentioned recently, this is another case of 'computer science' and 'mathematics' clashing. While in this situation what we get is clearly a case of GIGO, it's not clear that there aren't subtle cases where this causes actual bugs. While on the topic of GIGO: solve(true*x-false, x); returns false/true, as does solve(true*x-false). More fun is that solve(infinity*x-false) returns 0 ! GIGO indeed!

The point is not to go for best, but to expect that things will actually improve, instead of maintaining the status quo. It's a simple game: Maplesoft expects all of us to upgrade to the latest version of the product, we expect them to improve the product in ways that are useful to us. Part of that means to upgrade some of the older technology to use something more modern. Rather like what was done with GMP, Threads, etc. Such improvements may not hit the front page of the new shiny brochures, but they sure are a powerful incentive for long-term users to upgrade.

The point is not to go for best, but to expect that things will actually improve, instead of maintaining the status quo. It's a simple game: Maplesoft expects all of us to upgrade to the latest version of the product, we expect them to improve the product in ways that are useful to us. Part of that means to upgrade some of the older technology to use something more modern. Rather like what was done with GMP, Threads, etc. Such improvements may not hit the front page of the new shiny brochures, but they sure are a powerful incentive for long-term users to upgrade.

Indicating syntax errors in a sane way is a "solved problem", and has been for over 15 years. The problem is that Maple's syntax technology is way older (based on yacc, which dates from 1977, based on theory even older). A place to start is Error messages: the neglected area of the man/machine interface, followed by What the Compiler Should Tell the User, and then maybe a foray into Automatic generation of useful syntax error messages. For something truly modern, Syntax Error Handling in Scannerless Generalized LR Parsers is a good read.

Indicating syntax errors in a sane way is a "solved problem", and has been for over 15 years. The problem is that Maple's syntax technology is way older (based on yacc, which dates from 1977, based on theory even older). A place to start is Error messages: the neglected area of the man/machine interface, followed by What the Compiler Should Tell the User, and then maybe a foray into Automatic generation of useful syntax error messages. For something truly modern, Syntax Error Handling in Scannerless Generalized LR Parsers is a good read.

Right - and no matter how high I go with the order, I still won't get anywhere with D(y)(6*x+4). If I assume that a0=0, then it gets interesting, as the result is O(ln(1/x)^u) with u depending on the Order of the series! However, what I really ought to have done is to compute the series at x=1 (since we know y(1)=0). When I do that, I get:

> eq3 := eval(eq, y=( z-> a1*(z-1)+a2*(z-1)^2 + a3*(z-1)^3 + O((z-1)^4))):
> series(eq3, x=1);

  /
  |5 + exp(5/4 ln(a1 - 9) signum(0, -Im(a2), 1) + 5/4 ln(a1 - 9)
  \

                    1                                      1     \
         + 5/4 ln(------) signum(0, -Im(a2), 1) - 5/4 ln(------))| +
                  a1 - 9                                 a1 - 9  /

        O(x - 1)

Right - and no matter how high I go with the order, I still won't get anywhere with D(y)(6*x+4). If I assume that a0=0, then it gets interesting, as the result is O(ln(1/x)^u) with u depending on the Order of the series! However, what I really ought to have done is to compute the series at x=1 (since we know y(1)=0). When I do that, I get:

> eq3 := eval(eq, y=( z-> a1*(z-1)+a2*(z-1)^2 + a3*(z-1)^3 + O((z-1)^4))):
> series(eq3, x=1);

  /
  |5 + exp(5/4 ln(a1 - 9) signum(0, -Im(a2), 1) + 5/4 ln(a1 - 9)
  \

                    1                                      1     \
         + 5/4 ln(------) signum(0, -Im(a2), 1) - 5/4 ln(------))| +
                  a1 - 9                                 a1 - 9  /

        O(x - 1)

The code you based yourself on is ancient. A more modern version would read

`convert/sectan` := proc(fFP,x) local t, trans;
    trans := table([
      'sin' = (a -> tan(a)/sec(a)),
      'cot' = (a -> 1/tan(a)),
      'cos' = (a -> 1/sec(a)),
      'csc' = (a -> sec(a)/tan(a)),
      'sinh' = (a -> tanh(a)/sech(a)),
      'cosh' = (a -> 1/sech(a)),
      'coth' = (a -> 1/tanh(a)),
      'csch' = (a -> sech(a)/tanh(a))]);

    t := `if`(nargs = 1,'anything','dependent'(x));
    evalindets(fFP, 'specfunc'(t, {'sin','cos','cot','csc','coth','sinh','cosh','csch'}),
        (proc(f) trans[op(0,f)](op(1,f)) end));
end

Note that the above also fixed a bug in your routine [in the 2-argument case, when the original expression already had sec or tan in it]. In reality, one would not want to dynamically re-evaluate that table each time, so it would probably be coded as

`convert/sectan` := module() export ModuleApply;
    local trans, to_trans;

    trans := table([
      'sin' = (a -> tan(a)/sec(a)),
      'cot' = (a -> 1/tan(a)),
      'cos' = (a -> 1/sec(a)),
      'csc' = (a -> sec(a)/tan(a)),
      'sinh' = (a -> tanh(a)/sech(a)),
      'cosh' = (a -> 1/sech(a)),
      'coth' = (a -> 1/tanh(a)),
      'csch' = (a -> sech(a)/tanh(a))]);
    to_trans := map(op, {indices(trans)});

    ModuleApply := proc(fFP,x) local t;
        t := `if`(nargs = 1,'anything','dependent'(x));
        evalindets(fFP, 'specfunc'(t, to_trans), (proc(f) trans[op(0,f)](op(1,f)) end));
    end proc;
end module;

Note how every piece of information in the above is in the code once. Repeated information is the bane of code maintenance. Also, trans and to_trans are computed are module creation time, so have no run-time overhead. There might be something that can be done with argument processing to simplify the routine a little more, but I must admit that I have not mastered that art yet!

gen := proc() local n; n := 0; proc() n := n + 1; 'c'[n] end end: f := n -> randpoly([x], dense, degree=n, coeffs=gen()): then you get

> f(5);

              5         4         3         2
        c[1] x  + c[2] x  + c[3] x  + c[4] x  + c[5] x + c[6]

If you want to wrap that up into one piece and have the coefficients in increasing order, you can do

g := proc(n) local cof, m;
    m := n+1;
    cof := proc() m := m - 1; 'c'[m] end;
    randpoly([x], dense, degree=n, coeffs=cof);
end;

Using a,b,c,d looks pretty, but makes it more difficult to program with. It is probably easier to write a small printer for your polynomials rather than try to program with a,b,c,d,...

Call them up, or email them directly (support@maplesoft.com). This is the kind of issue that they can help resolve most quickly - they want legitimate owners of Maple to be able to access the product as smoothly as possible. Really, give them a call, I am sure they will be able to help you.

Solve is one of the most difficult pieces of Maple code to understand [in my experience]. In the past, I have repeatedly tried to make some changes to solve (i.e. fix a bug), where I invariably 1) managed to fix that bug, but 2) break something else in the doing. I know that a huge amount of work has been done in modularizing solve [it used to be made up of just a few routines, each of which was gigantic, all of which were mutually recursive!], but unfortunately I am no longer 'current' on where solve is at now. However, tracing (using high printlevel) what solve does is still something I can do :-). In this case, the first hint that things are going to go horribly wrong is that SolveTools:-Transformers:-MakeConditions is called (good), but it adds to our equations the inequality x^3-2*x^2-x+2 <> 0 ! This is clearly because it treats 'infinity' as some (finite) real constant, so that solutions can only lie on those areas where we have no singularites -- oops. SolveTools:-Transformers:-RemoveTerms then proceeds to "normalize" our term, to the lovely looking x-infinity*x^3 +infinity*x^2+infinity*x-infinity, which becomes the new equation to "solve". Note how things like 2*infinity have been automatically simplified to just infinity, so that most of the structure of the polynomial is forgotten. At this point, the 'modern' solve tries a few more trick, none of which work, so it calls `solve/oldrec2` [the main solve routine used to be called `solve/rec`, where rec stands for recursive, which in turn called `solve/rec2`, where the division of labour between rec and rec2 is known to only a few rare initiates, and I was never part of that rarified club]. At this point, the system we are trying to solve is {x-infinity*x^3+infinity*x^2+infinity*x- infinity, x^3-2*x^2-x+2 <> 0} for x. As was commented on, things take an ever weirder twist because type(x-infinity*x^3+infinity*x^2+infinity*x-infinity, polynom({complex(numeric), radalgfun(constant)}, {x})) actually returns true! If things were not really weird already, they get weirder now. How so, well type(x-infinity*x^3+infinity*x^2+infinity*x-infinity, polynom(constant, x))) also returns true. A tiny bit of sanity creeps in since type(x-infinity*x^3+infinity*x^2+infinity*x-infinity, polynom({rational,algnum}, x))) returns false. So the task is handed off to SolveTools:-PolynomialSystem. At this point, factor is actually called on the inequality, so that we have {1,-1, 2} marked as non-solutions. Our polynomial (with infinity coefficients) also is passed to factor - but comes back as is. Our polynomial, being irreducible but of degree 3, will not be solved exactly, so RootOf is called. And RootOf tries to collect terms -- which ends up with the x^1 term being (infinity+1), which is "simplified" to just infinity, naturally. So now the polynomial to look at is just infinity*_Z^3-infinity*_Z^2-infinity*_Z+infinity. This RootOf is now "plugged-in" to the inequality -- and unsurprisingly comes out as being true (i.e. that RootOf does not simplify to 0 when plugged in to x^3-2*x^2-x+2). So the inequality is tossed out, having done its job. Now SolveTools:-UnwindRootOfs is called, which "simplifies" the RootOf to {x=1}, {x=-1} ! How? Well, first it replaces infinity with a symbol, and calls factors, ie factors(O*_Z^3-O*_Z^2-O*_Z+O) which correctly and diligently returns [1, [[_Z-1],2], [_Z+1,1], [O,1]]] (those are not zeroes, they are capital o). And there we see our "solutions"! In fact, it is interesting that the x=1 solution is actually a double-root. The number of places where things go from wrong-to-worse is quite astonishing. As far as I can tell, this single problem has unearthed something like 4 different, separate bugs.