Most experienced Maple users have encountered situations where the "do" and "end" statements are not in the same execution group.
For example:

> for n from 1 to 10 do
> n, n^2, 1/n;
>
Warning, premature end of input, use <Shift> + <Enter> to avoid this message.

> end do; # in a separate execution group
Error, reserved word `end` unexpected

I have no objection to the issuing of a warning message when the "do" is executed without a matching "end".
My request is that the unmatched "end" (particularly when it appears as the initial (non-empty) string in an execution group) should receive a warning instead of an error.

I would like to see Maple's modp1 and modp2 support 25-bit moduli using the float[8] datatype, similar to the LinearAlgebra:-Modular package.

I think an excellent feature for Maple would be an auto-complete function similar to what they have in software integrated development environments like MS Visual Studio, i.e., when you begin typing a command, a small window pops up and displays the possible command completions, parameter list etc. This would be easier than typing Command-Shift-Space to complete commands, and if the parameter list and a small instruction could be included in the pop-up window, I think this would save loads of time, as it seems I spend half my time in the help browser looking up function calling sequences that I have forgotten.

Maple needs better user-level facilities for doing linear algebra over finite fields, particularly the integers mod n. For example there is no good way to solve a linear system Ax=B when B is a matrix. Obviously the LinearAlgebra:-Modular package is very good at what it does. Why can't there be some nice non-programmer routines which call it ?
One alternative to using the mod operator is to have all the commands in the main LinearAlgebra package accept an optional last argument for the characteristic. For example:
LinearAlgebra:-GaussianElimination(A, n);
Then in the GaussianElimination command you could do something like:

A colleague has been frustrated by the apparent limitations to Maple's abilities to "solve" inequalities. This does appear to be something that should - and could - be improved with a little effort.
The typical problem under consideration is the epsilon-delta definition of limit. Ideally, it would be nice to execute a command such as

> solve( abs( f-L ) < epsilon, x );

and receive an answer in terms of intervals.

I have this recurring editor issue where the cursor advances to the next line after entering an assignment operator (:=) or a type definition operator (::). I'm guessing the Maple code implementation is attempting some sort of code formatting and wants to advance the cursor one space beyond the operator. The only problem is that the space doesn't exist, so the cursor is ultimately advanced to the existing token in the buffer stream which in my case is a line feed; i.e., the next line.

The editor appears to be in 'Insert' mode since I can't overwrite characters while the cursor is positioned in the middle of a string.

Maple needs to be able to do the following:

RootOf(z^2-3)/RootOf(z^2-2) mod 5 -> 3

Instead we have

Normal(RootOf(z^2-3)/RootOf(z^2-2)) mod 5;
Error, (in mod/GetAlgExt) only the single algebraic extension case is implemented

I would also like to be able to factor and generally compute with polynomials whose coefficients involve multiple algebraic extensions mod p. These are basic fields, and it is somewhat sad that Maple has no way of computing in them.

As I have used MathML to prepare typeset mathematics in maplets, I noticed that there can be some confusion when there is no explicit multiplication operator. The problem appears to be most severe when two numeric quantities appear next to one another, e.g.,

> t := sin( 5*10^x );

I use the following maplet to see how this looks in MathML:

> with(Maplets[Elements]):
> maplet := Maplet([
> [MathMLViewer('value' = MathML[Export](t))],
> [Button("OK", Shutdown())]
> ]):
> Maplets[Display](maplet);

I note that the spacing appears to be a little better in Maple 10 than in Maple 9.5. But I would still prefer a centered dot (\cdot in LaTeX) or an x (\times). Note that I am not asking for a multiplication symbol to appear for all products, just ones where it can be difficult to determine the actual terms of the product.

I would like the Maple kernel to free sufficiently large (128 MB?) blocks of memory on garbage collect, not just on kernel restart. Sometimes I need to work with large objects temporarily, and then the overall performance of my machine suffers afterwards because of Maple's increased memory usage. I continue working afterwards, so I don't want to restart the kernel to free memory and eliminate swapping.

I'm currently working with a lot of large matrices in Maple (5000x5000), and I would really like a way to resize the Matrix Browser window, possibly filling the entire screen. I understand that this is probably one of those really irritating things that is difficult to add after the fact, but it would be extremely useful to me.

It would be convenient if the subscripted version of `type/integer`

could handle `infinity`

and `-infinity`

. Then, to specify an integer greater than, say, 1, we could do `type(i, integer[2..infinity])`

. Currently I handle this as `type(i, And(integer,Range(1,infinity)))`

which is not as nice, particularly because it isn't clear that 1 is excluded.
The drawback of doing this is that it implies that `infinity`

is allowed. However, because `infinity`

is not an integer, it seems reasonable that it would return fals

Just yesterday this came up in a newsgroup. For me the default size 100% seems too small, but the 150% is overkill. Having a 120% as a standard choice would be useful.

This forum is where you can suggest improvements for Maplesoft products. It will be monitored by Maplesoft staff who will record your input and in many cases, post appropriate responses. Please keep in mind that Maple is used be a wide variety of users with different needs. All comments will be read, taken seriously, and considered when making product decisions.
This forum is moderated by

Tom 4.