@ecterrab 

Certainly, it is a quite different thing including parameters, here m, as solving variables (namely enlarging the space) than solving in case splitted form. In the first case, parameters may become expressed in terms of the coordinates of the base space, as Markiyan has shown.

About alternatives to solve, using a different solving engines, note that they are not included e.g. in ?solve,details > Other Maple solvers. And it looks like there is not comprenhensive review document dealing with all the solving engines together. So, it seems unlikely that the ordinary user will be aware of these alternatives, and few will ever use them. In view of this fact, I would find quite illustrative that you show here how to sove this system by means of these different solving engines.

Even better, all these different solving engines should be integrated and accesible through a single interface, desirably solve.

Probably, that old version is earlier than Maple 6. ?updates,Maple6,symbolic states:

Convert to Radical ("convert,radical")

Given a rational multiple of Pi, the trigonometric functions now return a radical only if the result is is a non-nested radical for each of sin, cos, and tan (and thus necessarily for sec, csc, and cot). This includes the rational multiples 0, Pi/6, Pi/4, Pi/3, Pi/2, and Pi.

@Glowing 

It will depend largely on whether they are recognized as bugs...

@Bendesarts 

As I interpret what you say, you are using the context menu (right-click) "Copy as MathML" facility. Have you tried exporting the same problematic expression by using the MathML package? ( see e.g. ?MathML,ExportContent ). About the source of the error message that you get, an actual example should be debugged. With good luck the source of this problem could be identified (if located in Maple library code).

I am curious, as I do not do such a thing. What troubles do you have?

@Mac Dude 

This is an issue that I have not investigated for Windows as I stay in Linux most of the time. Certainly, that file jre\bin\client\Xusage.txt is not a configuration file, and possibly jre documentation. But it is exactly the output of \jre\bin\java.exe -X (as checked in Win XP). The point is how far this executable plays the same role than its equivalent in Linux, here /jre.IBM_INTEL_LINUX/bin/java. This is the executable that I use for my scripts. For instance, the script for 2GB maximum heap script first line looks like:

/opt/maple17/jre.IBM_INTEL_LINUX/bin/java -Xmx2g -Dsun.java2d.pmoffscreen=false -cp /opt/maple17/java/xercesImpl.jar:

where I have replaced the default option -Xmx512m that shows in the process monitor when the Standard GUI is launched in the standard way.

By the way, no option -Xss occurs for the java process here in Linux. Consequently I do not know which value is being used (likely some default), and I have not tried modifying it yet. Just as a guess, may be that it is set for the Mac as Maple uses the OS own Java, unlike the other systems, which might have a different default for the stack than the version provided by Maple.

@Carl Love 

Yet, that 2-D input error message is rather unhelpful in comparison with the normal error message:

...
> for i from 1 to nics do Sol ||i:=dsolve({sys1, ics[i]},{T1(t),T2(t),T3(t)},numeric)od;
Error, (in dsolve/numeric/process_input) system must be entered as a set/list of
expressions/equations

Moreover for the beginer user, presumably the target of 2-D input.

@Christopher2222 

No, the value of kernelopts(jvmheaplimit) is a different, unrelated issue. The number n in the -Xmx n option to the java call that Mac and me mentioned above is the heap limit for the main (Standard GUI) Java process. On the other hand, ?kernelopts states for jvmheaplimit:

The total amount of heap memory, in kibibytes, the Java external calling virtual machine is allowed to use.

Namely, it is about the heap limit for child externally called Java processes. As you have observed it is 65536 KiB also here, while the default heap limit for the main java process is 512MB.

In Linux, there is a configuration file bin/maple with some lines like:

# Parse all command line parameters. Parameters are collected into kernel
# and Iris parameters...
...
JAVAHEAP=512
CUSTOMHEAP=0
JVM_OPTIONS="-Dsun.java2d.pmoffscreen=false"
NORUN=false
...

And I see in a Windows installation the document file jre\bin\client\Xusage.txt:

    -Xmixed           mixed mode execution (default)
    -Xint             interpreted mode execution only
    -Xbootclasspath:<directories and zip/jar files separated by ;>
                      set search path for bootstrap classes and resources
    -Xbootclasspath/a:<directories and zip/jar files separated by ;>
                      append to end of bootstrap class path
    -Xbootclasspath/p:<directories and zip/jar files separated by ;>
                      prepend in front of bootstrap class path
    -Xnoclassgc       disable class garbage collection
    -Xincgc           enable incremental garbage collection
    -Xloggc:<file>    log GC status to a file with time stamps
    -Xbatch           disable background compilation
    -Xms<size>        set initial Java heap size
    -Xmx<size>        set maximum Java heap size
    -Xss<size>        set java thread stack size
    -Xprof            output cpu profiling data
    -Xfuture          enable strictest checks, anticipating future default
    -Xrs              reduce use of OS signals by Java/VM (see documentation)
    -Xcheck:jni       perform additional checks for JNI functions
    -Xshare:off          do not attempt to use shared class data
    -Xshare:auto      use shared class data if possible (default)
    -Xshare:on          require using shared class data, otherwise fail.

