You write that x and y are both restricted to [-1,1]. But then you also write that x>=0 and x<y. If that is all true, then both x and y are restricted to [0,1].

Is this close to what you want?

> restart:

> f:=C*exp((-0.001*x)-0.002*y):

> int(int(f,x=0..y),y=0..1);
                                  0.4991675 C
 
> C_sol:=solve(%=1);
                             C_sol := 2.003335554

> Fx:=int(eval(f,C=C_sol),y=x..1);
 Fx := 1001.667777 exp(-0.003000000000 x)
     - 1001.667777 exp(-0.001000000000 x - 0.002000000000)
 
> int(%,x=0..1);
                                   1.0000000
 
> Fy:=int(eval(f,C=C_sol),x=0..y);
 Fy := 2003.335554 exp(-0.002000000000 y) - 2003.335554 exp(-0.003000000000 y)

> int(%,y=0..1);
                                   1.0000000

Or do you perhaps want to drop some of the restrictions on x?

Did you want to use `spacecurve` instead of plot3d? (You wrote "surface", but your equations seem to parametrize a space curve.)

`solve` and `evalc` may have different (default or otherwise) conventions about whether abs() and unassigned names are complex.

> seq(eval(kr+ki*I,x),x in [solve(evalc(sqrt(5)=abs(1+(kr+ki*I)*I)),{kr})]);
                          2 1/2                        2 1/2
            (4 + 2 ki - ki )    + ki I, -(4 + 2 ki - ki )    + ki I

