As I see it, if a computation fails, it should return uniformly an explicit message indicating this status, probably the special name FAIL, rather than returning unevaluated as with fsolve. It would be more clear in an interactive session and easier to handle programmatically.

@acer 

As you mention it, specfunc(anything,fsolve) can be replaced by the simpler specfunc(fsolve), documented as available since Maple 17. Apparently, the latter should have some advantage as I see a systematic process of replacement in the library code going on.

Do you mean something like this?

> plot3d(x*y,x=-1..1,y=-1..1);
                                      ----                                     
                                    --------                                   
                                 --------------                                
                               ------------------                              
                            ------------------------                           
                          ----------------------------                         
                       ----------------------------------                      
                     ---------------------------------------                   
                  --------------------------------------------                 
               --------------------------------------------------              
             ------------------------------------------------------            
          ------------------------------------------------------------         
        ----------------------------------------------------------------       
     ------------------------                      ------------------------    
   -----------                                                    -----------  

If so, try executing plotsetup(default).

@casperyc 

Yes, it was clear. But, first they are just a couple of example areas. And as said, suites for some other areas were also published (and you have not specified any area). And second you can also use these suites to compare the performance of different versions of Maple. Some times they show progress, but some other times they show regressions... Some additional source for the former are updates help pages, like ?updates,Maple18,Performance for GMP computations or ?updates,Maple2015,Performance for Floating-point LinearAlgebra.

@acer 

And what about setting gcfreq=2^22? Documentation declares this option "Deprecated as of Maple 16". Are there computations where setting this option would help anyway in recent versions?

@tomleslie 

I am a frequent debugger of Maple, and experience shows that the Standard GUI window interface to the debugger fails most frequently (hanging, becoming unresponsive, etc). No such problem occurs with the traditional text interface to the debugger used in the Classic GUI and the CLI. And the additional problem is that no known way exists to turn off this window interface. 

So, in general, and moreover in Standard, I use Joe's mdcs interface to the debugger. I recomend it strongly.

By the way, the debugger itself has several known bugs, but that is yet another story...

@casperyc 

There are comparative benchmarking testing suites for some areas like symbolic ODE solving and indefinite integrals.

@tomleslie 

Congratulations! Finally you have found a purpose to that broken Standard debugger window interface :)

@Carl Love 

No, I have not made that black box analysis of iolib in Standard (in particular as I use it little). But a comparison of the TCP dialog between the kernel and the interfaces, when executing iolib(2,-1) in Classic and Standard, shows that the kernel returns the same for both. Meaning that what matters is the reaction of the interface, in this case Standard at creating the dialog box. And, the question might be whether Standard has some switch that controls this behavior. So, I would rather look at tracing/debugging the java code.

@acer 

Interesting, in particular the vindication of deprecated student[changevar].

@Carl Love 

This is the behavior in the Classic GUI. What you describe is the behavior in Standard. Uniform behavior across interfaces would be best. Otherwise, the differences should be correctly documented.

@Carl Love 

This problem with the help page ?restart has been discussed for years, here and elsewhere. Not yet fixed, sadly.

@Rouben Rostamian  

Vey nice. But as this site is about Maple/CAS, I wonder how far geometric reasonings like yours could be implemented symbolically, in a systematic way (as an algorithm, say). If possible, this example shows that sometimes this way could be much more efficient than going to sophisticated methods (like meijerg) to produce a complicated expression in terms of special functions and then trying hard/unsuccessfully to simplify this expression to an elementary result.

@Kitonum 

Yes, squaring is a natural idea, because of the half angle. But the code of the procedure `convert/radical` does not seem to try it (or any other succesful path). In any case, it handles a table of cache values to which an identity can be added:

> `convert/radical`(sin(-(1/6)*Pi+(1/2)*arccos(1/3))):=1/2-1/6*6^(1/2):
> convert(sin(-(1/6)*Pi+(1/2)*arccos(1/3)),radical);
                                          1/2
                                         6
                                   1/2 - ----
                                          6

@HeiniKlum 

As far as I know, these coloring TypeMK tricks work only in the Standard GUI, and the ANSI tricks work only in the CLI. I do not recall at this moment of any similar programmable color facility available for the Classic GUI. It is a problem of the Maple system that the interfaces were not developed in a unified fashion.