The imaginary unit in Maple is I (uppercase), not i (lowercase).

There are some commands that were commonly used when your textbook was written that have been superceded by newer commands. Three of those are array, vector, and matrix (all begin with a lowercase letter). These have been superceded by Array, Vector, Matrix, and rtable. While the older forms continue to work, you shouldn't use them; formally we refer to them as deprecated.

A simpler alternative to Array(1..3, 1..4, (i,j)-> i^j) is Array(1..3, 1..4, `^`). I prefer to group the indices with parentheses for clarity:

Array((1..3, 1..4), `^`)

The extra parentheses are a purely syntactic addition; they have no effect on performance.

The computational problem (as opposed to the mathematical-display problem) can be addressed by iterating mul over a set or list of indices:

• mul(lambda[i] - lambda[k], k= {$1..n} minus {i}) (set of indices)
• mul(lambda[i] - lambda[k], k= [$1..i-1, $i+1..n]) (list of indices)

There is a formal paradigm that applies here called "Scales (or Levels) of Measurement". The scale determines which arithmetic and statistical operations can be performed on the measurements.

The basic (Stevens's four)^[*1] scales of measurement are (this is now often taught on day 1 in "Statistics 101"):

1. Nominal (aka Categorical): Objects being measured can be categorized into a finite number of categories, but there's no numerical relationship between the categories. Examples: {female, male}, {usable, repairable, discardable}, {too sick to be worth treating---going to die anyway; should be medically treated; not sick enough to be worth treating---going to get well anyway}. Allowed operations are set membership and set cardinality.
2. Ordinal: Objects can be placed in order on some scale, but other arithmetic operations are not appropriate. Examples: hardness scales of materials, such as MOHS; Beaufort scale of hurricane strength. Allowed operations now include <, <=, and the like.
3. Interval: Objects are measured in such a way that the differences of measurements make sense and can be compared by ratio, but the ratios of individual measurements make no sense. Examples: calendar year, Fahrenheit temperation, Celsius temperature.
4. Ratio: Measurements can be compared by ratio. Examples: the vast majority of standard measurements with units, such as years or Kelvin temperature.

Although there is much debate over the details of this paradigm, the vast majority of it is that there need to be more levels^[*1]; there's wide acceptance of the ideas that there are Levels of Measurement and that some classification of them is useful. Personally, I would always include a logarithmic level for scales such as pH, dB, Richter, etc.

When you do a units conversion in Maple, it is operating on the ratio scale. Suppose I said "The temperature of the solution increased by 18 Fahrenheit degrees. What's that in Celsius?" The answer is 10 Celsius degrees. That's not the same computation as a conversion of absolute temperatures on scales that don't have equal 0 points.

[*1] See Wikipedia article "Level of measurement".

Your method is not even close to something that would work. You need to make 2 implicitplots, one of each color.

restart:
S1:= (x,y,z)-> x^2 + y^2 + z^2 - 16:  
S2:= (x,y,z)-> (x+4)^2 + y^2 + (z-2)^2 - 49:
S1S2intersect:= solve([S1,S2](x,y,z), [x,y,z], explicit):
IntPlaneX:= unapply(rhs(S1S2intersect[1][1]), (y,z));
p1:= (x,y,z)-> `if`(x <= IntPlaneX(y,z), S1(x,y,z), undefined): 
p2:= (x,y,z)-> `if`(x > IntPlaneX(y,z), S2(x,y,z), undefined):
plots:-display(
    plots:-implicitplot3d~([p1,p2], -12..5, (-7..7)$2, grid= [50$3], color=~ [red, blue]),
    style= surface
);

If the scaling (or unit of measure) of the axes is different, then lines may not appear perpendicular even though mathematically they are. This can be adjusted by including the option scaling= constrained in the plotting command.

Please put Questions in the Questions section, not the Posts section.

Expectation E (under null hypothesis of "true randomness") is that 1/2 of runs will be length 1, 1/4 length 2, 1/8 length 3, etc.

RunLengths:= proc(L::list)
local R:= Array(1..0), r:= 1, k;
    for k from 2 to nops(L) do
        if L[k-1]=L[k] then r++ else R,= r; r:= 1 fi
    od;
    Statistics:-Tally([seq((R,= r))]);
end
:
Chi2:= proc(T::list(`=`)) #return p-value (probability of randomness)
local chi2:= 0, T0:= table(sparse, T), S:= rhs(add(T)), E:= S, s:= 0, k;
    for k while E > 10 do
        chi2+= (T0[k]-(E/= 2))^2/E;
        s+= T0[k]
    od;
    #Last category is "all remaining": 
    1-Statistics:-CDF(ChiSquare(k), chi2 + (S-s-E)^2/E)
end proc
:
#Your data:
A:= [0,1,0,1,0,1,1,0,1,1,1,0,0,1,1,1,1,0,1,0,1,0,1,0,1,0,1,1,0,1,0,1,0,
0,0,1,0,1,0,1,0,1,1,1,1,1,0,0,1,0,1,0,1,0,1,0,1,1,1,0,1,0,1,0,0,0,1,1,1,
1,0,0,0,1,0,1,0,0,0,0,0,1,1,1,0,1,0,1,0,1,0,1,0,0,0,1,1,0,1,0]
:
B:=[0,1,1,0,1,1,0,1,1,1,0,1,0,0,1,1,0,0,0,0,1,1,1,1,0,0,0,0,0,0,0,0,0,0,
0,1,1,1,0,1,0,0,0,1,0,1,0,1,1,0,1,1,0,0,0,0,0,0,1,0,1,1,1,0,0,0,1,0,1,0,
0,0,0,1,0,0,0,0,1,0,1,1,1,1,1,1,0,0,0,1,1,1,1,1,1,1,0,0,1,0]
:
evalf(Chi2(RunLengths(A)));
                        0.0005236818491

evalf(Chi2(RunLengths(B)));
                          0.6136983916

Another way is like below. I prefer this slightly over using listprocedure for two closely related reasons:

1. listprocedure gives the naive user the false impression that it's possible to compute one of these functions without computing all 4. In reality, it's simply obscuring that it's always computing all 4 together.
2. Managing your own remember table gives you finer control over the recomputation.

restart: 
ddesys := {diff(S(t),t) = -beta*S(t)*Ix(t)/N, 
diff(Ex(t),t) = beta*S(t)*Ix(t)/N - sigma*Ex(t-tau__1),
diff(Ix(t), t) = sigma*Ex(t - tau__1)- gamma*Ix(t-tau__2), 
diff(R(t),t) = gamma*Ix(t-tau__2), 
diff(Dx(t),t) = delta*Ix(t), 
S(0) = 80900, Ex(0) = 1, Ix(0) = 1, R(0) = 0, Dx(0) = 0 }:
params:= {
    beta = 4, gamma = 0.0478, sigma = 0.10, delta = 0.0005,
    N=80900, tau__1 = 1.1, tau__2 = 8.7, tau__3 = 0
}:
dsn := dsolve(eval(ddesys, params), numeric):

Dsn:= proc(t) option remember; dsn(t) end proc:

F:= t-> 
    if t::numeric then eval(op(procname)(':-t'), Dsn(t)) 
    else 'procname'(args)
    fi
:

The parts that I added are in red.

Now, you can use these numeric procedures to do things like this:

plot([F[Ex], F[Ix]], 0..9);

fsolve(t-> F[Ex](t) - 10, 0..infinity);

The definitive difference between Threads and Grid (regardless of the specific command (such as Seq) used from those packages) is that Threads uses a shared-memory environment and Grid does not. A group of processes running in parallel under Threads can all "see" the same variables at higher lexical levels. Those processes can just as well overwrite those variables, which is where potential trouble arises. Two processes overwriting the same variable at the same time will usually cause erroneous results. Those commands and procedures that are guaranteed to not do that are called "threadsafe". Many commands are actually threadsafe even though they're not formally declared as such. An example is ListTools:-Classify. Most of the high-powered symbolic commands such as solve are not threadsafe.

If it's possible to do your problem with Threads, then you should: It's faster and uses much less memory. If you cannot make your code threadsafe, but it's still parallelizable, then you must use Grid.

To upload worksheets to this forum, use the green arrow on the toolbar.
 

Download betounes2.mw

In your example 2, Maple can't solve it because the input equations do not contain _xx[2]!

In your example 3: The explicit complex number is not the same thing as the RootOf because the RootOf represents all of the roots of the polynomial.

Problem 1a.
 

Download Betounes_1a.mw

Maple is not backwards compatible all the way back to version 4.3. I think that backwards compatibility only extends back to Maple 6 (not sure about the Maple 6, but I am absolutely sure that it doesn't go back to 4.3). If you read the help page ?forall, it clearly says that the first argument should be a name or list of names.  

Any situation where a procedure body (or the right side of an arrow expression) contains indirect references to variables named the same as the parameters (or the names on the left side of the arrow) will not work. This is by design, not a bug. If the procedure body can be expressed as a single expression, you can use unapply. More complicated cases require subs.

There are three dichotomies involved here, not just the two mentioned by the other respondents, and you are confusing them:

1. Standard vs. Classic GUI interface
2. 2D Input vs. 1D input (aka Maple Input)
3. Document mode vs. Worksheet mode

The red input that you've mentioned a few times is associated with 1D input. (You can change the color if you want.) You are confusing this with the other two dichotomies.

1. Standard vs. Classic: Classic is more robust and usually delivers the output faster. This has nothing to do with the speed of the computations performed by the kernel, only with the output---already computed---being formatted for your screen. There are a huge number of commands and command options (mostly related to plotting, graphics, tabular layouts) that will not work at all in Classic. Plus, you'll be restricted to a 32-bit kernel, which seems like a major setback.

2. 2D Input vs. 1D input (aka Maple Input): The 2D Input is to me nearly unreadable (due to a poorly spaced default font) and untypeable (due to constantly shifting context and the need to use arrow keys or the mouse). It is rife with bugs. Bugs are difficult to find because they may be due to character position rather than the character itself. Automatic conversion of 2D Input to 1D plaintext form results in a unreadable "brick". Despite what the other correspondents have said, there are a huge number of great syntax innovations that were introduced in Maple 2018 and 2019 that won't work at all with 2D Input. The error messages that you get for these will tend to make no sense; it's as if the 2D parser is totally unaware of that syntax. There are a moderate number of other forms of 1D syntax that work differently and erroneously when they are tried in 2D.

3. Document vs. Worksheet: I can't say much because I've never used Document.

So, I work exclusively with Standard GUI interface, 1D input (aka Maple Input), Worksheet mode.