@acer 

May be this question?

Logic and Set Theory with Maple

There is also this MUG thread.

@Markiyan Hirnyk 

After ?CodeTools,Usage this command "records time and memory usage statistics for the evaluation of expression". A priori, in my understanding, the memory used in evaluation and the memory used for storage, which presumably is what  kernelopts(memusage) measures, are two different things. There may be a relation between both magnitudes, but if it exists, the documentation is not showing it properly.

The OP's question has been asked several times here. I do not see a satisfactory answer though. Probably, a facilty providing this information is needed. 

@Andriy 

Yes, as Edgardo has shown, there is a design problem in that some type names collide with some procedure names, so that a workaround is needed by quoting the type name (i.e. avoiding its evaluation). This is a system wide problem affecting, in particular, some top level type names, coliding with procedures built in the kernel. One side of this problem is that this potential of name collision is not properly documented.

@H-R 

About the second way, no, it is a bit more than using subs or writing a procedure named "rBB" because this extension mechanism uses some of the "infrastructure" of the int facility like linearity, etc. See this less trivial usage:

> int(4*rBB(u,exp(x),1/y),u=0..1);
               3
4 y (exp(3 x) y  BesselJ(1, exp(x)) BesselI(1, 1/y)
                                                    2
     + BesselJ(0, exp(x)) BesselI(0, 1/y) exp(2 x) y
                                 2
     - 2 BesselI(0, 1/y) exp(x) y  BesselJ(1, exp(x))
     + exp(x) y BesselJ(1, exp(x)) BesselI(1, 1/y)
     - 2 BesselJ(0, exp(x)) y BesselI(1, 1/y)
                                             /            4               2
     + BesselJ(0, exp(x)) BesselI(0, 1/y))  /  (exp(4 x) y  + 2 exp(2 x) y  + 1
                                           /

Yet, I agree that this extension mechanism is very old and it was kept undeveloped in a primitive state, handling only function calls (as far as I could see). Note that it was kept underdocumented after its introduction in Maple V Release 2, some 20 years ago (?updates, v52 ).

So yes, Maple does need a better extension mechanism of its integration database. The first way is actually work in progress in this direction with the purpose of porting Rubi to Maple. As things stand now, it involves some hacking, and it is not ready for publication. Note, by the way, that for Maple 18 some details in that linked comment no longer hold as written because of (undocumented) changes of the indefinite integration sector in this version. 

@casperyc 

Yes, probably a driver issue with some hardware.

@ThU 

Yes, this keyboard shortcut seems new in Maple 18 and it is apparently undocumented... By the way, does the location of the menu entry "Execute > Workheet" under "Edit" make sense? Probably, I have missed this change as it does not for me.

@ecterrab 

The OP's starting expression was Transpose(s)*Inverse(A)*s, rather than Transpose(s)*A*s. I guess that you will agree that for some calculations/purposes, an abstract, non-indexed representation of matricial calculus is better. So, I think that there is a need of implementing it. Consequently, I have written an experimental version for such a facility.

@Preben Alsholm 

Yes, this is a frequent abuse of language, using "variable" instead of "name". Maple documentation is plenty of examples, generating a lot of confusion. And note that this same help page ?name also states:

Any expression can be assigned to a name.

without any qualification on whether the name is protected...

There is a somewhat deep problem here. Names play different roles depending on the computational/mathematical context (identifiers, variables, etc). But some contexts are not properly enforced, so that semantic clashes may occur, meaning e.g. that in an expression the same name may be taken with two different meanings, like variable or not. This is a source of bugs. It seems, though, that there is a way out for this role of variable in Maple that could be implemented rather easily, as I have discussed recently elsewhere.  

@Carl Love 

Independently of what the OP meant, I wonder whether solve returning a procedure was ever intended. The transformation of the equation into a procedure is made in SolveTools:-Engine:-Rename line 41:

> kernelopts(opaquemodules=false):
> stopat(SolveTools:-Engine:-Rename,41):
> solve(1=x(x),x);
memory used=1.1MB, alloc=38.3MB, time=0.06
x
SolveTools:-Engine:-Rename:
  41*            r2 := `minus`(`union`(r2,{fn = subs(('XXX') = rx,solve_rec_rename_BODY = qx,XXX -> solve_rec_rename_BODY)}),{nv = qx})
DBG> args
[{1-x(x)}, {}, {x}, {}, true, false, 1, {x}]
SolveTools:-Engine:-Rename:
  41*            r2 := `minus`(`union`(r2,{fn = subs(('XXX') = rx,solve_rec_rename_BODY = qx,XXX -> solve_rec_rename_BODY)}),{nv = qx})
DBG> into
{x = (x -> 1)}
SolveTools:-Engine:-Rename:
  43         r := r, r2
DBG> quit

It looks to me more like a bug (or more than one). Possibly, such an input should not be allowed and an error message explaining the problem should be produced. 

@acer 

I have seen examples of diverse kinds. Cases where export-to-.mpl works "wrong" while expand-document-block makes more sense (while not giving a fully programatic result), other cases where export-to-.mpl provides the actual hidden 1-D, while expand-document-block remains half-way, etc. So, probably, the advice would be better try all these three methods and cross-check results.

My opinion, as I have expressed some times here and elsewhere, is that the actual 1-D code behind 2-D objects should be easily accessible as hover-over or the like. Moreover if the 2-D language is intended as a road into the 1-D language. And also that worksheet/document-wide transformation between 1-D and 2-D code should be possible.

@acer 

Note that I have seen cases where "Expand Document Block" does not show the actual hidden command but an "intermediate" version of it.

@Valkyrie 

You have written the full error message in your initial message, so there was no problem about that. Certainly I also find unlikely that this error message arises in the Java sector of the system, so that tweakening with javaheaplimit and the like will not make any difference in this regards. An additional check that you could make is running your code in the command line interface (CLI), if you did not already. As the dependence of this interface on the Java code is "minimal", if this error message also occurs in the CLI, it would provide additional evidence that its origin lies elsewhere.

Now, for sure, this error message does not come from the code of the procedure DifferentialAlgebra:-RosenfeldGroebner. On the other hand, this code does contain try...catch constructs that trap exceptions arising at lower levels. Because of diverse clues, my suspect is the external C library. But I think that verifying this conjecture would require debugging, using your full code, unless that the developer of the package comes here and provide some required undocumented information (something that I find unlikely).

So, in these circumstances that preclude posting your full code, I do not believe that much more could be done here. Moreover, if my conjecture comes true and there is a bug in the external C library, its fix might require that to you submit a SCR with your full code and even then, it would not come until some dot/full upgrade.

@space 

One thing that you may try is launching the command line interface (CLI). If it starts (it should do quickly), then the problem might be related to the Java sector.

@Alex Smith 

Yes, from the computational point of view, Maple functions are polymorphic, namely admitting diverse types of arguments. For instance names, standing for variables in some space (Integer, Real, Complex, etc), Matrices, and several others. For obvious practical reasons I would start with the most standard mathematical cases like Real and Complex, the same as Mathematica does.

@Axel Vogt 

OK, now it is clear. It is the same issue that we have discussed so many times here. The more/only practical way to handle this phenomenon of domain extension within CAS is using the principal branch approach. In particular, this is how Maple defines ln, sqrt, etc. Besides, nowadays Maple has a facility computing branch cuts that could help here (even when it still needs improvements and bug fixing). The only part that needs further development in this regards is about closure (finding from which side of the branch cut the function is continuous on it).