With value(%) it yields k.

The curious thing is that e.g IntegrationTools:-Combine is built upon (calls) `combine/range`:

> trace(`combine/range`):
> IntegrationTools:-Combine(Int(f(x), x = a..b)+Int(f(y), y = b..c));
{--> enter combine/range, args = Int(f(X),X = a .. b), [{Int, int}, {}]
[...]
<-- exit combine/range (now in combine/int) = Int(f(X),X = a .. c)}
                                     c
                                    /
                                   |
                                   |   f(x) dx
                                   |
                                  /
                                    a

But there is no equivalent interface for sums.

A site written in Russian may involve a barrier for those who do not know that language (including me), but also an incentive for its native speakers. I do not see why every site on Maple should be written in English, or provide an English translation. This issue reminds me somewhat of this other thread on a Chineese Mapleprimes.

The Classic GUI does handle Maplets, the same as the CLI. Actually, Maplets started as an addon to Maple 7, well before than the Standard GUI were launched in Maple 9.

The Classic GUI does handle Maplets, the same as the CLI. Actually, Maplets started as an addon to Maple 7, well before than the Standard GUI were launched in Maple 9.

Certainly, this is a bug introduced in Maple 16. This procedure solve_eqn calls itself recursively and is defined on the fly in line 23 of Groebner:-F4:-symbolic_preproc, so that its code can be seen by looking at it within the debugger:

kernelopts(opaquemodules=false):
stopat(Groebner:-F4:-symbolic_preproc,28):
F:=randpoly(epsilon,degree=10000,dense):
simplify(F, {epsilon^2=1});

DBG> showstat(solve_eqn)
solve_eqn := proc(i)
local t, a, j;
   1   t := T[i];
   2   procname(i) := NULL;
   3   map(procname,t);
   4   a := A1[i];
   5   if assigned(B1[i]) then
   6     x[i] := -(inner([seq(a[j],j = t)],[seq(x[j],j = t)])-subsop(op(op(eval(B1[i]))),zero))/a[i]
       else
   7     x[i] := -inner([seq(a[j],j = t)],[seq(x[j],j = t)])/a[i]
       end if;
   8   NULL
end proc

This code is identical in Maple 15.01 and 16, so that this bug is not originated here. Tracing this procedure by

kernelopts(opaquemodules=false):
stopat(Groebner:-F4:-symbolic_preproc,28):
F:=randpoly(epsilon,degree=10000,dense):
simplify(F, {epsilon^2=1});

DBG> trace(solve_eqn)

produces a long output. In Maple 15.01 it goes like:

