Here's an example. Here I use 2x2 matrices to save space. I'm sure that you'll be capable to generalize this. The essence is the use of unapply to turn one matrix with a parameter into a constructor for other matrices. (The ?unapply command is much more general than just being used for matrices.)

Download Matrix_function.mw

Yes, the "problem" is caused by the lack of end proc. You can avoid the problem two ways:

1. When you want a blank line, use Shift-Enter (or Shift-Return) instead of Enter (or Return). Don't hit Enter until you're ready for the procedure to be processed ("parsed" is the lingo). If you do hit Enter prematurely, just ignore any error message and put the cursor back where you want it. This takes a bit of getting used to, which brings us to my preferred method...
2. From the Insert Menu, create a Code Edit Region. This gives you a box, a subwindow, that you can use like Microsoft Notepad or other primitive text editor. Here, Enter just gives you a new line. When you want the code to be parsed (and Executed, if it's more than just a procedure definition), right-click in the box and select Execute Code. You can resize the box by left-clicking in it and then dragging one of the blue square dots on the sides or corners. But the box doesn't need to be big enough to hold your code; it will scroll if needed.

Put a semicolon after the end proc.

The proc line should not end with a semicolon.

There is also a mistake in your type declaration, but the mistake will unfortunately not generate an error message. If you want a parameter to be restricted to having both type A and type B, then the type is And(A,B). So with that the proc line becomes

Grade:= proc(mark::And(nonnegative,numeric))

You should look up a user named Rupunzel on this forum. She got help about this very same homework problem in two separate threads a few days ago. There's a Users tab at the top of the page.

For me, in worksheet text mode, the alt codes generate different characters than the characters accessible programmatically by Maple. (I haven't explored the possibility of getting more characters with MathML or XML.) But, I see that you got a thorn for character 254, which is the same as Maple's standard font's 254. So, I can just plot the standard font for you:

plots:-display(
    plots:-pointplot([[0,0],[16,16]], color= white),
    plots:-textplot(
        [seq([.5+irem(k,16), .5+iquo(k,16), convert([k],bytes)
             ,color= black, font= [times, roman, 24]
             ]
             ,k= 0..255
             )
        ,seq([irem(k,16), .75+iquo(k,16), sprintf("%d",k)
             ,color= blue, font= [times, roman, 9], align= {above, right}
             ], k= 0..255
             )
        ]
    ),
    labels= ["low nybble", "high nybble"],
    labeldirections= [horizontal,vertical],
    axes= boxed,
    axis= [gridlines= [$(1..15)]],
    tickmarks= [(1/2 +~ [seq](k, k= 0..15) =~ [$(0..9),A,B,C,D,E,F]) $ 2],
    axesfont= [times, italic, 16],
    labelfont= [HELVETICA, bolditalic, 16],
    title= "Character codes 0-255 in the regular font",
    titlefont= [HELVETICA, BOLDOBLIQUE, 24]
);

When you plot this in Maple, you'll need to enlarge the plot with your mouse so that the characters fit neatly in their boxes.

As posted, you have overlapping ranges for x, so I think that you meant for the upper bound of x in the first line to start -2*Pi instead of 2*Pi, and my code below reflects that change. Note that the constant Pi is capitalized in Maple. That being said, what I get from your ranges is a nonagon, not a hexagon.

Plotting a surface over a complicated region in the plane involves the same steps as setting up a double integral over that region. You've already done the hardest part---defining the ranges. I chose an f, and here's the rest of the steps.

Download poly.mw

After executing the statement

gn:= g;

gn is identical to g, so any changes made to gn will automatically be made to g also. To avoid this, i.e. to create a separate independent matrix, use copy:

gn:= copy(g);

But I can't tell for sure if this is what you need because you never use gn after constructing it. So the only way that the code as posted makes sense is if the changes are made to g. Perhaps you didn't upload the whole code.

Also, the double if statement at the end can be replaced by

if not (j in s[i] xor n in s[i]) then g[j,n]:= 0 end if;

To avoid unintended conversion of monomials, you can check if the expression is of type `+`.

Example:

Download poly.mw

You simply need to do

eval(x(t), dsn1(1));

Let me know how that goes.

Building upon Markiyan's excellent observation about erf (which I wish I could vote up, but can't because it's a comment), we see that the Asker's original problem can be done thus (which I call going one step backwards before going forward):

And also we see that Maple's algorithm for arbitrary order differentiation could be very easily improved. It would be trivial for it to check this method after other methods have failed.

Download errdiff.mw

You've made the classic so-called fencepost error. Think of the trapezoids as the gaps between posts of a fence, and think of the evaluation points as the fenceposts. There are n of gaps, hence n+1 posts. In your CompTrap, you have n+2 evaluation points: a, b, and n done in the loop. The loop needs to stop at n-1.

Also, in your test comparison integral, you are integrating from 8 to 1. You should go from 1 to 8.

You can compare your procedure with Maple's own trapezoid rule procedure like this: The call

CompTrap(f, a, b, n);

should produce the same result (*footnote) as

Student:-Calculus1:-ApproximateInt(f(x), x= a..b, method= trapezoid, partition= n);

This is a good way to test whether your procedure is correctly implementing the rule. 

It is also good to compare against the integral done by Maple's more sophisticated methods, as you did. This is a way of testing whether the rule itself is good, not testing your implementation of it. You can also study the rate of convergence of the rule.

A matter of style in your procedure: Be careful of how you mix "pure" exact symbolic computation with floating-point numeric computation. Your procedure has 0.5 near the end. You should probably change that to exact (1/2).

Regarding your Simpson's Rule procedure: In addition to the fencepost error, there five other errors in that, three algorithmic and two syntactic. Two of the algorithmic errors are super obvious and the third is subtle; both syntactic errors are essentially the same. If you find any two of the five, I'll point out another two. Deal? Also, why did you change the parameter n from the trapezoid procedure to j in the Simpson's procedure? Maple doesn't care which you use, but the change may have clouded your thinking and led to one of the errors.

You can test/compare your procedure with Maple's own implementation of Simpson's rule by using the same Student command as above, but changing trapezoid to simpson.

(*footnote): After you apply evalf, there may be a small deviation due to rounding error. This may affect the last digit.

You were close. That's actually fairly impressive for one's first day with Maple (and the day is young in my time zone).

An unevaluated function does need to have at least a name, something to put immediately in front of the (a, b, c, d). You are right that no explict expression or -> is needed. I think from your example that you want to name it B. Do this:

restart;
mtaylor(B(a,b,c,d), [a=e,b=f,c=g,d=h], 2);

Does that give you what you want? I made the order 2 because 1 is too trivial an example for you to see what Maple is doing. Please feel free to followup here on MaplePrimes. Have fun exploring Maple.

@iazaroff I wasn't suggesting that you switch to Maple Input permanently. Rather, I was asking as a means of testing what was wrong with your particular system. But it's fine with me if you do switch to Maple Input. I never use 2D Input myself, and I find that it's much harder to answer other users' questions if they use it.

Someone else who is more adept with the 2D Input than I am can probably fix your problem. However, If you're happy with the Maple Input, you can do as I do and make it the default: Go to the Tools Menu, then select Options, then the Display tab. In the top box, select Maple Notation, then click Apply Globally at the bottom.

That one does not simplify. But that is not analogous to your first example: This second example has a product of two square roots in numerator; the first has a single square root in the numerator. In general, sqrt(a)*sqrt(b) <> sqrt(a*b). If I make this small change in your second example (combining the square roots in the numerator), it will simplify to 1 without using assumptions.

I can't find a set of assumptions that will work on your second example. I'll admit that's a deficiency of the assumption facility. But I can force the potentially invalid rule (although it's perfectly valid if everything under a radical is positive) by using applyrule like this:

Note that this is valid for any E.

Download simpsqrt.mw

@iazaroff Hmm. I guessed wrong.  Try this: use the pull-down menu to change the input mode from "2D Input" to "Maple Input". Then, at the red "> ", type explicitly (i.e. do not use the palettes)

sin(Pi/4);

(including the semicolon), and then press return (or enter). The characters you type should appear in red boldface. Maple should respond 1/2*sqrt(2), but it should be in the usual mathematical notation, and it should be in blue.

Let me know how that goes.

If I apply simplify or even expand to your expression, it simplifies to 1 with or without any assumptions. I'm using Maple 16. What version are you using?