Is there any reason you can't put 30 or 3000 entries in the display function using the seq( ) function?

For my purposes, gifted students are those that like to explore mathematics, to see the structure in it, and ask what if questions. For them, having a CAS would not inhibit or prevent them from understanding the ideas behind what they are using Maple to because one cannot usefully experiment without this knowledge. I would have liked to have had Maple in at least third grade. But alas back then computers were programmed with boards and were huge objects. On the other hand, the large mass of students only want "answers". I have seen many, even at the university level, who can't even do fractions because they are so computer dependent.

(1) The whole point in doing the symbolic calculation is that I want any expression that depends on the Matrix A to change when A changes. That is, however, impossible. The next best thing seems to be to change whenever the indexed values of the symbol changes. (2) The following is a somewhat deeper example than my previous one. The problem here is that one cannot use the symbol option in conjuction with any other initializer. And, the symbol "a" cannot be in the Matrix constructor used to define "a", because the definition is done recursively, unlike the linalg constructor. Notice that that means that I cannot redefine "a" to have the values I want with the Linear Algebra Matrix( ) constructor but need to use the linalg matrix( )constructor. In the example, I first try two ways using LinearAlgebra to achieve the resulting C_LA that I want, without success. Then I do it easily with linalg matrix( ) constructor. >unassign('a', 'b'); A_LA := Matrix(3, 3, symbol = 'a'); B_LA := Matrix(3, 3, symbol = 'b'); C_LA := A_LA.B_LA; # In the following code I get zeros for last row and column of a and thus C_LA a := Matrix(3, 3, [[c, r], [p, q]], symbol = 'a'); 'C_LA' = C_LA; # In the following code I get a recursive assignment error when assigning to a unassign('a'); aa := Matrix(3, 3, symbol = a); aa[1 .. 2, 1 .. 2] := Matrix(2, 2, [[c, r], [p, q]]); 'aa' = aa; a := aa; 'C_LA' = C_LA; # In the following code all works as desired. a := matrix(3, 3, [[c, r], [p, q]]); 'C_LA' = C_LA

I'm back again with a specific example and a general comment. The following code and output shows how the "normal" symbolic evaluation process does not work with LinearAlgebra though it does with linalg. This aspect, rather than particular operations such as the matrix exponential, is what really keeps keeps LinearAlgebra from being symbolic. This behavior goes against the basic symbolic view of calculations in a symbolic algebra program. To add on the ability to do Fortran or MatLab calculations is fine, but not at the expense of eliminating the basic symbolic features of Maple for matrix operations. The first set of code shows how the evaluation works with linalg. When a symbolic multiplication is done, and then a change is made in one of the matrices, that change is automatically made in the result of the first multiplication. This does not work in LinearAlgebra. In LinearAlgebra, one has to change the table entries created with the symbol option when originally creating the matrices, rather than the matrices themselves. However, changing table entries cannot be done in an easy matrix way directly, one has to revert to using a linalg type matrix, which often needs to be built up using linalg routines. So even if one can "use" LinearAlgebra for some symbolic calculations, to get proper symbolic evaluations, one has to constantly fall back on linalg. Thus linalg has not really been "superseded" by LinearAlgebra, and it would be disasterous for many of us if linalg were eliminated without something like ALA really replacing it. The AbstractLinearAlgebra refered to above seems like it would be even more powerful, since it would apparently allow matrices which have symbolic instead of fixed dimensions.

Maple Info:

Comparisons of linalg package with LinearAlgebra package

>

>

>

>

This post was generated using the MaplePrimes File Manager

View 1763_linalg_vs_LA.mw on MapleNet or Download 1763_linalg_vs_LA.mw
View file details

