and it is a nasty one, which I'd like others to confirm before I submit an SCR

Consider the (slightly revsed) version of Kitonum's code, shown below

  restart:
  local D:

  solProc:=proc( P )
                 local Q, f, np, nq, M, N, Sys1, Sys2, Sys3;
                 Q:=x-y-4=0:
                 f:= v-> < coeff(lhs(v), x),coeff(lhs(v), y), coeff(lhs(v), z)>:
                 np:=f(P);
                 nq:=f(Q);
                 M:=[1,0,0]:
                 N:=[0,0,-1]:
                 Sys1:=eval(P,[x,y,z]=~M);
                 Sys2:=eval(P,[x,y,z]=~N);
                 Sys3:=(np.nq)=sqrt(np.np)*sqrt(nq.nq)*cos(Pi/4) assuming real;
                 solve([Sys1, Sys2, Sys3]);
           end proc:

  solProc( A*x+B*y+C*z+D=0);
  solProc( a*x+b*y+c*z+d=0);

Running this code in Maple 2018 returns

{A = 0, B = B, C = 0, D = 0}, {A = -2 B, B = B, C = 2 B, D = 2 B}
{a = 0, b = b, c = 0, d = 0}, {a = -2 b, b = b, c = 2 b, d = 2 b}

But running this code in Maple 2019, Maple 2020 and Maple 2021 returns

                  {A = 0, B = B, C = 0, D = 0}

{a = 0, b = b, c = 0, d = 0}, {a = -2 b, b = b, c = 2 b, d = 2 b}

so for these three (latest) Maple releases, the number of solutions returned by the solve() command depends on whether the parameters in the equations are uppercase or lowercase - now that is nasty

from 'linalg' to 'LinearAlgebra' is shown in the attached.

Apart from the discrepancies noted in the comments in the attached, the two worksheets appear to do the same thing

Download withLA.mw

just a lot *simpler* (and works!).

You should use add() not sum() unless you are seeking a "formula" for the summation. I think all of the uneval quotes which you have are redundant.

Download sums.mw

I don't understand why you are generating ~1000 fits, n=2..3 in 0.001 steps.

Why not just treat 'n' as another fitting parameter restricted to the range 2..3. You then just have one fit to do - see the attached

Download NLFit.mw

No idea where you got the idea that the intersection point was   [249/100, 471/100, 0].

If I put forward an alternative solution to that already provided by Kitonum, I get the same answer (s)he did

Download insect.mw

Something wrong with

ExportMattrix( somePathName/someFileName,  someMatrixName )

in the worksheet where the matrix is generated, and then

anyMatrtixName:= ImportMatrix( somePathName/someFileName )

in the worksheet where it is desired?

if I throw out all the random code in your original worksheet, which isn't actually being used, and put what's leftr in more or less legible form, then I have to agree with you - this so-calle iteration process diverges. See the code snip below.

This gives the same answer as your original worksheet (ie 0.8789295492), for a single iteration (ie m=1), but diverges rapidly as the iteration count increases.

  restart:
  u[0]:= x*(1/2*exp(-t/4) + exp(-1/2) - 1) + 1:
  alpha:= 1;
  printf(  "    Number of\n"):
  printf(  "    Iterations         answer\n"); 
  for m from 1 to 10 do
      for n from 0 to m do
          u[n + 1]:= simplify
                     ( u[n]
                       +
                       alpha*int( x*(1-s)*(diff(u[n], t)-diff(u[n], x$2)-1/4*u[n]),
                                  s = 0..x
                                )
                       +
                       alpha*int( s*(1-x)*(diff(u[n], t)-diff(u[n], x$2)-1/4*u[n]),
                                  s = x..1
                                )
                     ):
       end do:
       printf( "       %2d      %16.8f\n",
               m,
               evalf(eval(u[n], [x = 0.2, t = 0.2]))
             );
  end do:
  
                           alpha := 1

    Number of
    Iterations         answer
        1            0.87892955
        2            0.95670244
        3            0.66722716
        4            2.78900964
        5          -18.82567148
        6          228.99961580
        7        -3004.18166800
        8        47074.66315000
        9      -875743.22920000
       10      18798150.48000000

mann.mw

From this information there are only two possible conclusions

1. The iteration process has been correctly implemented but does not converge - who claims that it does?
2. The iteration process should converge, but won't because it has been incorrreclty implemented - and I'm not going to read a few academic papers to work out how to implement it properly!

Pick one of the above - or come up with an alternative!

This image

was generated using the code below (and in attached link). It is 501*501 pixels and (on my machine) took about 90secs to produce. If you have the patience then just change the variable "npts" - a 1001x1001 image ought to be available in ~360secs

  restart:
  with(ImageTools):
  st:=time():
#
# Define the "ranges" for the complex variable
# starting point, and the numbe of points in the
# image. (Actually the number of points in the
# image will be npts+1 by npts+1
#
  bl:=[-2.0, -2.0]:
  ur:=[2.0, 2.0]:
  npts:= 500:
  step:= (ur[1]-bl[1])/npts:
