2468 Reputation

12 Badges

14 years, 344 days

Dr. Robert J. Lopez, Emeritus Professor of Mathematics at the Rose-Hulman Institute of Technology in Terre Haute, Indiana, USA, is an award winning educator in mathematics and is the author of several books including Advanced Engineering Mathematics (Addison-Wesley 2001). For over two decades, Dr. Lopez has also been a visionary figure in the introduction of Maplesoft technology into undergraduate education. Dr. Lopez earned his Ph.D. in mathematics from Purdue University, his MS from the University of Missouri - Rolla, and his BA from Marist College. He has held academic appointments at Rose-Hulman (1985-2003), Memorial University of Newfoundland (1973-1985), and the University of Nebraska - Lincoln (1970-1973). His publication and research history includes manuscripts and papers in a variety of pure and applied mathematics topics. He has received numerous awards for outstanding scholarship and teaching.

MaplePrimes Activity

These are replies submitted by rlopez

@Markiyan Hirnyk 

Markiyan, thanks for your care in reading my response. You are again correct - when x=3, the edge of the triangle is being searched and the "max" is at a vertex. I failed to note the three coordinates of the point I located. Had I done so, I'd have seen the error you so quickly spotted. Thanks again.

@Markiyan Hirnyk 

Markiyan is completely correct in pointing out that the "maximum" does not exist.

But to conclude that the maximum does not exist on the given set, one has to go through my calculations first.

@Alejandro Jakubi 


The old Classic interface might have been useful for those whose use of Maple centered on coding. It was not useful for creating expository mathematical documents. My Advanced Engineering Math book was written with great pains in Maple 4. It was a terrible interface for writing some 273 worksheets that comprised that text. The Standard GUI provides a much more robust set of tools for writing such documents.

Apparently, you are claiming that the Standard WORKSHEET with 1D input is not sufficient for programmers. I can't address that issue because I rarely write extensive Maple code. But if that is the case, I doubt that Maplesoft is being malicious in not providing a better environment for coders. As I understand it, it's a matter of resources.

The Maple interface now called "Classic" dates back to the mid 1990s, and was written in software provided by a company that went out of business long ago. It is impossible to provide any new features in this old interface.

The new (Standard) interface that arrived with Maple 10 comes in two flavors. One can open a "Document" or a "Worksheet." The Worksheet resembles the look and feel of the Classic interface, but provides some additional features that were missing from the interface that supported Maple 4-9.5.

Unfortunately for some, the default input mode in either the Document or the Worksheet is typeset math (called by Maplesoft "2D" math). This can be changed in the Tools/Options/Display dialog, where the choice "Maple Notation" in the Input display box reverts input to the linear "text form" Maplesoft calls "1D" and which was the only input mode available in the old Classic interface.

Coding in a Document using 2D math does indeed pose challenges as described in the accompanying article. I believe coding in a worksheet using 1D math would have been more appropriate for the task described herein.

RJL Maplesoft



