OrProp is a procedure. At the time of the error, that procedure has a very large remember table. (I can't tell yet whether it's large due to having a large number of entries or the entries being large, but I suspect the latter.) When you use print with a procedure name, it expands the procedure, including the table. (Whether the table is actually shown on screen depends on your setting of interface(verboseproc).) But if you just issue lastexception as a command, then the procedure is shown simply as its name, OrProp, due to the "last-name-evaluation" rule that applies to the names of procedures, modules, and tables.

I recommend that you use lprint instead of print, because lprint won't expand the procedure.

Other tips:

1. Assumptions don't usually work with solve, and an assumption of real definitely doesn't work.
2. Your equation can be solved in under 20 seconds by
   sol:= timelimit(20, solve(evala(Norm((lhs-rhs)(eq))), y, parametric, real))
   The evala(Norm((lhs-rhs)(...))) is needed to convert eq to a polynomial form so that it's accepted by the parametric option.

You asked:

• 1. What is the difference between the “process” and “task” conception and meaning in Threads and Grid packages?

A process is an independently running instance of a program. In this case, that program is the Maple "kernel". If you were to open two or more Maple worksheets in the same session, each would have its own kernel process (unless you changed your configuration from the Tools => Options menu so that the same kernel is re-used). Setting a variable's value in one worksheet wouldn't change its value in any of the others. That's what I mean by "independently running". Likewise, each node used by Grid is an independent kernel process. They don't share any memory unless you explicitly tell them to share specific pieces of it (through commands such as Set and Send). That last sentence is really the only thing that you need to know about processes in order to use the Grid package.

The meaning of "task" is more vague and more general. It would be a mistake to think that tasks are what Threads uses instead of processes. Perhaps we could say that a task is the smallest unit into which the work is divided in either package, but understanding the definition is not that important. What you need to know is that all of the simultaneously running code in a Threads application is running as part of a single process, a single kernel; they share all memory that is global or up-level to themselves unless you explicitly tell them to not share specific pieces of it or to share it in a controlled way. So, you see that Grid and Threads treat memory in exactly opposite ways. It is the uncontrolled sharing of write access to global or up-level memory that makes code not threadsafe.

• 2. What is the discrepancy between Grid:-Map and Threads:-Map commands in the practice and execution?

Both are parallelized versions of the regular map command. The only practical differences are as I described in the answer to #1 and that Grid naturally uses far more memory.

• 3. Between the “process” and “task”, which one of them does have the smaller run-time?

The question is irrelevant if asked exactly like that, because "processes" and "tasks" are not necessarily distinct entities. But if you change it to "Between Grid:-Map (or Seq) and Threads:-Map (or Seq), which has the smaller run-time?" then the answer is easy: If the code is threadsafe, then you should definitely use Threads; it is faster and uses less memory. (The vast majority of high-level Maple commands are not threadsafe.)

• 4. What is the default value of “tasksize” option in Grid:-Map and Threads:-Map commands?

For Grid:-Map and Grid:-Seq, the default tasksize is

`if`(n < 1000, max(1, floor(n/NN)), ceil(n/(20*NN)))

where n is the total number of items being mapped over and NN is the number of nodes (usually the same as kernelopts(numcpus)). So, the default for n > 1000 is such that there are 20 tasks per processor. The code for Threads is compiled and built-in, and thus I can't read it.

• 5. Does or the larger value of the “tasksize” option results in smaller run-time either the smaller value of that?

If there were an easy answer to that question, then there'd be no need for a tasksize option. Using too large a tasksize risks that some processors will finish long before the others and remain idle. Using too small a tasksize means that there'll be more overhead for the task initializations.

See this paragraph at ?has:

• If the item that you want has to search for is itself a list or set, you must enclose it in a list or set. Otherwise, has will search for items in the list or set as described above.

Thus, the answer is has(x, {{}}).

The green output is due to some kind of tracing or debugging being turned on. If you didn't turn it on, then it's unusual, but it's certainly possible. I suspect that some code author at Maplesoft accidentally left some debugging code in.

The green output is supplementary. It is not part of the return value of your command, which is the blue part. Nothing bad would happen if you simply ignored the green output.

For some strange reason, GetProperty returns the string "true" rather than the constant true. 

Although this code is ugly to me, you can workaround by 

if GetProperty(...) = "true" then ...

You can intersperse plots and text by putting it all in a column vector. This avoids the need to rely on side effects produced by print:

right:= ()-> <plot(x, x= -1..1), `This is a line of text.`, plot(x^2, x= -1..1)>:
right();

If you prefer normal-sized display, use

print~(right()):

Note that that last command ends with a colon.

My advice is to just use a Matrix from the start, and forget about the Vector of lists. The Matrix can be created in a single line by any of the following four commands (and there are several other variations possible):

restart:
vars:= 4:  n:= 1..2^vars:
sgn:= 2*<seq(<Bits:-Split(i-1, bits= vars)>^+, i= n)> -~ 1;
sgn:= Matrix([seq]([seq]([-1$2^j, 1$2^j][], i= 1..2^(vars-j-1)), j= 0..vars-1))^+;
sgn:= Matrix(combinat:-permute([-1$vars, 1$vars], vars))[.., [seq](vars..1, -1)];
sgn:= Matrix((2^vars, vars), (i,j)-> 2*irem(iquo(i-1, 2^(j-1)), 2)-1);