#
# Initialize the "RGB" array
#
  A:=Array(0..npts, 0..npts,1..3):
#
# Specify the three roots. (These are given as
# "floats" just to make convergence testing
# simpler, later on
#
  rts:=[ 1.0+0*I,
        -0.5+evalf(sqrt(3)/2*I),
        -0.5-evalf(sqrt(3)/2*I)
       ]:
#
# Specify the rgb sub-arrays
#
  rgb:= [ Array(1..3, [1,0,0]),
          Array(1..3, [0,0,1]),
          Array(1..3, [0,1,0])
        ]:
#
# Run the calculation: the outer two loops just
# generate the starting value across the range
# -2-2*I to 2+2*I. Yje case 0+0*I has to be trapped!
# 
  for i from 0 by 1 to npts do
      for j from 0 by 1 to npts do
          zold:=bl[1]+j*step+(bl[2]+i*step)*I;
          if   zold=0+0*I
          then break
          else zold:=evalf(zold);
             #
             # Run the iteration
             #
               while true do
                     znew:=zold-(zold^3-1)/3/zold^2;
                     if   abs(znew-zold) < 1e-06
                   #
                   # if true, convergence has been achieved
                   # so check which root is obtained and
                   # populate the output arra with the
                   # appropriate sub-array, and brak from
                   # this inner loop
                   #
                     then A[i,j,...]:= rgb[min[index](abs~(rts-~znew))];
                          break;
                     else zold:=znew;
                     fi;
               od;
          fi;
      od;
   od;
#
# Check time
#
   time()-st;
#
# Display image
#
   pic:=Create( npts+1, npts+1, A):
   Embed(pic);
#
# Write out image - path name will need to be changed
# depending on user
#
  Write("C:/Users/TomLeslie/Desktop/basin.jpg", pic):
                             87.703

basins.mw

There are a few problems with this worksheet

1. A couple of simple typos whihc I have corrected (and indicated) in the attached.
2. After fixing these, dsolve the produces a solution module, but it cannot be evaluated, beyond the initial time. My thought was that thsi might be related to the use of piecewise functions which rely on dependent variables, so I replaced these with hs1:=, hs2:=1, hd3:=1 in the attached. This produces a graph - but not for long!
3. the stop_cond option which you uses in the dsolve command triggers at around t=5e-03, so I have graphe all dependent variables up to thhis point
4. I think if you want to reinstate the" piecewise behaviour", you are probably going to have to use the 'events' option with discrete variables. See the help at ?Events for dsolve[numeric]. I have added a link to this in the attached. I warn you, that (in my experience of using events, particularly with discrete variables), this is a non-trivial exercise, and possibly best practised on a "simpl"e ODE system

Good luck with the attached, which for some reason won't display inline on this site - becuase somebody has broken something AGAIN!

odeProb.mw

See the attached for the simple plot in your question.

For future reference, please use the big-green up-arrow in the Mapleprimes toolbar to upload worksheets, rather then "cutting-and pasting"

So else what could be wrong?

1. Wrong Maple version for your OS? Unlikely but possible. The attached shows how to use the interface(version) command to return bith you OS and the Maple version you are running.
2. Installation problem - try reinstalling, but not before you have read to the bottom of this list for other possibilities
3. "Legacy" .init file. If your previous Maple installation had some "clever" stuff in an .init file this *may* be an issue, because installing an upgrade will probably copy your legacy .init file
4. Licensing issues. It has often been reported ithat if some aspect of you licensing is incorrect, then (unlike many other software packages, whihc will just refure to run), Maplee will actuall "run", but just produce completely erroneous output. I think this is just the method used by those at Maplesoft to annoy anyone trying to pirate the software

I would display the output of the attached worksheet inline on this site, but once again some lamebrain at Maple has "improved" thsi site so that simple inline display of trivial worksheets is no longer possible

Download simpleplot.mw

Probably several ways to do this, but the attached is the "simplest" I can come up with - basically divide the current time (t) by the "period" (T) and if the remaindet is less than "duty", signal is ON, otherwise signal is OFF.

Check the attached

Download duty.mw

of which the attached (using the geometry() package) is just one

Download pbola.mw

for log(), which states (emphasis added)

For complex-valued expressions x,  ln(x) = ln(abs(x)) + argument(x)*I, where  -Pi < argument(x) <= Pi. Throughout Maple, this computation is taken to be the definition of the principal branch of the logarithm.

So when you take the imaginary part of  the logarithim of a complex number, the answer will always lie within the range -Pi..Pi

- just because I like alternatives

Download hypLine.mw

but I suspect that the existence of the print() statement means that your procedure cannot "autocompile" successfully so when you invoke it, you are actually running "native" Maple code.

When you comment out the print() statement, Maple does its best to compile the procedure (and may even think it has succeeded), but as a general rule, you cannot "compile" commands from a Maple package (such as combinat) - so the "compiled" version will not run.

So your problem is more with the statement

options threadsafe,autocompile:

than anything else.

Note that the attached runs correctly with/without the print statement

Download fib.mw