DBG> cont 
{--> enter solve_eqn, args = 1
                                   t := {287}
                                solve_eqn(1) :=
{--> enter solve_eqn, args = 287
                                   t := {285}
                               solve_eqn(287) :=
{--> enter solve_eqn, args = 285
                                   t := {283}
                               solve_eqn(285) :=
[...]
{--> enter solve_eqn, args = 8
                                    t := {6}
                                solve_eqn(8) :=
{--> enter solve_eqn, args = 6
                                    t := {4}
                                solve_eqn(6) :=
{--> enter solve_eqn, args = 4
                                    t := {}
                                solve_eqn(4) :=
                                       {}
                                   a := A1[4]
                                  x[4] := [-7]

That is, the recursive calls keep a descending order in the values of T[i], so that it finishes after some fixed nmber of steps and the computation can complete. But, in Maple 16 these values keep jumping up at several steps, so that the recursion finally stops by exhaustion of stack call space.

I am submitting a SCR.

Certainly, this is a bug introduced in Maple 16. This procedure solve_eqn calls itself recursively and is defined on the fly in line 23 of Groebner:-F4:-symbolic_preproc, so that its code can be seen by looking at it within the debugger:

kernelopts(opaquemodules=false):
stopat(Groebner:-F4:-symbolic_preproc,28):
F:=randpoly(epsilon,degree=10000,dense):
simplify(F, {epsilon^2=1});

DBG> showstat(solve_eqn)
solve_eqn := proc(i)
local t, a, j;
   1   t := T[i];
   2   procname(i) := NULL;
   3   map(procname,t);
   4   a := A1[i];
   5   if assigned(B1[i]) then
   6     x[i] := -(inner([seq(a[j],j = t)],[seq(x[j],j = t)])-subsop(op(op(eval(B1[i]))),zero))/a[i]
       else
   7     x[i] := -inner([seq(a[j],j = t)],[seq(x[j],j = t)])/a[i]
       end if;
   8   NULL
end proc

This code is identical in Maple 15.01 and 16, so that this bug is not originated here. Tracing this procedure by

kernelopts(opaquemodules=false):
stopat(Groebner:-F4:-symbolic_preproc,28):
F:=randpoly(epsilon,degree=10000,dense):
simplify(F, {epsilon^2=1});

DBG> trace(solve_eqn)

produces a long output. In Maple 15.01 it goes like:

DBG> cont 
{--> enter solve_eqn, args = 1
                                   t := {287}
                                solve_eqn(1) :=
{--> enter solve_eqn, args = 287
                                   t := {285}
                               solve_eqn(287) :=
{--> enter solve_eqn, args = 285
                                   t := {283}
                               solve_eqn(285) :=
[...]
{--> enter solve_eqn, args = 8
                                    t := {6}
                                solve_eqn(8) :=
{--> enter solve_eqn, args = 6
                                    t := {4}
                                solve_eqn(6) :=
{--> enter solve_eqn, args = 4
                                    t := {}
                                solve_eqn(4) :=
                                       {}
                                   a := A1[4]
                                  x[4] := [-7]

That is, the recursive calls keep a descending order in the values of T[i], so that it finishes after some fixed nmber of steps and the computation can complete. But, in Maple 16 these values keep jumping up at several steps, so that the recursion finally stops by exhaustion of stack call space.

I am submitting a SCR.

Yes, it seems that the problem is in `trig/ident` that deals only with sin,sinh (not with  cos, cosh). It is an old bug. Checked as present in Maple 9.

It all depends on what A and some*other*stuff is intended to be.

It all depends on what A and some*other*stuff is intended to be.

@pagan 

I am afraid that I find it now harder to interpret your opinion. You like the Smart View feature, but yet think that `plot` should not be trying to impose it in the case that an explicit domain is supplied?

Certainly, the issue posed by jaytreiman is keeping the explicit plot domain. Laurent has described this feature as "heuristic", and the linked page describes it as "A new intelligent algorithm". In most usage scenarios, no algorithm (heuristic, intelligent, or whatever) can know better than the user which horizontal plot view is desired. So, a new default where the algorithm decides this view (or forcing the user to add an option for disabling it) is a wrong design, in my opinion. And it introduces a backwards incompatibility for no good reason.

The vertical plot range is a different issue, and I have described my opinion time ago in this thread, namely finding a more sensible default vertical range is good. In other words, changing the default behavior for the vertical range only would be OK for me.

Last, but not least, the issue raised by jaytreiman: debating about the features before being added would be a step forward.

@PatrickT 

I would find hard to believe that monitoring, the way you describe it, could be the reason. It could have been a reasonable way to do it in the 80's, when file distribution was based on ftp servers! Your last conjecture (ongoing development) seems more likely to me. Hopefuly, improvements will be seen soon...

Thank you Patrick and jaitreiman for the pointer to the FAQ note about the need to contact technical suport by email to get the fix. Meaning, presumably, that this fix is not published, as usual for other fixes. I wonder what is so special about this fix so that this distribution method was chosen, thus overloading the activities of the support staff. 

Do you know whether this fix for Linux has been published? If so, I have missed it.

Certainly, I find that the claim Improved Export of 3-D Plots to EPS with Vector Graphics
in the page New Features in Maple 16: Customer Wish List is a bit premature...

Certainly, at the proper time and place, I have expressed my opposition to this change of default for exactly this same reason, but no reaction occured yet. I am afraid that this is just one more example of people that believe being smarter than they really are.

PD: As pagan has edited his message, changing the semtence to which I have commented to, I copy below the original version of his sentence. This way we keep the record right...

I suppose that `plot` should not be trying to impose its new Smarter View

in the case that an explicit domain is supplied.

One way to make it work is by placing the .lnk shortcut file for cmaple.exe in your desktop directory, so that you get an icon for this shortcut on your desktop. Then you throw your .mpl source file onto it by dragging its icon with the mouse. It should get executed minimized.

I prefer handling such processes through the file manager. I use Total Commander and I would create a custom button which launches a suitable script. Surely, there is a lot of software tools around with similar capabilities, suitable for every taste.