> solr:=simplify(convert(evalc([%][1]),piecewise));
                 {                      2 1/2                     1/2
                 { (ki + (-4 - 2 ki + ki )   ) I        ki < 1 - 5
                 {
         solr := {                2 1/2                            1/2
                 {  (4 + 2 ki - ki )    + ki I          ki <= 1 + 5
                 {
                 {                      2 1/2                1/2
                 { (ki + (-4 - 2 ki + ki )   ) I        1 + 5    < ki

> simplify( eval( eval(kr+ki*I,kr=solr), ki=0 ) );
                                       2

> simplify( eval( eval(kr+ki*I,kr=solr), ki=1 ) );
                                   1/2
                                  5    + 2 I

I should be easier to get "all" the possible solutions for complex-valued variable k=kr+ki*I, yes? (I mean for general problems passed to `solve`, not just simple examples.)

On the "j" vs "I" front,

> restart:
> interface(imaginaryunit=j):
> sqrt(-9);
                                      3 j

> j^2;
                                      -1

> I^2;
                                       2
                                      I

Is the nilpotent index the leading power of the minimal polynomial (where nilpotency is true iff the min poly is a pure power)?

> Nilpotent:=proc(A::Matrix)
> local x, mp, G;
>   mp:=LinearAlgebra:-MinimalPolynomial(A,x);
>   if type(mp,`^`) and op(1,mp)=x then
>     true,op(2,mp);
>   else
>     `and`(seq(`or`(solve(G,indets(G,name) minus {constants})),
>               G in PolynomialTools[CoefficientList](mp,x)[1..-2])),
>      degree(mp,x);
>   end if;
> end proc:
>
> M:=Matrix([[0,0,0,0,0],[6,0,0,0,0],[0,2,0,0,0],[0,0,8,0,0],[0,0,0,3,0]]):
> Nilpotent(M);
                                    true, 5

>
> M:=Matrix([[w,y,z,s,t],[6,w,y+z,0,0],[0,2,0,0,0],[0,0,8,0,0],[0,0,0,3,0]]):
> Nilpotent(M);
{t = 0} and {s = 0} and

    /              z (w - 6)                                 \
    |{w = w, y = - ---------, z = z} or {w = 0, y = y, z = 0}| and
    \                  w                                     /

                                2
                               w
    {w = w, y = y, z = -4 y + ----} and {w = 0}, 5
                               2

You should check whether this is correct!

Oh, I see now that the handling of the conditional return requires more work. Is there a utility which converts the results from solve and correctly maps in the `or` and `and` calls, to get a valid equivalent expression?

Start with the Help system. Find relevant help pages, and look especially to the Examples sections.

You could start here or here.

Or, are you supposed to program Euler's method yourselves?

Maple does not always automatically simplify results. You can put it into normal form, or simplify it.

> normal( eval( rhs(eq1)-lhs(eq1), sol ) );
                                       0

> simplify( eval( rhs(eq1)-lhs(eq1), sol ) );
                                       0

There are slicker ways to code it, but since you are getting started...

eq1 := diff(x1(t),t,t) - 3/85 * sin(w*t) = -2*k1 + k2:
eq2 := diff(x2(t),t,t) = k1 - 2*k2 + k3:
eq3 := diff(x3(t),t,t) = k2 - 2*k3 + k4:
eq4 := diff(x4(t),t,t) = k3 - 2*k4 + k5:
eq5 := diff(x5(t),t,t) = k4 - k5:

sol := solve( {eq1,eq2,eq3,eq4,eq5}, {k1,k2,k3,k4,k5} );

# now check that it's correct
eval( rhs(eq1)-lhs(eq1), sol );
eval( rhs(eq2)-lhs(eq2), sol );
eval( rhs(eq3)-lhs(eq3), sol );
eval( rhs(eq4)-lhs(eq4), sol );
eval( rhs(eq5)-lhs(eq5), sol );

See also ?LinearAlgebra,GenerateMatrix

There must be lots of ways to do this, likely better. But this seems in roughly the same spirit.

> T:=proc(f,x)
> if type(x,float) then fprintf(f,`%.5g`,x);
> elif type(x,complex(float)) then fprintf(f,`%.5Zf`,x);
> else fprintf(f,`%a`,x); end if;
> NULL; end proc:

> A:=[-0.123456-0.123456*I,0.1334423423*10^(-15),3]:

> writedata('terminal',A,string,T);
-0.12346-0.12346I
1.3344e-16
3

It wasn't clear whether you wanted flow control back, while it ran, or whether you would update x to false inside the loop according to some calculation. I've done it the second way: when g()=7 it stops. The first way could be done by removing the g() and the bit that sets x:=false, stuffing the loop code in a proc and starting that in a Thread:-Create. See here.

> restart:
> kernelopts(printbytes=false):
> g:=rand(10^6):
> st:=time[real]():
> x:=true:
> while x do
>   if time[real]()-st > 2 then
>     st:=time[real](); print([A,st]);
>   else
>     # stuff
>     if g()=7 then x:=false; end if;
>   end if;
> end do;
                                 [A, 629.758]

                                 [A, 631.759]

                                 [A, 633.760]

                                 [A, 635.771]

                                 [A, 637.772]

                                 [A, 639.773]

                                 [A, 641.774]

                                 [A, 643.775]

                                 [A, 645.776]
>                                                          

Maple had only 1D Maple notation up until a few years ago. It still has that, but now there is also so-called 2D Math notation.

In 2D Math, the syntax f(x):=... can mean one of two things. It can be used to denote a function definition, or it can be used to specify a remember table assignment.  In 1D Maple notation, it can only mean a remember table assignment. Historically, it only ever meant remember table assignment. The disambiguation of that syntax to allow for function definition is quite new.

Ok, so, what is a remember table? It is a "hiddden" table that every Maple procedure has. It is a place where previously computed values can be stored. The basic purpose is to allow Maple to immediately look up a precomputed value, without having to take time to recompute it, if the same argument gets passed again to the procedure. But values computed and returned by procedures are not always stored. Values are only stored to the rember table if the procedure is created with `option remember`, or if an explicit remember table assignment is made.

Let's have a look at some simple examples of what can happen. (You could also see this help page.) All the code below is entered in 1D Maple notation in a Worksheet, so keep it unambiguous.

> restart:

> f := proc(x) option remember; x^2; end proc:

> op(4,eval(f)); # the remember table is empty. nothing's shown.

> f(3), f(t);
                                        2
                                    9, t 

> op(4,eval(f)); # print the remember table of f
                             table([t = t^2, 3 = 9])

In the code above, those returned values are stored in the remember table simply because f has option remember. But we can also make an explicit remember table assignment.

> f(7) := 100; # we force this value, even though 7^2 is 49
                                     100

> op(4,eval(f)); # print the remember table of f
                        table([t = t^2, 3 = 9, 7 = 100])

> f(7); # the stored value is remembered!
                                     100

Now, let's try something else. First, restart. Then, let's use the syntax of an explicit remember table assignment, even though we do not first define f as a procedure.

> restart:

> f(x) := x^3;
                                  f(x) := x^3;

> eval(f); # look, f has become a form of procedure!
                proc () option remember; 'procname(args)' end proc

That assignment to f(x) actually made f into a procedure. And it's a weird procedure, too. For any argument which doesn't already have an entry in its remember table, this procedure `f` will simply return a call to itself (just as if it were any old name, as if it were hiding its procedure nature). But it does have a remember table.

> op(4,eval(f)); # print the remember table of f
                              table([x = x^3])

> f(x);
                                      3
                                     x 

> f(17);
                                    f(17)

Notice how f(x) returned x^3. That's not because f is a procedure that raises its argument to the power 3. It's because x=x^3 is stored in f's remember table. The procedure f has no remembered value for 17, so the call f(17) returns itself unevaluated. The important thing to note is that f does not compute 17^3.

So, it's all very technical and tricky. A big problem is that f(x):=... is the syntax that almost every new user tries, as a first attempt at creating a function in Maple. And historically, all that would produce for them was this funny procedure like f in the last example above. It just behaved in that crazy way.

The new 2D Math parser provides an opportunity to detect that the user has entered something like f(x):=..., to intercept that, and then to ask what was intended. Hopefully, lots of people new to Maple will understand the dialogue enough to be able to select "function definition" if that's the intention.

I have  few objections to how it`s been implemented, some of which others have previously mentioned. Firstly, you can`t tell which it is underneath, just by looking at that syntax in 2D Math. Second, whichever choice is made is not stored when the Document or Worksheet is saved. So if you pass it to your friend or instructor they have to deduce (cold) what to select when that dialogue pops up again for them. And lastly, the 2D Math parser could instead simply replace the typed f(x):=... with f:=proc(x)..., and in doing so teach the unambiguous syntax. I don`t object because the disambiguation dialogue is new and different. But I do think that the implementation issues mentioned are serious enough to detract from the benefits,

The 1D syntax for the exponential function is exp(x) not e^x.

Maple leaves sin(1) alone because it is an exact quantity with no more useful, terser representation (and Maple is a computer algebra system and is often capable of discriminating usefully between exact values and approximate floating-point values). You can enter sin(1.0) as just one of several ways to get immediate floating-point computation of an approximate value.

eval(alpha[2],Result);

Your definition of rect is this.

> rect:=t->Heaviside(t+1/2)-Heaviside(t-1/2);
             rect := t -> Heaviside(t + 1/2) - Heaviside(t - 1/2)

Your argument to your second plot call is simply this.

> int(rect(t-1/2)*cos(t)*exp(-I*t), t = -infinity .. infinity);
                                                              2
                1/2 - 1/2 I + 1/2 cos(1) sin(1) + 1/2 I cos(1)

That last result is a constant expression, which represents a nonreal (complex) number. It is approximately this.

                         0.7273243567 - 0.3540367091 I

The plot command doesn't do anything meaningful with that value as the only argument. Did you intend the integral to vary, according to some other variable (say, T)?

The usual way to handle this is to set up P so that it returns a call to itself unevaluated for nonnumeric arguments. In this case, it might look like this.

P := proc(d)
  if not type(d,numeric) then
     #... the computation ...
  else
     return 'procname'(args);
  end if;
end proc:

There are some refinements possible. When using parameter-processing it may be preferable to return 'procname'(_passed) instead.

You're using time[real]() and not time().

The first of those measures wall-clock time, which means it's measuring the elapsed real-world time including cycles used by Maple and also by every other process vying for the same CPU. Hit Ctl-Alt-Del and select the Task Manager (or run `ps` on Unix/Linux) to see all the other processes that your Operating System might be running concurrently. Just because you machine looks inactive doesn't mean that schedulers are checking, disk isn't being committed, etc. A wall-clock time measurement takes into account all cycles used by all processes, not just Maple, in the interval between calls.

The second command, time(), measures cycles devoted only to Maple itself. Even for that there can be some small variation according to what's gone on before in the session (memory management or GUI redraws might be at a different state at exactly that same point). Very fine timing agreement shouldn't always be expected.