@Carl Love I'm not seeing that in 2017.3. Executing the first time doesn't give any indication, but the second time I select and "!" (or ctrl-E) the highlighted line moves to the line with the error but no underline appears. Perhaps I'm missing a reqruired setting. I can live with the highlighted line.

CodeEdit.mw

@Carl Love Thanks - I missed the tooltip, but as you say, syntax errors aren't too hard to find. Not sure why the same mechanism wouldn't work in a regular code edit region.

@ebrahimina LinearSolve will be faster and more accurate than finding the inverse then multiplying. Since you have a generalized eigenvalue problem, you could just use the Eigenvectors command directly Eigenvectors(FF1,FF2). (But for non-square matrices not sure what inverse you want,...)

Finding the inverse could be part of the problem if it is ill-conditioned. So if you can use Eigenvectors, you may not need Digits=30. You really, really need to decide what part of your calculation is requiring this accuracy and improve/avoid it.

@awass I agree it is a bug.

I take @tomleslie's point that floating point arithmetic may make things that are linearly dependent seem linearly independent and too many vectors are returned, and his and @vv's solutions to get rid of extra one(s) are certainly useful for the case where n-component vectors give <=n solutions.

But for 3-component vectors, the routine should never attempt to give more than 3 vectors, so I consider that a bug, and not just possibly a bug.

@Mac Dude I suppose if I were looking for density of various substances, I'd look in a table listing properties of various substances, not just elements. Maple has the ThermophysicalData package, which seems more appropriate (and does have densities), but the database only has fluids. Perhaps there are plans for expansion of that for other materials....

This gives -1 in Maple 2015 but doesn't work in 2017. Don't have 2018...

@Bland3 

shape=hermitian can be used if the matrices are going to be complex. This forces real eigenvalues for a floating point calculation.

You are worried that two zero eigenvalues not being exactly the same, and suggest that the one that is not exactly zero has the wrong symmetry for its eigenvector. But from a numerical point of view at Digits=15, these are both zero. I think the eigenvector algorithm is robust, and the symmetry issue is not related to the numerical roundoff in the eigenvalue, if that is what you are suggesting. You can take the Matrix with integer (or exact rational) entries and use NullSpace(M) to see an exact pair of eigenvectors for the zero eigenvalues. Your <0,-1,0,-1> and <1,0,-1,0> are an exact pair.

Probably you know this already, but the non-degenerate eigenvalues have unique eigenvectors up to a scalar multiplication, so the eigenvectors for E and -E will automatically have the required symmetry if E and -E are non-degenerate. Then you can just sort the eigenvectors to have them next to each other (and scale them) if that is what you want.

Once you have degeneracy, then mathematically there is no preferred form for the eigenvectors. So what you want to do is find a linear combination of the ones you get in some prescribed form. I don't see a simple way to do this. On the other hand, degeneracy usually arises from some sort of symmetry, so knowing more about the matrix structure might help you, e.g., if you can partition them into related blocks.

I'm still confused over whether you think the zero eigenvectors can alsways have the <u,v> <v,u> symmetry as I think you originally proposed, or now you think <u,u>, <v,v>?

@dharr - oops, I was careless here. The eigenvectors for zero don't have the [x,-x] symmetry here, entries 1,2,4 are negative of 5,6,8 but entry 3 is not negative of entry 7.

Leaving the entries as integers, so there are no numerical issues, NullSpace(M) gives

[0,0,1,0,0,0,1,0] and [49/5, -56/5, 21/5, -1, -49/5, 56/5, 0,1]

@Bland3 for the plot issue, you can use: seq(plotter[i],i=1..4*L)

To avoid us cutting and pasting, please upload the worksheet using the fat green up-arrow in in the Mapleprimes editor.

@jthress1 From a physical point of view, you have 4 equal eigenvalues and 4 eigenvectors, and for most purposes (say various expansion theorems) you could arbitrarily associate them in 1:1 fashion, and get the same answer. But you almost certainly can't just use one. The eigenvalues also aren't unique, so you could take linear combinations and find another (linearly independent) set of 4.

So I suspect you could take the 6 eigenvectors in a matrix and continue to calculate other quantities, but that depends on the physical context I guess.

@Carl Love The first two columns of acer's evecsA are zero, so even without chasing down special parameter values it looks like the matrix is defective. But the missing eigenvalues are associated with the simple eigenvalues?? JordanForm(A) is diagonal, so something is strange here.

Edit: I see now that @acer's evecsA is different in his two worksheets. So the second version with two zero columns has a problem, perhaps an artifact of the Normalizer used.

@Adam Ledger Do you have a file "F:/test.txt" already existing on your system?

Try FileTools[Status]("F:/test.txt");

If you get file or directory doens't exist, then it is a problem with finding the file. If it can find it, it will give you the permissions for that file.

displayprecision=4 on Maple 2015 gives 4 decimal places, and in Maple 2017.3 gives 4 significant places as you say. But the 2017.3 help page for interface (and the options menu setting) say that it should give 4 decimal places. So it seems as though the behaviour in 2017 is an anomaly compared with earlier and later versions and not as intended.

I don't have a fix, other than precede every output you want formatted by evalf[4](...).

@shimaa sadk 

I didn't attempt to understand the algorithm, so really don't understand what you want. You can leave the range 0..infinity and it will be slower. If you can make a narrower range estimate it might go faster.