I should know better than to quickly answer such messages late at night after a long day!

I should know better than to quickly answer such messages late at night after a long day!

First, you don't need with(linalg) at all. And you should stick to LinearAlgebra (and thus always Matrix rather than matrix). Second, you will not get the same eigenvalues/eigenvectors numerically as you do with exact numbers because you have repeated roots, so that your matrix (numerically) has a really bad condition number. So you will have to work with exact numbers, which will be much slower. Is there a deep reason why all the eigenvalues are real and non-negative? Is your Matrix naturally positive semi-definite? That might help a lot. Also, what are you really after? Is it really the Eigenvalues?

First, you don't need with(linalg) at all. And you should stick to LinearAlgebra (and thus always Matrix rather than matrix). Second, you will not get the same eigenvalues/eigenvectors numerically as you do with exact numbers because you have repeated roots, so that your matrix (numerically) has a really bad condition number. So you will have to work with exact numbers, which will be much slower. Is there a deep reason why all the eigenvalues are real and non-negative? Is your Matrix naturally positive semi-definite? That might help a lot. Also, what are you really after? Is it really the Eigenvalues?

If you change your last list to L := Matrix((VectorCalculus[DotProduct])(Di, DD-W), datatype = float[8], shape = symmetric, storage = sparse) then the Eigenvalues come out sorted (and real), and the eigenvectors are predictable too. [Your data looked symmetric, though maybe I am wrong there?]

If you change your last list to L := Matrix((VectorCalculus[DotProduct])(Di, DD-W), datatype = float[8], shape = symmetric, storage = sparse) then the Eigenvalues come out sorted (and real), and the eigenvectors are predictable too. [Your data looked symmetric, though maybe I am wrong there?]

What is going on is that 'plotting' in Maple is a bit of a hack. What the maple command produces is a data-structure (that PLOT(...) that you saw). Then the interface, if it sees a Maple output that is a PLOT data-structure as a surface type, it will render that as a plot, otherwise it will just ``print'' the data-structure as is. Very hackish, very 80s, and still here. What Scott03 told you works, and is a good way to return multiple results. If you want to display rather than return them, then you can use an explicit call to 'print' around the plot, and that will display it. Be warned that 'print', plots, and the Standard GUI do not always co-exist seamlessly, you might have to experiment a little to find combinations that ``work'' for you.

What is going on is that 'plotting' in Maple is a bit of a hack. What the maple command produces is a data-structure (that PLOT(...) that you saw). Then the interface, if it sees a Maple output that is a PLOT data-structure as a surface type, it will render that as a plot, otherwise it will just ``print'' the data-structure as is. Very hackish, very 80s, and still here. What Scott03 told you works, and is a good way to return multiple results. If you want to display rather than return them, then you can use an explicit call to 'print' around the plot, and that will display it. Be warned that 'print', plots, and the Standard GUI do not always co-exist seamlessly, you might have to experiment a little to find combinations that ``work'' for you.

Globals do not scale. It works great if you have just a small problem to work on, but using globals dooms your work to remain small-scale.

Globals do not scale. It works great if you have just a small problem to work on, but using globals dooms your work to remain small-scale.

It looks like it is the amount of time that is yielding. I teach in an Engineering Faculty here, and more and more programs are going to 5 years. Now, it is dressed up fancily (with the 5th year giving you a Master's degree), but basically that is had to happen to ``cram'' everything in. Note that, at least at McMaster, in none of the Engineering programs has the math been skimped on. If anything, the students get even more theory because they are supposed to be able to learn ``technology'' on their own. [Whether they can is an entirely different question].

In Maple VR4, there was no Groebner, only grobner, Groebner came in to Maple VR5! So the commands ran really fast because they all returned unevaluated...

I heard that Dell struck a deal with Microsoft (because of strong customer demand!) to be allowed to sell new computers with XP on it instead of Vista, if customers ask.

I heard that Dell struck a deal with Microsoft (because of strong customer demand!) to be allowed to sell new computers with XP on it instead of Vista, if customers ask.

But even a correct implementation of RKF45 can give a completely bogus answer! RKF45 will return the answer to a "nearby" problem to the one asked. If the (generalized) condition number of the problem is large enough, then an essentially random answer will be returned. The problem with most implementations of RKF45 is that they do not report this condition number (which is easily computed from most implementations), so that you don't know if your answer is trustworthy or completely bogus. This is what engineering is supposed to be all about: knowing what tools to use when. And without the math, you don't know whether your problem is stable or not. If it is unstable and you use tools blindly, you get wrong answers, even from ``correct'' implementations. If you get audited, as a professional engineer, you would get blamed and not the tool, for such a failure, as you should have known better.