The -X options are non-standard and subject to change without notice.

@Mac Dude 

Indeed, the Java heap size is a big problem. E.g. in Linux 32-bits the Standard GUI Java process is launched with a line like java -Xmx 512m..., meaning a default heap size hard limit of 512MB. I have found that increasing this limit to 2GB (calling the Standard GUI by a custom script) easies a lot of use cases that stall Standard when started in the default way (worksheets that do not finish loading, or do not finish saving, etc). I have monitored the evolution of the Java heap for these cases and found that the stalling condition is reached when the heap gets above 400MB (i.e. over 80% of the default limit).

@Glowing 

In some more detail:

> ode := diff(sqrt(U(t)), t) = 1-sqrt(U(t)):
> ics := U(0) = 0:
> s:=dsolve({ics, ode});
                                 s := U(t) = 0
> odetest(s,{ics, ode});
                                      {0}

> ode1 := %diff(sqrt(U(t)), t) = 1-sqrt(U(t));
                                      1/2               1/2
                    ode1 := %diff(U(t)   , t) = 1 - U(t)
> (value@subs)(s,ode1);
                                     0 = 1

So, it looks like a bug both in dsolve and odetest.

@ecterrab 

I see. The actual exception arises in t1, a procedure defined on the fly in `property/Rename`:

> stoperror(traperror["attempting"]):
> dsolve({ics, ode}, usesolutions = "particular");
Error, attempting to assign to `%1` which is protected.  Try declaring `local %2`; see ?protect for details.
t1:
   2   nam := x
DBG> where
...
assume: nr := `property/Rename`(i)
	[x]
`property/Rename`: nm = t1(nam)
	[x]
t1:
   2   nam := x
DBG> args
x
t1:
   2   nam := x
DBG> attributes(args)
protected
t1:
   2   nam := x
DBG> quit

My impression, though, is that the end cause is the design of the assume facility that forces to somewhat involved (hence fragile) maneuvers.

@ecterrab 

I have observed that the code run by the option usesolutions = "particular" places an assumption on U__0:

> ode := diff(sqrt(U(t)), t) = sqrt(U__0)-sqrt(U(t)):
> ics := U(0) = 0:
> about(U__0);
U__0:
  nothing known about this object
> dsolve({ics, ode}, usesolutions = "particular");
                                    U(t) = 0
> about(U__0);
Originally U__0, renamed U__0~:
  nothing known about this object

I wonder whether this assumption is intended. It sounds more like a bug as U__0 does not occur in the returned solution, but this solution holds only for the condition U__0=0, which is not the assumption. And because this side effect is "hidden", it could bring unexpected consequences. I think that it would be much better returning an explicit condition. I observe it in Maple 17 and 18.

@Kitonum 

Actually, something else can be done with the original equation (with a bit of help), by using the new option symbolic = false:

> s:=solve(sqrt(x-a) = x, [a], symbolic = false);
       {         2
  s := { [[a = -x  + x]]        And(2 argument(x) <= Pi, -Pi < 2 argument(x))
       {
       {       []                                 otherwise
> s assuming x>=0;
                                        2
                                [[a = -x  + x]]
> evalindets(%,equation,lhs=maximize@rhs);
                                  [[a = 1/4]]
> s assuming x<0;
                                       []

@Kitonum 

Of course, I think that it is the best that can be done nowadays in Maple. One of the reasons why I have added "with some issues, though". The code behind is SolveTools:-SemiAlgebraic which handles rational functions only, see the error messages:

> solve(sqrt(x-a) = x, x,parametric,real);
Error, (in solve) invalid input: SolveTools:-SemiAlgebraic expects its 1st
argument, osys, to be of type {list, set}({ratpoly(rational), ratpoly(rational)
= ratpoly(rational), ratpoly(rational) <> ratpoly(rational), ratpoly(rational)
<= ratpoly(rational), ratpoly(rational) < ratpoly(rational)}), but received
{(x-a)^(1/2) = x}

@Kitonum 

The (intended) default domain in Maple is complex (not consistently implemented though). In this context, 0 is a branch point of ln and ln(0) should return undefined probably (rather than Error, (in ln) numeric exception: division by zero).