When A and B are Arrays, something like

 if A = B then ...

won't work unless A and B are literally the same (pointers to the same memory location).  What you want to do in this case is check whether the Arrays have the same entries.  You can use IsEqual in the ArrayTools package for this.

The name IsEqual offends the grammarian in me: since it's always used on two or more Arrays, it ought to be called AreEqual.   But I guess it's too late to change that now...

Leaving aside the question of what it means to "just keep plottin out the other side of the singularity", one way is to use a change of variables to get a system that won't have a singularity there.  In your case, with the problem occurring when e(z) hits 0, you might try a new variable g(z) = 1/e(z) instead of e(z).

Leaving aside the question of what it means to "just keep plottin out the other side of the singularity", one way is to use a change of variables to get a system that won't have a singularity there.  In your case, with the problem occurring when e(z) hits 0, you might try a new variable g(z) = 1/e(z) instead of e(z).

To plot, you want to use pds:-plot(...), not plot(pds).   See the help page ?pdsolve,numeric for examples. 

To plot, you want to use pds:-plot(...), not plot(pds).   See the help page ?pdsolve,numeric for examples. 

Or you could just use Rotate from the ListTools package, which works exactly the same way.

Or you could just use Rotate from the ListTools package, which works exactly the same way.

This doesn't produce any error when I try it.  Are you sure your input was exactly what you wrote here?  You just have one dependent variable and one PDE, so there shouldn't be any complaint about that.  This error message would occur if e.g. you misspelled one Sigma.  Perhaps upload your worksheet.

This doesn't produce any error when I try it.  Are you sure your input was exactly what you wrote here?  You just have one dependent variable and one PDE, so there shouldn't be any complaint about that.  This error message would occur if e.g. you misspelled one Sigma.  Perhaps upload your worksheet.

Coin3[t] is either 0 or 1, with equal probabilities.  If it's 0 (corresponding to Heads in this case), you play Game A, where you use Coin 2 if your fortune == 0 mod 3.  If it's 1 (Tails), you play Game B, where you use Coin 2 if your fortune == 1 mod 3.

If your fortune == 2 mod 3, you use Coin 1 no matter whether it's Game A or B.
If your fortune == 0 or 1 mod 3, you would use Coin 1 in one of Game A and Game B and Coin 2 in the other, so each of those coins is equally likely to be used.  Thus in these cases your probability of gaining 1 is (1/2) * 0 + (1/2) * 4/5 = 2/5.

Coin3[t] is either 0 or 1, with equal probabilities.  If it's 0 (corresponding to Heads in this case), you play Game A, where you use Coin 2 if your fortune == 0 mod 3.  If it's 1 (Tails), you play Game B, where you use Coin 2 if your fortune == 1 mod 3.

If your fortune == 2 mod 3, you use Coin 1 no matter whether it's Game A or B.
If your fortune == 0 or 1 mod 3, you would use Coin 1 in one of Game A and Game B and Coin 2 in the other, so each of those coins is equally likely to be used.  Thus in these cases your probability of gaining 1 is (1/2) * 0 + (1/2) * 4/5 = 2/5.

There's no "lag".  At turn number t the current fortune is A[t-1], B[t-1] or C[t-1], and then you flip whatever coins you flip and get A[t], B[t], C[t].  

Here is a flow chart

There's no "lag".  At turn number t the current fortune is A[t-1], B[t-1] or C[t-1], and then you flip whatever coins you flip and get A[t], B[t], C[t].  

Here is a flow chart

1)  If small imaginary parts get smaller at higher values of Digits it is certainly an indication that there are roundoff issues.  It's not conclusive proof that the true value is real, but it would indicate that floating-point arithmetic is unlikely to decide that question.

2)  That's not the way I'd put it.  eval(J1, x=v) - eval(J1, x=0) is the integral from x=0 to v if J1 is an antiderivative of the integrand on the interval [0, v].   When that is not the case, you have to take into account the discontinuities in J1.   Maple's antiderivatives often do have jumps at some points where the integrand itself is smooth.  Definite integration by int(..., x = 0 .. v) will try to give a correct answer, taking this into account.  It doesn't always succeed.  On the other hand, evalf(Int(..., x = 0 .. v)) uses numerical integration methods, and usually is quite reliable.

1)  If small imaginary parts get smaller at higher values of Digits it is certainly an indication that there are roundoff issues.  It's not conclusive proof that the true value is real, but it would indicate that floating-point arithmetic is unlikely to decide that question.

2)  That's not the way I'd put it.  eval(J1, x=v) - eval(J1, x=0) is the integral from x=0 to v if J1 is an antiderivative of the integrand on the interval [0, v].   When that is not the case, you have to take into account the discontinuities in J1.   Maple's antiderivatives often do have jumps at some points where the integrand itself is smooth.  Definite integration by int(..., x = 0 .. v) will try to give a correct answer, taking this into account.  It doesn't always succeed.  On the other hand, evalf(Int(..., x = 0 .. v)) uses numerical integration methods, and usually is quite reliable.