@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.

@kjell 

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.

@C_R 

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.)

https://www.youtube.com/watch?v=k6Y7CBSzONw

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.

@ecterrab 

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.

@ecterrab 

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?

@C_R 

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.

Load the Student VectorCalculus package and define the vector q:=Vector(<1,0,0>).

Change to spherical coordinates:

MapToBasis(q,spherical) => (1)*e[r]+(Pi/2)*e[phi]+(0)*e[theta]

So, the Physics convention has been imposed, as it has been since at least Map;le 2016 (thee earliest version I can access). To reverse the meaning of the names phi and theta, do MapToBasis(q,spherical[r,theta,phi]) =>(1)*e[r]+(Pi/2)*e[theta]+(0)*e[phi]. Note that it's the position of the angle names in the triple of coordinate names that determines the meaning of these angle names.

However, MapToBasis(q,spherical_math) leads to an error (spherical_math is not one of the 5 coordinate systems supported by the Student package). Therefor try

VectorCalculus:-MapToBasis(q,spherical_math) => (1)*e[r]+(Pi/2)*e[theta]+(0)*e[phi], which is the same as if "spherical_math" were just "spherical."

The reason for this: the "changecoords" command applies only to scalars. To change coordinates in a vector in one of the VC packages, the MapToBasis command is essential. Otherwise, the basis vectors will not be subjected to the change.

Also, note again that in the VC packages, it's not the names of the spherical angles that matter. Perhaps for display purposes, yes. But the function (i.e., meaning) of the angles, no matter what their names, it's the position of the angles in the triple [name1, name2, name3]. The middle name in that triple is always the angle down from the z-axis; the third name always refers to the angle around the z-axis.

Perhaps the help page at ?coords could have mentioned these two issues - (1) the changecoords command is a top-level command, and has nothing to do with what happens in the VC packages. In those packages, the MapToBasis command is much more important but has been left ignorant of the option spherical_math; and (2) the meaning of the names used in spherical coordinates is determined by the position in the triple of coordinate names, not by the names themselves.

@JAMET 

It's easy enough to sketch a drawing with pencil and paper. Would that suffice, or do you want to see the Maple code that would draw such a figure? (I don't find it particularly easy to use Maple as a drawing tool.)

@Ahmed111 

In the LinearAlgebra package, the noncommutative multiplication operator is the period. I don't know if you used the period and it displayed like a centered bold black dot. I think you will have to figure out a proper entry for z1. If it continues to contain a mixture of ordinary multiplication and noncommutative products, I'm not sure how you can simplify and collect on lambda.