This is a case were the 1-D input error message is more informative:

f := (c[A], c[B]) -> c[A]+c[B];
Error, invalid parameter; functional operators require their parameters to be of type 
symbol or (symbol::type)

This is a case were the 1-D input error message is more informative:

f := (c[A], c[B]) -> c[A]+c[B];
Error, invalid parameter; functional operators require their parameters to be of type 
symbol or (symbol::type)

May be that poles could be better be found numerically in some cases. But then identify (or something equivalent) should be used to recover the symbolic expression of the integral. Isn't it a shift of the problem?

I would expect that a stronger contour integration method could help with the current difficulties of FTOC + discontinuity checking for a relevant class of integrals. In the current setting of definite integration,  method FTOC may take something like 70% of all cases, while method contour very seldom contributes (note that it is last in the list of methods in Maple 16). In particular it fails for your example above of  cos(x)/(1+x^6), and method FTOC gives that long default answer. Yet, method meijerg yields a much more compact result. May be that this is what Mathematica is using by default.

Any link to the second thread?

By the way, any idea how strong is Mathematica at contour integration? (if such a method is implemented, I guess yes, but how to check? ).

@DJKeenan 

I have just made another experiment. Another of my default settings is typesetting standard. So, I have started the Standard GUI with your worksheet, kept the plot to windows mode, but changed the typesetting mode to extended, also by means of the menu (Tools > Option > Display), and executed by pressing the !!!  button (no copy & paste). It happens that that the 2-D parser errors are also produced.

So, I am begining to think that it doesn't matter what specific change is made initally via the menu, but only the fact that some change is being made at this point, somehow affecting the behavior of the 2-D parser. This conjecture needs further testing, but if confirmed (at least for some set of settings) it would be quite remarkable (and worrisome).

No, the correlation of the plot mode with the behavior of the 2-D parser is just a symptom of a deeper problem, a symptom that may be specific to my settings. In particular, the change to inline plot mode, for producing these errors, has to be done at the start of the session. If this change is made is made after any successful run in plot window mode, no such errors are produced either. In short, whether this problem occurs, depends on the settings and the history, a signal that the root cause of this problem is quite involved. Note that, in particular, by reinstalling, a change of settings may occur (it is like destroying the scene of the crime...)

I have executed this worksheet in Maple 16.01 several times and I have found a quite curious effect. With my default setup, plotting to a window, this worksheet executes without error (by pressing !!!), but changing the plot mode to inline (for the session) and executing exactly the same, those ShowCal error are produced. So, this effect seems to be about how the 2-D parser changes its behavior by this plot setting change. Namely, in the first case, copy & paste of a 2-D input ShowCal call to a 1-D input line looks like:

ShowCal(3345+`&+-`(10))

which fits the parameter type check, while in the second case, it looks like:

ShowCal(`&+-`(3345, 10))

which does not.

Well, 2-D input is a risky business. I would not publish any paper depending on it...

@Christopher2222 

Yes, in Maple 12 it works with a name form (with left quotes) but not as a string (with double quotes).

@Christopher2222 

Yes, in Maple 12 it works with a name form (with left quotes) but not as a string (with double quotes).

The actual problem is how long will Maplesoft provide the Classic GUI...

The actual problem is how long will Maplesoft provide the Classic GUI...

@Mac Dude 

My experince is exactly the same: in any serious work with Maple diverse bugs, weaknesses and undocumented/subdocumented features are met. In my opinion, discussing problems for identifying their nature is a good practice. In some cases, inspecting the code, debugging and tracing may help to understand what is going on, and eventually finding workarounds. And reporting bugs is always important. I understand that test suits are run systematically, but their coverage is never perfect and they may improve with SCR cases.

@Mac Dude 

My experince is exactly the same: in any serious work with Maple diverse bugs, weaknesses and undocumented/subdocumented features are met. In my opinion, discussing problems for identifying their nature is a good practice. In some cases, inspecting the code, debugging and tracing may help to understand what is going on, and eventually finding workarounds. And reporting bugs is always important. I understand that test suits are run systematically, but their coverage is never perfect and they may improve with SCR cases.

A first observation is that Maple 16.01 Classic GUI (or the CLI) generates the 2x2 array of plots correctly, directly and within the maplet, but it is not using the new smart view feature. Namely, the plot p3 for tan in the output of:

plots:-display( Array(1..2,1..2,[[p1,p2],[p3,p4]]) );

shows the peaks at odd multiples of Pi/2 as before. Certainly, displaying p3 looks fine in this regards. And the same occurs, curiously, with the single plot array:

plots:-display( Array(1..1,1..1,[[p3]]) );

On the other hand, the smartview feature is being used in the 2x2 array of plots generated in the Standard GUI. So, there is a chance of a relation.

I cannot check right now as my Pentium machine with Win XP is at hardware maintainance. In a newer machine, I have tried running on Wine 1.4/ Linux Mint 13 32-bit, setting Windows 95 compatibility mode, but that alone does not work. I have not found yet an equivalent to the rest of the settings (256 colors, etc).