Mr. Roman Pearce

1683 Reputation

19 Badges

19 years, 234 days
Research Associate
Abbotsford, British Columbia, Canada

I am a research associate at Simon Fraser University and a member of the Computer Algebra Group at the CECM.

MaplePrimes Activity

These are answers submitted by roman_pearce

Maybe. Can you post the equations ?
It's worth pointing out that Maple's latex command is completely separate from worksheet typesetting. Some people think they should have made the new interface typeset *in* LaTeX, but that's another issue (read: flamewar). The latex command itself is pretty simple. It's written under the assumption that whatever it outputs will probably have to be edited by the user anyway, so it doesn't try to do anything fancy. It predates the Java interface, and possibly even the Classic Maple GUI. I'm sure something better could be written today. I guess it's just a question of priorities.
You essentially need the cartesian product of [0,1] with itself m times. A crude method is to write a recursive procedure, ie: cartprod := proc(L::list, n::posint) option remember; local i, j; if n=1 then L else [seq(seq([i, op(j)], i=L), j=procname(L, n-1))] end if; end proc: cartprod([0,1], 3); # produces the arguments to B map(B@op, cartprod([0,1],3)); # op breaks the list, and the elements are given to B The problem with this is that it is slow. It constructs a lot of intermediate lists. If you need it to be fast, and you don't care about the order of the elements then you should look up "grey codes".
You should post your education questions to the Maple commons forum. It's perfectly on topic, and I for one would be interested in what you have to say.
If you save the plots to variables you can use the plots[display] or plots[display3d] commands to plot them all together, ie: l1 := [[1,2,2],[3,4,2],[1,5,6],[7,8,9]]; l2 := [[1,2,2.5],[3,4,2],[1,5,6],[7,8,9]]; P1 := plots[pointplot3d](l1, axes=boxed, labels=[x, y, z], connect=true): # be sure to use a colon not a semicolon P2 := plots[pointplot3d](l2, axes=boxed, labels=[x, y, z], connect=true): plots[display3d](P1,P2); Alternatively, if you have a list of things you want to plot: P := map(plots[pointplot3d], [l1, l2, ....], axes=boxed, labels=[x,y,z], ...): # gives you a list of plots plots[display3d](op(P));
In my experience as a TA, I would suggest you don't bother. When people copy and paste it is blatantly obvious. The spacing and variable names are usually the same, and their programs will have the same bugs. If you have doubts, ask the student to explain his or her work. If they can't describe how their program works or why their method solves the problem then they must have cheated in some way. It's as simple as that. Make sure you explain this policy before you enforce it. Tell the students that they are responsible for all of the work they submit, and that they must understand what they have done, or it will be taken as evidence of cheating. Tell them that they can not copy or use portions of another student's solution. Tell them that the proper way to get help from someone is to ask them for the ideas behind a solution, and then go away and work it out on your own. Technological measures like what you suggest are simply too much effort, and the students don't learn anything from you using them. A lot of students go through an entire four-year degree having never learned what cheating or plagiarism is, or what is really expected of them in university. A policy like the one above is going to catch a lot of people who just don't know any better. Take the opportunity to set them straight. As far as "bad students" go, measures like what you suggest are generally ineffective. First, there is always an excuse: "I lost my file so I started from my friend's", etc, etc. If they're smart, they'll give you an excuse which is good enough to create reasonable doubt. Then they will find out what method you used because you will have to confront them with some sort of proof. They will get around that method the next time. You really can't win this sort of arms race, and it's degrading to everyone if you try. It creates an atmosphere of disrespect and distrust. It's far better to set a positive example and hold students to it. If there is any question about cheating, the evidence is in what they submitted. You will get a clear case, instead of an argument based on something hidden in a file. In any case, good luck.
I looked into your problem a little bit before posting this. You have no hope of solving this problem in Maple. In fact, I would be surprised if any software can give you the general solution. The issue is that you have 15 parameters, and the way that these parameters appear prevent you from splitting the system of equations. Any Groebner basis, triangular set, etc. which you try to compute will have coefficients which are polynomials or rational expressions in the 15 parameters. Even if you can isolate a single variable, you will get a polynomial in (probably) 15 or 16 variables because most of the parameters will appear. This polynomial is unlikely to factor, so to solve for just one variable you will have to compute the roots of the polynomial over the 16-dimensional parameter space. You will have to do at least the same thing for every other variable as well, with higher degree coefficients. I think it's a hopeless task. The only thing I can suggest is that you should try to remove as many parameters as possible. Either plug in numbers or try to express some parameters in terms of the others. If this is a robot arm then it shouldn't be too hard to do. If you can get it down to two or three parameters then you might be able to solve the problem, although it may still be too difficult for Maple.
Are the equations all polynomials ? If so, solve may not be the best code. There is Groebner[Solve], RegularChains[Triangularize], and PolynomialIdeals[PrimeDecomposition]. These commands can be better than solve under certain circumstances. If you post the equations I might be able to suggest something, and I can probably tell you if the problem is too hard for Maple.
Please correct me if I'm wrong: you have interface(showassumed=0) and you save a worksheet with assumptions that are not shown, and when you open that worksheet it shows the assumptions ? If so, this is a bug. If, on the other hand, you open a worksheet with assumptions that were shown then you should see the assumptions. In either case, you should see the output exactly as it was saved.
It seems to be a bit more work than that. You do have to use "Format -> Styles" and modify the existing styles. When you are happy with your choices (be sure to test it) go to "Format -> Manage Style Sets" and create a new style set. You can select only what you changed or leave it all selected to save everything. Save it to a file, then load the file as a "User Defined Style Set" in the dialog box. New worksheets will use your style set. You can copy this file and use it on other machines as well.
It worked fine for me in Maple 10. Try setting infolevel[solve] := 5; and tell us where it gets stuck. I've put the solutions at For the record, this is what I did: L := ...; # copied and pasted from here vars := [a, k, v, mu, lambda]; S := {seq(diff(L, i), i=vars)}; infolevel[solve] := 5; sols := solve(S, vars);
The quo and rem commands will do it. See the help page by typing ?quo and hitting enter at the Maple prompt.
It doesn't work on my Linux machine either. Maple 9.5 gives "???" on Macs, but it works on SGI Irix (I got "PST8PDT" for Pacific North America). Does anybody know whether it works on Windows ?
First 17 18 19 Page 19 of 19