rlopez

2448 Reputation

12 Badges

14 years, 223 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

I believe that any "1D" math (which I prefer to think of as textual input) is equivalent to its "2D" counterpart (which I prefer to think of as typeset input). Of course, I have not tested each and every instance of this in the whole of AEM, so this is a conjecture on my part, based on feedback and information from the developers of typeset math notation.

There are many places where typeset math as input is easier to read. For example, I find reading a raised exponent easier than reading syntax such as x^2. On the other hand, there are lines of Maple code in the AEM book that lean toward "programming" and it's not at all a generally accepted position that typeset math is appropriate for coding.

So much for the pro & con on whether the ebook should have all its "red code" simply changed to typeset "black code."

The bigger issue is whether or not the format of the ebook is optimal. Apparently, there's some voices being raised to the contrary. No doubt, Maplesoft has, in the years since the AEM book was first written, developed many new features in Maple itself that would all for a different paradigm in an ebook. I'll be retiring at the end of the year and meanwhile, I'm contemplating a complete rewrite of the ebook to take into account the new tools available in Maple.

But for now, let me just point out a few details of the evolution of the text and its ebook form. The materials grew from worksheets written in the early '90s for use in my classes at RHIT. These worksheets were exported to LaTex, massaged so that the obvious Maple was removed, and given to Addison Wesley as the deliverable for the text. The worksheets themselves went into the back of the book on a disk. When the text went out of print, I got the copyright back, and at the suggestion of Maplesoft itself, morphed the worksheets that accompanied the book and upon which the book itself was built, into the ebook.

So, the worksheets in the ebook still have the flavor of their classroom roots, namely, to capture the mathematics, and to show users how to implement that mathematics in Maple. In the Maple content projects I've worked on directly for Maplesoft, I've moved in the direction of separating the presentation of mathematics from the implementation in Maple. So, for example, in the calculus study guides I've written, examples are presented in three forms. First, there's a mathematical form where no Maple appears. Then, there's a Maple version using syntax-free techniques. Finally, there's a version using Maple commands.

Would a similar separation of mathematical presentation and implementation in Maple be appropriate for AEM? I really don't know. I wouldn't mind hearing from users of AEM what they think. And for anyone who bought a copy of the ebook and was less than satisfied, I apologize for having failed. But I would appreciate hearing from anyone with suggestions for improvements that I'd like to spend my retirement making.

Go to the View menu and select "Markers" so that you can see the column of opposing triangles that delineate document blocks. Be sure you are entering typeset math in a document block in "math mode."

If you are still having trouble, post some form of display showing what you are doing. Otherwise we are all left to guess at the problem.

RJL Maplesoft

Seems to me that you have values for E, the independent variable. You also need the corresponding values of epsilon, the dependent variable. Given such pairs, there are a  number of ways to obtain a least-squares fit. The easiest way is to use the Curve Fitting Assistant available from the Tools menu. This Assistant is an interactive tool for obtaining a least-squares fit, and a graph of the data points along with a graph of the fitting function.

There are other built-in tools for obtaining least-squares fits in the Statistics package, but these are given in the form of commands whose syntax can be found in their help pages.

RJL Maplesoft

I brought this post to Primes to the attention of Maplesoft's Tech Support group, and received back the following answers. It appears that the scrolling issue has been fixed in the next version of Maple. The sticking cursor problem couldn't be replicated, so it seems that it was fixed in Maple 2015.1.

RJL Maplesoft

@Carl Love I admit that the paradigm Carl enunciates was not in focus as I wrote the blog. The issue to me has been that the examples from which I learned the material all made decisions based on the characteristics of the particular matrix A. I was looking for a process that uniformized these choices. I don't think I completely succeeded in that regard. My process still has points at which choices of basis vectors have to be made.

I've looked at the code Maple uses for producing the transition matrix. If any choices have to be made, it seems that Maple has been coded to make those choices. But I have to admit that so far, I've only scanned the code, I haven't gone down that tedious path of copying and pasting it so that I can execute it, analyze it, etc.

As I mentioned to the development team yesterday afternoon, it's really too bad that the design specs for Maple code didn't require that coded algorithms be accompanied by a mathematical description of the algorithm. I have always found it difficult to extract an algorithm from its code.

If anyone has more facility with this process and chooses to apply that skill to the algorithm by which Maple produces the transition matrix to Jordan form, I, for one, would be happy to benefit by such.

@Carl Love If I remember correctly, I ran many, many, many trials of the code to generate a "nice" matrix A. I varied the loop length, ran experiments, changed how I viewed the results, etc. Eventually, one of the random matrices will turn out to be A, but I wouldn't spend time looking for the exact A that I ended up using.

After all, the point is that the process I sought should work with any such A. But if I had foreseen that this issue would be a hidden distraction, I would certainly have addressed it.

