Yes, symbolics are our friends, but dsolve() won't output a direction field. We ask the students to use the DEplot command on various differential equations so that they can see the direction field very easily and learn how to interpret them.

Yes, symbolics are our friends, but dsolve() won't output a direction field. We ask the students to use the DEplot command on various differential equations so that they can see the direction field very easily and learn how to interpret them.

I'm sorry. When I read your question the first time, I didn't notice that you were talking about components. No, I'm just talking about regular old text in a text field in a worksheet or document. For example: I want to distribute a worksheet to students, and I want to make sure that certain parts (section titles, notes, reminders, etc.) cannot be edited, then I can go in with a text editor and manually add an attribute to the Text-field (xml) containing that text, but I cannot find any option in any menu that will allow me to do the same from the GUI. For note, this power was definitely in Maple 7, probably in Maple 8, possibly in Maple 9, and I can't seem to find it in Maple 10.

Yes, my apologies. I was referring to the former. Where is the option to set this text as 'editable' or not? I can't seem to find it.

Yes. I dislike referring to Maple as containing two separate languages, but this example goes to show that there are subtle differences in the input modes. In theory, Maple should be able to understand itself fully, so there shouldn't even need to be a distinction between input types. For a more deliberate rant on 2 related but subtly different languages inside of Maple, look here to my discussion of the Worksheet and XMLTools packages.

Input method aside, they are the exact same string and should be treated as exactly the same in Maple. However Maple decides to display what I have entered (as input or output) is not important.

Looking at the output form showstat(Matlab:-TranslateName); , I see now where this comes in and why. It is rather annoying, though, to have tools specifically for the Matlab package loaded when the Matlab package is not loaded.

Are the two ideas of "constant" all that different? Maple, at its base, seems to want a "constant" to be any object which represents a single complex number. Although this this idea is more restrictive than "mathematical interpretation" of "constant," is it not the case that every Maple constant is a mathematical constant? In other words, is it not the case that the set of all objects that Maple would consider to be constants a proper subset of the set of all objects that would be considered constants by the "mathematical interpretation?" I do agree with you, though; your final point is the point I've been trying to make: The language is not clear. If I can evaluate an expression and receive a constant, does that expression not evaluate to a constant?

I agree with what you say; however, that is not the source of my confusion. The crux of my argument seems to be the word "evaluates." I see it as this: The expression x+3 is not a constant. If I were to evaluate "x+3" at x equal to some constant, then the resulting expression would be a constant. Thus, x+3 would "evaluate to a constant." In other words, I read "evaluates to a constant" and I equate it to meaning "type( eval( c, PARAMETER=CONSTANT), constant ); returns 'true.'" (where PARAMETER is any single parameter contained in c, and CONSTANT is any appropriate constant).

The exact distinction being ...?

If this is truly the case, then it would seem that I am mistaken either by the term "undocumented" or what is in the documentation. Yes, the help page ?implicitplot has (since Maple 7, if I recall correctly) stated that the endpoints a,b,c,d must evaluate to constants. Is it not the case that, for the command implicitplot( f, x=a..b, y=c(x)..d(x)); , where the functions c(x) and d(x) evaluate to constants for all values of x in [a,b], the endpoints all evaluate to constants?

Thank you. I'll keep this in mind for future posts.

It seems that this messageboard took what I wrote and handled it correctly. Let me try this again: If you were to, instead, open the worksheet with a text editor, you would notice that the contents of the command prompt in question is: _quot;\134_quot;foo\134_quot;_quot;; Where each _ represents an &. My apologies for the confusion.

Yes, we understand this. Yes, the r is basically an escaped local from the evalf() command (more specifically, from evalf/Sum1 ). When evalf() evaluates the Sum, it performs a simple addition loop which assigns the value at each step to the same name, r. Since we're passing a function (or, as further testing has shown, any unevaluated procedure call) through the Sum, that procedure call gets stuck (since it is not evaluated). What I really don't understand is why Maple is able to keep tacking on those procedure calls in the recursive sum and display the end result once, but not able to display it again. And I guess I should have been more specific in my initial posing of the question. This is an example of an untrappable error: An error which kicks us back up to the top level of Maple every time, regardless of try/catch statements or the like. Yes, there is an easy fix for this answer if we are allowed to change the statements which lead up to the problem, but our system takes what the students input and run it through grading code as is. There is no human interaction. Normally, errors are no problem. This error, however, kicks us out of our grading code. We need some way of trapping (or, at least, disarming) an untrapple error. That's why I made the post: To see if anyone had any ideas or could answer the question of how to track/trap an untrappable error. Luckily, as was noted in my last reply, we came up with a work-around using ToInert() and evaln(). ToInert gives us just enough information about what's inside the name given by evaln() for us to test, but not enough information that Maple had to evaluate the statement and cause the recursion error. I know that this may not be the best way around it, and I know that there are other types of untrappable errors in Maple; so, I guess my question still stands. Anyone know? --Schivnorr

The problem actually comes from the evalf() command evaluating the sum. The sum is not proper, but does not cause an error. The point of my post was to point out an intractable error that we could not handle (trap and disarm) automatically. We very readily realize that all that needs to be done is to change f to f(x) in the statement of leftsum. We have a home-made system similar to Maple TA where we can automatically grade Maple worksheets. Students are making this error. Normally, errors are no problem (that's why they make greades, right?) But this error kicks us entirely out of our grading code. Since making the post, one work-around has been discovered, although it is not exactly satisfactory: restart;with(student): f:=x->x; a:= evalf( leftsum( f, x=1..2, 6) ); b:= evalf( leftsum( f(x), x=1..2, 6) ); aa:= ToInert(evaln(a)); bb:= ToInert(evaln(b)); So we can look at op(2,aa) and op(2,bb) before either variable is called (calling the variable is what causes the infinite recursion error to spring up). --Schivnorr