Run the following code, and I hope you will see what I mean. Because of what you are doing, it is necessary to add a few more ways of putting in unevaluated functions ('solve') and numbers (convert(..., symbol). > eq := z = (1+y+y^2-y^3)/(1-y)^3; y_sols := solve(subs(z = .8, eq), y): 'solve'(subs(z = `.8`, eq), y) = y_sols; `check solutions:`; for i from 1 to 3 do y = [y_sols][i]; subs(z = `.8`, y = convert([y_sols][i], symbol), eq) = subs(z = .8, y = [y_sols][i], eq); end do;

I think, but may be incorrect, that any equation system with procedures will be attempted with Newton's method. I also don't yet see anything about `fsolve/sysnewton` that would be affected by simply how complicated the procedure is. Of course, Newton's method doesn't always converge, and convergence does depend on how the equations are formulated (even given an equivalent answer set). The procedure is really a "black box" to `fsolve/sysnewton`. As long as the function implied by the procedure is well behaved enough that the induced numerical derivatives (done by fdiff)can be obtained and Newton's method is appropriate, I can't yet see how the complicatedness per se of the procedure will affect anything. I have tried and succeeded with rather complicated procedures. But I guess one can only hope to find the problems with this idea by trying it.

First, nothing in fsolve directly prevents procedures as such from being used, although they must be used in functional form as f(x,y) rather than as operators, that is as just f. If the procedures simply return algebraic expressions when symbolic input is used, they will be replaced by those expressions before fsolve is run. However, if the procedures do not just return algebraic expressions, then the first lines of code must have a check which will just return the symbolic expression which is in your fsolve argument. You will see this in the two example functions which I use below. Apparently, the reason the help page for fsolve says procedures in systems of equations aren't done is that the existing code gives errors which are due to the use of the subs() function rather than the eval() function. Subs() apparently simply cannot do all that eval can do. When these substitutions are made, fsolve does seems to handle the systems I have used with contain procedures perfectly well. I should add to my previous blog that there are actually four statements that need to be changed. All the changes involve simply switching from subs() to eval() with the corresponding slight change in syntax. All of these changes are made in exactly the same way that the statement in my original blog indicated. The statements that must be changed are numbers 24, 32, 70, and 94. You can see the statement numbers by running debugopts('procdump' = `fsolve/sysnewton`). Here are my example procedures: fnb_1 := proc (x, y) if type(x, numeric) = false then return 'procname(args)'; end if; if x < 0 then 2*x^2+y^2+(-1)*.75^2; else x^2+y^2+(-1)*.75^2; end if; end proc: fnb_2 := proc (x, y) if type(x, numeric) = false then return 'procname(args)'; end if; if 1 < x then 2*(x-1)^2+y^2+(-1)*.75^2; else (x-1)^2+y^2+(-1)*.75^2; end if; end proc: I then run the following fsolve statement. The original form of fsolve just returns the symbolic form of the statement intact, i.e., it cannot find an answer. My revised form returns the correct answer. By turning on debug(fdiff), I can also see that the numerical differentiation function is not being used when the original fsolve is run, while it is being used when the revised fsolve is run. fsolve({fnb_1(x, y) = 0, fnb_2(x, y) = 0}, {x, y}, {x = 0 .. infinity, y = 0 .. infinity}) The correct answer is {x = .5000000000, y = .5590169944} which can be checked by substitution.

Your EMP information page doesn't know anything about mapleprimes being free and says that the old content is still on this page. So, one may ask, where is the content the EMP page refers to?

(1) OK, I see, apparently the only effect of setting prettyprint=1 when printing procedures is to start the printing in column 1 instead of centering it (which is what happens with prettyprint=3). However, print() does not seem to use any of the other prettyprinting features (with either prettyprint=1 or 3) that I can determine *when it is printing procedures outputted by eval()*. (2) I do not know how how [but see last paragraph] the backslashes got doubled. I did not enter them that way on purpose, but obviously I did not catch them when proofreading the entry. Some software, somewhere, did that change on its own. I'll have to watch that in the future to see where it happens and correct it. It should correctly be: printf("%s:\n", RegSubs("\n( +)" = "\n\\1\\1\\1", RegSubs("\n ...." = "\n", debugopts('procdump' = g)))[1 .. -2]) I just copied and pasted the above from a Maple worksheet, and lo and behold, when I pasted, all the backslashes were doubled! I then corrected them manually in the above statement.

Joe Riel's first procedure doesn't do what I want because it prints everything in the middle of the page, and, when copied to an input line, makes all the lines but the first line very indented. The second procedure does just fine, and you do not have to change prettyprint; prettyprint=3 is just fine. In fact, except for all the checking and the module consideration (and, of course, one has to have verboseproc=2o3 to print a Maple library procedure), one can just use one statement ("g" is the procedure to be printed): printf("%s:\\n", RegSubs("\\n( +)" = "\\n\\\\1\\\\1\\\\1", RegSubs("\\n ...." = "\\n", debugopts('procdump' = g)))[1 .. -2]); The thing I learned here is that the output of 'procdump' can be assigned to a name and otherwise used as input to other functions, whereas, as far as I can tell, the output of print(eval()) cannot be captured in this way. The output of 'procdump' is not a string but can be converted to a string by convert( ,string), and it seems that RegSubs() automatically does this conversion if its input is not a string. Then the output of RegSubs() is definitely a string. When the output of this statement is copied to an input line (in standard 2D Maple), tripling the indention works out well. And all the indentions in it are done with simple manipulable spaces. Thanks for the idea Joe.

I presume you mean a numerical solution with A and C given numerical entries. First, you can ask if C*D-1*w=w has non-trivial solutions, if so then clearly v=A-1*w gives a non-trivial solution v for each w solution. Now clearly C*D-1 has an eigen value of 1 from the left (just multiply (1,1,...,1)*C*D-1=(1,1,...,1). Thus C*D-1 has at least one eigen value of 1 from the right. Thus you just need to find the eigen vectors of C*D-1 corresponding to the eigen value 1. Thus you know that your original eigen value problem has at least one non-trivial solution. You just need to use the Eigenvectors routine in the LinearAlgebra package on your original problem. Your solutions are the eigen vectors corresponding to the eigen value 1. Remember that the number of eigen vectors can be less than the algebraic multiplicity of the corresponding eigen value. YOu can use the routine JordanForm to see the complete eigen value, eigen vector breakdown of the matrix. Unless you have 2x2 matrices, you are not going to get a useful symbolic solution.

Was the Remove Output/From Selection functionality somehow removed in 10.04? Did something happen to my Maple? Did I change some preference without realizing it? I was playing a lot with Document Mode and Document Blocks the day or so before I noticed this. Could that have had something to do with the loss of functionality of this menu item? Anyway, I now notice that I can use Delete Element to remove output, although with a few more steps. At least it's a workaround until I discover what has happened.

The general problem seems to be that once an x~ is passed on by assigning a data structure containing it to another name, it becomes an entity on its own, a sort of vintage x~, with no connection back to the original variable on which the assumptions were made. It has no unique name and no way to access it for manipulation or redefinition. The code x:='x' does not affect these vintage x~'s. Even the function addionally() does not affect these vintage x~'s. Thus one can have a whole set of x~'s of different vintage in one's data structures with no way to tell them apart or manipulate them. This has tied some of my codes in knots before I realized what was happening. It would be so much less frustrating if each new vintage received a unique name that could be referenced by the user.

The general problem seems to be that once an x~ is passed on by assigning a data structure containing it to another name, it becomes an entity on its own, a sort of vintage x~, with no connection back to the original variable on which the assumptions were made. It has no unique name and no way to access it for manipulation or redefinition. The code x:='x' does not affect these vintage x~'s. Even the function addionally() does not affect these vintage x~'s. Thus one can have a whole set of x~'s of different vintage in one's data structures with no way to tell them apart or manipulate them. This has tied some of my codes in knots before I realized what was happening. It would be so much less frustrating if each new vintage received a unique name that could be referenced by the user.

Your description uses single quotes around the numbers you assign to the parameters and these numbers are integers. This probably really accomplishes nothing while seeming to. It seems to work because these functions aren't evaluated at integers unless an evalf is forced. It may be that, when inserted in your Maplet code, an evalf is implicitly being done before you see the output. If you put a decimal point after your numbers, you will see that what you have done does not even work in straight Maple. On the other hand, if you use backquotes around the numbers, they are no longer numbers but literal names of variables which have no assigned value. Also you will not see the backquotes in output. I use this all the time to produce notes for students showing the steps in a calculation. Note if you define "a" BEFORE you give values to the parameters then you can always change the parameter definitions amongst symbols, the literal numbers, and the real numbers and see the result using subs() or eval(), etc. (If "a" is defined after the parameters are given values, then these values, not the parameter names, are hard coded into the definition because Maple evaluates the expression before assigning it. Of course, if you put single quotes around the paramenter names when defining "a", that postpones evaluation of the parameters and produces the same result as defining "a" before giving values to the paramenters.)