@Carl Love The solutions given by Markyian and by you, Carl, are effective. Here's a hack I often find useful as a first shot at interpreting such messy returns as being discussed here.

print~(L)[];

where L is a list of things to be printed on successive lines.

@Carl Love 

The option in the VectorCalculus package is, indeed, inert, and only inert. However, the option in the Student VectorCalculus package can be either output=integral or just "inert". Verily, an oddity.

 

@krismalo Someone else previously posted about phasors in Maple. One device used was the definition of the conversion factor from degrees to radians: cf:=Pi/180.0. Then, instead of having to include a convert in each call to the polar command, simply write polar(magnitude, cf*angle_in_degrees). To convert an angle in radians to degrees, simply divide by cf.


The restart command clears Maple's memory of previous assignments.

 

The symbol "cf" is a name, or variable.

The assignment operator is "colon equal" and it is used to assign to the variable cf the value computed to the right.

The number cf is then the conversion factor for going from degrees to radians. Maple works in radians.

Replacing the colon at the end of the line enables you to see the result of the executed command.

 

cf:= 2.0*Pi/360;

0.1745329252e-1

(1)

The name "phasor" is the name of a function that the author is defining. Note the assignment operator that follows the name.

The function phasor will have two arguments, namely, x and y.

The arrow, made with a minus sign and a greater-than sign, represents a mapping, the mathematician's view of what a function does. It maps from one set (the domain) to another (the range).

The rule for the function is Maple's built-in polar command. This command takes two arguments, here represented by the letters x and y. The first argument, x, is the magnitude of a complex number. The second argument is the "angle" for the complex number. Here, it has to be y*cf because y will be given in degrees, but the polar command requires the angle to be in radians. This then represents the complex number in as close to "phasor form" as Maple can manage.

 

phasor:= (x,y)->polar( x, y*cf );

proc (x, y) options operator, arrow; polar(x, y*cf) end proc

(2)

 

sol is a new name, to which is assigned the result of the calculation with phasors that was suggested. Note that the calculation is one phasor divided by the sum of two others. Essentially, one complex number is divided by the sum of two others, where the complex numbers are expressed as "phasors."

The evalc is another built-in Maple command designed to put complex expressions into rectangular (a + b i) form, where the imaginary unit sqrt(-1) in Maple is I. (This can be changed to anything you like, including j, but that is a story for another day.)

 

sol:= evalc( phasor(200,0)/( phasor(100,45)+phasor(100,45) ) );

.7071067812-.7071067812*I

(3)

 

The final line is an "expression sequence" containing two results separated by a comma. The first result is the magnitude of the complex number stored in "sol." It is obtained by applying the built-in  "abs" command that actually stands for "absolute value."  The second member of the sequence is the angle of the rectangular complex number "sol." It is obtained by the built-in "argument" command. But this angle will be in radians. The final division by cf converts radian measure to degrees.

abs(sol), argument(sol)/cf;

1.000000000, -45.00000000

(4)

 

``


Download Explication.mw

Explication.mw@krismalo 

Because I'm going to be gleaning such opportunities for explaining members' responses, I looked at this plea for an explanation of Maple code and realized that I just had to respond. See the details in the attachment.

I think I'll also try to insert the contents of the worksheet.

 

@glnritchie The web post you point to contains many interesting ideas for interpreting eigenpairs. Thanks for calling it to our attention.

acer kindly pointed out a subtlety in the middle explanatory box underneath "fraction" in the evalindets command. The phrase "since all the terms of the equation are fractions" should only be interpreted colloquially. In Maple, "fraction" is a very special type, defined as the ratio of two integers with denominator not 1. Carl wisely used type fraction in his work, and not type rational. Type rational would have caught everyting that colloquially was a "fraction", so that terms like 1/x, interpreted by Maple as x^(-1), or x^2, would have had their exponents converted to floats.

acer suggests that a more accurate phrase would have been "since all the subexpressions that are to be converted to floating-point happen to be of type fraction."

As mentor on this post, I should have caught this, but I was as naive as the co-op in this regard. Indeed, this forum is a great place for learning about Maple!

RJL Maplesoft

@Kitonum How do you determine the accuracy of a process that starts with an interpolation of nonuniform data, then does a spline fit to the equispaced points that result, then does an integration? Strikes me that the initial interpolation is the key to the whole process, but its accuracy hinges on what function the data actually comes from. And that is presumed to be unknown. I'm not trying to start an argument, but merely looking for some insight into what I think is a difficult issue.

@Mac Dude Thanks for the feedback. I'll bring your comment to the attention of the folks here at Maplesoft who are actually implementing this series of blogs.

@Alger 

The function of a matrix is not the same as mapping that function onto the entries of the matrix. Use the square root function to convince yourself of this. The square root of a matrix is a matrix whose product with itself is the original matrix. That will not be the case if you simply map the square root onto the elements of the matrix.

First 7 8 9 10 11 12 13 Page 9 of 15