3010 Reputation

14 Badges

19 years, 228 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

Yes, I'm observing that also.

Check the article at the end of the following link.


Classroom Tips and Techniques: Maple Meets Marden's Theorem

(Am I the only user who finds the linking mechanism in this utility unfathomable?)


I share Scot Gould's enthusiasm for "MakeFunction" as opposed to "unapply" but forgive him for what is perhaps an inaccuracy in nomenclature.

Scot is right for touting "MakeFunction" but acer is correct in pointing out that unapply (ugh!) has been around from the beginning.

@Rouben Rostamian  

Is it not possible to adapt finite difference schemes to non-rectangular domains? I think the coding gets a lot more difficult, but I know I've seen such FD schemes applied on non-rectangular domains.

But you are correct in stating that finite element solutions are the industry standard. It is unfortunate that Maplesoft has elected to neglect this area of numerical analysis.


The methodology for forming the discretization equations, and for keeping track of the variables is due to Dr. Sam Dao when he was a Maplesoft employee. I only take credit for presenting his methods in as clear a way as I could.

My approach to this problem, captured in my Advanced Engineering Math ebook, maps each unknown to a singly-indexed variable, a much more complex approach. That's why my eyes opened when I saw what Dr. Dao did. And his technique for graphing the computed data is simple and efficient.

I'm glad to have helped. And remember, if you want the worksheet, just contact me.


Maple does not have a numeric solver for elliptic equations, and that includes Laplaces's equation.

View the Youtube presentation: Maple-Based Numeric-Symbolic Techniques for PDE BVPs - YouTube

to see a way for coding a numeric solution. (Sorry, I just could not get the link to work properly.)


If it helps, contact me and I'll provide you with the worksheet upon which the presentation is based.

I appreciate the unsolicited comment and the sentiments expressed by Dr. Guzel. He has long been a booster of that text.

However good or not that work is, I really hope that the essential message in it does not get lost: The only way to teach, learn, do the kind of math that ebook treats is with a tool like Maple. It's not enough to ram that material into students' heads with pencil-and-paper technology, shrug and say, "Oh, you can also do it with a tool like Maple."

Maple must become the instrument by which that material is met and mastered. That was the whole point of the book, and then the ebook after the book itself went out of print. To this end, I just completed bringing the original 2001 text into a collection of Maple worksheets that can be read with the Maple Player, just as it appeared in the Addison-Wesley paper text. Maplesoft and I are just beginning to envision how this readable version of the original text can be made available.


Wow! If this problem can be corrected in Maple 2023 via a Physics update package, it might fix some of the thousands of files in the AEM ebook, something I've been working on and struggling with for at least 4 years. Although the ebook is executed and saved in each new version of Maple, many of the files were first created in older editions. Throughout, I continue to find long dashes where short ones would be preferred. I've found that in versions slightly older than 2023, putting a space between the too-short dash makes it lengthen. There's some magical stuff happening with the GUI display logic that just baffles me. I look forward to seeing this magic subdued. Thanks all for taking this seriously.

@Carl Love 

Thanks to both Carl and Edgardo for clarifying that what happens in the kernel will still happen, so we are talking about the GUI only. Now Carl types in n-x as if that were a possibility. Isn't that automatically a binary subtraction, so that the dash between must necessarily be the long one? If a change is made and n-x can occur, then the change will have failed to correct the underlying problem.


ndash for numbers looks OK. But when I saw the lines where ndash for letters did not equal the long dash for the same letter, I got surprised. Does that mean that if an "ndash" x and a long-dash x were on the same side of an equal sign, they would not add to zero?


Sorry to have short-circuited your happiness, but as I expressed in my initial post, this is a problem that has plagued me (and Maple) for a long time. It probably makes no difference to someone using Maple for computations, but it's an irritant to an instructor trying to match notation to a subtle distinction in mathematical meaning.

By the way, in something like -3 - x, it's visual shock to see the first dash as long as the second.

Thanks for your response. I'm keeping score.

@Carl Love 

Great observation! Indeed, let's hope this is an easy fix that will be implemented soon.

@Carl Love 

Thanks, Carl. I'm deeply into an update of my AEM text, one that differs from the ebook version in that I'm re-creating the original text form of the work. The unary/binary issue is rampant and very tedious to correct. Try inserting a space between a too-long unary sign and what it negates. This changes the size of the sign in older versions of Maple. I don't know what it does in 2023, the version of Maple that induced me to bring the issue to the attention of R&D. Not having gotten to first base there, I've opted to work in earlier versions in the hope that one day, Maple will have the issue resolved.

@Carl Love 

But suppose the OP meant to write sin(x)/cos(x) not becoming tan(x) under "simplify." That was the case with all Maple up to and including 2022. That's fixed in Maple 2023. Just guessing.

Make the functionalities of all the Student packages available via the Context Panel.

1 2 3 4 5 6 7 Last Page 1 of 20