If you are entering the Do command outside of an embedded component, then you must either load the DocumentTools package via the command with(DocumentTools) or use the long form for each call to Do via the syntax DocumentTools:-Do(.....




After forming the two equations, apply the solve command as you did in the original post. Your problem was not with the solve command, it was with forming the equations by reading values from the Math Containers.



To read the contents of MathContainer0,  you can use the Do command from the DocumentTools package. To read and assign to a variable, say u, use Do(u = %MathContainer0). If the DocumentTools package is not loaded, then use the long form: DocumentTools:-Do.

It looks like your example reads two coefficients, one from MathContainer0 and one from MathContainer1. The equations so generated would then be

x*Do(%MathContainer0) = -y*Do(%MathContainer1), etc. (It looks like there is no implicit multiplication (space) or explicit multiplication between your variables and what you hoped would be read from the math containers.)



If dsolve returns an exact solution of an ODE, it would be possible to graph it with the plot command.

It must be that you are obtaining numeric solutions, which require different tools. Here is what I would suggest you investigate.

Q:=dsolve({ODE, ICs}, unknown, numeric):

Look at the help page for the odeplot command for all the variants that allow you to draw various graphs with the numeric solution dsolve/numeric has generated.

By the way, we are all trying to "guess the question" because we are stumped by your reference to "ode architect solver."


Don't press the Enter key to re-execute the definition. Place the cursor in the field, and press the single exclamation mark (!) in the toolbar.


Maple's top-level diff command will not differentiate with respect to a function. In the Physics package, diff is modified to allow this. So, define f in terms of x(t) and y(t) as you did, then use Physics:-diff(f,x(t)) to get the derivative with respect to the object "x(t)".



Keeping the same ODE, I tried solving the BVP consisting of that equation and the two Robin conditions

BC:=D(T)(0)=1+3*T(0), D(T)(.2)=5+T(.2)


The command Q:=dsolve({ode,BC},T(x),numeric) succeeded, and the command Plots:-odeplot(Q) drew a graph of the solution of the BVP I had created.

Please try following this example and let us know if the problem you want to solve yields to these ideas.


Draw the graph. Right-click on the graph and in the Context Menu that appears, select Probe Info/Nearest datum. This turns the cursor on the graph to cross-hairs that trace the curves. Place the cross-hair on the intersection. Right-click again, select Probe Info/Copy data. The coordinates are now on the clipboard. Paste into the worksheet. Coordinates appear as a column vector.

I wrote a Newton iterator and solved for the intersection coordinates numerically, but that's a challenge for another day.




The following modification of the procedure given earlier computes f(b,S) using the same idea that each fixed pair of values of (b,S) generates a solution satisfying the first three boundary conditions. If the condition f(b,S)=b*S/2 is then imposed, a curve in the bS plane is generated. So, is S an arbitrary parameter whose value you are seeking, or is it a fixed and known number? If it is parameter, then a curve results. If it is a fixed number, then there is a unique value of b that satisfies all the conditions of the problem.


local bc,Q,F;





I graphed the surface f(b,S) and superimposed the surface defined by b*S/2. These two surfaces intersect in a curve in space, whose projection onto the bS-plane contains an infinite number of (b,S) pairs that satisfy the ODE and the conditions imposed. (I found that the ranges b in [0,1.5] and S in [0,2] generated points for which f was positive.)

Now look at  your specific questions. You ask for a graph of f(b) vs the *parameter* S. If S is a parameter in the ODE, then the solution of the ODE is a function of both b and S, so consider that it is f(b,S), not f(b). What does it mean to graph f(b,S) against S? The graph of f(b,S) over the bS-plane is a surface. It's not clear to me what it is you want here.

Similarly, what does f"(0) mean in the context where S is a parameter? As soon as S becomes a free parameter in the ODE, the "solution" f becomes a function of both b and S, not just b alone. A clarification in the question would help here.

The odeplot command allows you to graph functions of the solution. This is stated on the help page for odeplot, the second bullet in the Description section.

However, it seems Preben has given you a much more detailed solution, one in which you need look up no command or its syntax.

Maple exports to rtf, but when imported into Word, 2D math becomes an image. The export/import process does not result in 2D math changed into the Word equation-editor format. I think one of the products found in the links provided by Markiyan Hirnyk would have to be used, and I think the route has to be via LaTeX to Word. Since the Word equation editor is a cut-down version of the editor in MathType, I suspect that product might be the best tool to employ. Unfortunately, a quick scan of the list of tools Markiyan found seems to indicate that at least one intermediate product would have to be purchased in order to take Maple's 2D math over into Word in a form that the Word equation editor could operate on.

I faced problems like this when I wrote the original version of my Advanced Engineering Math text (Addison Wesley, 2001). At that time, the classic worksheet was inadequate for expressing the full range of mathematical notation, and I used MathType to format some displayed equations, but this worked only in Windows, and not on other platforms. It was a nightmare to embed proper math notation in the classic worksheet, and I welcomed most heartily the extended functionalities in the newer standard interface that Maple provided in 2004.

In the not-too-distant past, I collaborated with an engineering prof who submitted our work to engineering journals that accepted only Word documents. I worked in Maple, but fortunately, my colleague was willing to rewrite everything in Word, a chore that I would not have enjoyed.

This interoperability of math formats is a knotty problem, and I sympathize with waseem, who asked the original question.

First 9 10 11 12 13 14 15 Page 11 of 15