The commands vector, matrix, and evalm (all lowercase) should never be used. Replacements are Vector, Matrix, and the angle bracket constructors shown in the first construction above.

A Maple session runs as two or more separate processes (independently running programs): one user interface (either plaintext as you show above or GUI) and one or more "kernels" or "mathematical engines". The message "lost connection to kernel" almost always means that there was an untrapped error due to a bug in the kernel, and the process has died. (Occasionally, it does mean a severance of the connection between the kernel and the user interface. That seems extremely unlikely in this case.)

Yes, running out of memory can precipitate this error. The messages that you show indicate that this Maple kernel (alone) was using about 32 Gigabytes of memory at the time of the crash and that that amount was rapidly increasing. (Look at the "alloc"; ignore the "memory used".) How much memory does your machine have?

The fact that you got this message says nothing whatsoever about the mathematical solvability of your system or whether you've input it correctly. Groebner calculations often take an extreme amount of memory and time.

It may be possible to achieve better results by changing the order of the variables in plex. However, I have no advice on how to select one of the 13! possible orders. A Groebner expert may be able to advise on this.

After the solve command, do

assign(%);

O(...) is special when it occurs as part of a series structure (which includes any output from taylor), which I think is the case here. If you just want to get rid of O(...) and expand, try

expand(convert(Q(h), polynom));

The oddly named command convert(..., polynom) is for converting series structures to ordinary algebraic structures, regardless of whether they're polynomial.

Like this:

`&Delta;x`

Like this:

expr:= expand(alpha[-2]*(f(x) - 2*D(f)(x)*h + 2*(D@@2)(f)(x)*h^2 + O(h^3))/h + alpha[0]*f(x)/h + alpha[3]*(f(x) + 3*D(f)(x)*h + 9/2*(D@@2)(f)(x)*h^2 + O(h^3))/h):

InertForm:-MakeInert(expr);

This will work even if expr is entered in 2D Input using implied multiplication.

To use assuming in list form, do

`assuming`([odetest(sol,ode)], [x::real, x>0]);

I can't find any documentation on an assume option to odetest. Where did you see it? I guess that it's just being totally ignored, which is the default behavior for extra arguments that match no declared parameter.

I find this confusing also. Put your cursor on the "Section 1" header and press Ctrl-Period (or menu Insert => Section). Then a new section will open under Section 1 with the same level of indentation as Section 1.

Here are procedures for both of your sequences:

Seq1:= proc(N::posint) #N = number of terms
local 
    S:= Array(1..1, [1]), #the sequence
    SD:= 1, #its digit sum
    C:= 1, #its concatenation
    Used:= table([1= ()]), #terms used
    k, j, C1, SD1
;
    for k from 2 to N do
        for j from 2 do
            if not assigned(Used[j]) then
                C1:= Scale10(C, length(j)) + j;
                SD1:= SD + `+`(convert(j, base, 10)[]);
                if igcd(C1, SD1) = 1 then
                    C:= C1; SD:= SD1; Used[j]:= (); S(k):= j;
                    break
                fi
            fi
        od
    od;
    seq(S)
end proc
:   
CodeTools:-Usage(Seq1(99));
memory used=3.60MiB, alloc change=0 bytes, cpu time=31.00ms, real time=30.00ms, gc time=0ns

1, 3, 7, 2, 4, 5, 9, 6, 13, 8, 19, 11, 15, 21, 10, 17, 22, 23, 
  12, 24, 25, 14, 27, 16, 20, 28, 26, 31, 29, 18, 33, 37, 35, 39, 
  40, 41, 34, 42, 44, 43, 32, 45, 30, 46, 47, 36, 49, 38, 48, 51, 
  55, 53, 61, 50, 57, 60, 63, 52, 59, 64, 62, 66, 67, 54, 65, 58, 
  68, 69, 70, 71, 73, 75, 77, 79, 80, 81, 72, 82, 83, 76, 84, 86, 
  87, 78, 88, 89, 85, 93, 95, 91, 99, 101, 97, 105, 107, 103, 
  111, 56, 109

Seq2:= proc(N::posint)
local S:= Array(1..1, [1]), C:= 1, Used:= table([1= ()]), k, j, C1;
    for k from 2 to N do
        for j from 2 do
            if not assigned(Used[j]) then
                C1:= Scale10(C, length(j)) + j;
                if irem(C1, j) = 0 then
                    C:= C1; Used[j]:= (); S(k):= j;
                    break
                fi
            fi
        od
    od;
    seq(S)
end proc
:
CodeTools:-Usage(Seq2(99));
memory used=1.07MiB, alloc change=0 bytes, cpu time=16.00ms, real time=8.00ms, gc time=0ns

1, 2, 3, 5, 10, 4, 8, 6, 11, 20, 13, 7, 9, 12, 15, 18, 14, 25, 
  30, 24, 16, 32, 40, 29, 50, 100, 26, 52, 39, 21, 28, 35, 42, 
  17, 34, 51, 23, 46, 27, 36, 45, 43, 19, 38, 68, 48, 60, 75, 90, 
  54, 56, 58, 22, 44, 33, 55, 97, 125, 200, 64, 80, 69, 66, 88, 
  70, 41, 82, 37, 74, 79, 63, 84, 96, 72, 85, 136, 128, 92, 105, 
  31, 62, 93, 120, 150, 71, 142, 108, 124, 155, 179, 113, 164, 
  123, 205, 223, 140, 65, 78, 104