@markweitzman Did you see the bit where I said that I recommend evaluating the Matrix entries up front instead of forcing a valuie for Normalizer? I really meant it.

This is not a bug in LinearAlgebra. It is a bug in the Matrix palette (or typesetting, or some combination of that and the palettes). Working around the palette bug by introducing blind over-evaluation into Library routines would be irresponsibly bad. It should be fixed in the palette, and worked around by the user by evaluating (once) upfront.

I see no such problem in at least Maple 12.02, 17.02, 2015.0 and 2015.2 .

Download lae.mw

Could it be that you have some other package loaded, or something in your initialization file that interferes?

Right before you call Eigenvectors, what do each of the commands eval(Normalizer) and eval(Testzero) produce? One way to get that all-zero result for the eigenvectors Matrix is to have Normalizer set to something other than identically normal and weaker than radnormal or simplify. It's important for the nullspace computation that the radicals are dealt with, including adequate zero-recognition while choosing pivots.

acer

Step 5 involves obtaining roots of a polynomial of degree n, and I don't see how the restrictions on the unknown elements (from step 1) are enough to provide an explicit symbolic solution to that.

What would you eventually do with these n functions? If at some point (no matter how far down the road) you are going to want to evaluate these functions at numeric values of the unknowns then why would not a "black box" apporach work? For that I mean that your Matrix in step 1 has n^2-n unknowns. You could construct a procedure which accepted values for the unknowns and returned the final n eigenvalues. You could then call this procedure (on the fly) and so simulate the n functions at any numeric value set. Would that suffice? You could also try calling that procedure with symbolic values and -- if there were some strong pattern of commonality to the symbols used for the n^2-n parameters -- possibly arrive at special cases of somewhat nice explicit n formula. Do this sound like it might do?

acer

I'd like to add one note to Carl's excellent post.

The ideas demonstrated by Carl are central to the reasons why Maple computes the characteristic polynomial of a Matrix with floating-point values by first computing the eigenvalues and then computing the polynomial as an unexpanded product of factors using those values. In other words, for a Matrix of floating-point values the CharacteristicPolynomial command computes the charcteristic polynomial by first computing the eigenvalues, and it does not compute the polynomial by taking the determinant of the characteristic Matrix.

Now, fsolve can immediately pick off the roots of said unexpanded characteristic polynomial. And that is why the green symbols in the plot below, taken from LA:-CharacteristicPolynomial(Af, x) are also on target. Of course there is not much point in using this to obtain the roots, as using the Eigenvalues command is more direct and skips two unnecessary steps (of forming an unexpanded polynomial from roots, and then picking the roots off). It's simpler and direct to simply use Eigenvalues command, as Carl demonstrates.

So I add this note just to illustrate what LA:-CharacteristicPolynomial(Af, x) provides.

Download EV.mw

acer

@iman 

determinan_alt.mw

What do you see if you set Digits:=80 at the start? 

acer

@Markiyan Hirnyk That's why I mentioned the material of mathematician Clayton Shonkwiler.

@Markiyan Hirnyk 

I recently saw links on community.wolfram.com to the following collections of animations: here, here and here. The last of those contains work by Clayton Shonkwiler, who has posted source to some of his work on that Wolfram community site.

@perr7 I am looking at trying to improve your example. It is slow because I am very busy right now with other things, sorry.

@Axel Vogt Thank's Axel.

I should be more polite and tell the questioner this:

.tar.gz is a Unix/Linux/OSX thing. It means that the file or files were bundled together with the `tar` untility and then compressed with the `gzip` utility (well, `tar` can do both nowadays).

It just means that the files were bundled and compressed, producing something similar to a .zip archive.

It's not a Maple thing. It's just an general operating system question. You just need a utility for Windows that understands .tar.gz compressed archives. There are several such things on the internet, most of which can handle .tar.gz as well as zip archives, etc. Axel has named one. Another is Winzip. Some are free.

@Carl Love I suspect what he wants (in 2D Math parlance), is more like (1)=~0 where (1) is probably an equation label reference.

Of course he could also assign it to some name, first...

@Markiyan Hirnyk How does your example "p:=(x-1)*(x-2), q:=(x-2)*(x-3), and r:= (x-1)*(x-3)" relate to what was given by you originally?

The text in your post is garbled. (Did you try to paste it in from 2D Input or something?)

Also, what do you mean by xe, x2, and y2?

Anyway, this works for me in Maple 2015,

plots:-densityplot(x*exp(1)-x^2-y^2,x=-2..2,y=-2..2,
                   colorscheme=["Blue","Green","Orange"],style=surface);

acer

@perr7 Thanks. Knowing the version number helps. Not sure of your OS, but in any case even without Classic availability we can likely get a command line script that exports the gif or frames more efficiently. The speed of the frame (all the plots) can likely be made better still.

The sign vs signum thing I mentioned gets an expected improvement. Thete can be several such bottlenecks or things to tweak in order to attain closer to optimal performance. But as mentioned, it is the holiday season for some, so you may have to wait for me to chip in fully.

@perr7 I'll try to find time to speed it up and post.

Which version of Maple are you using? Depending on the version it may be the using operator form for the plot3d calls' first arguments, and utilizing a wrapping call to evalhf with that, might speed up the generation of the surface plots.

Do you really feel that grid=[150,150] gives that much better look? That's about ten times as expensive to generate and to store.

In several places you used the uneval-quoted 'sign(-x)' and you might try the unquoted signum(-x) instead.

The data structures produced by `spacecurve` and `transform` are less efficient listlist rather than float[8] rtable. It is just possible that intermediary conversion (correction) in this regard might alleviate some of the strain on the GUI.

If we can speed up the generation enough then you might want to save without output, after restart, so as to get a very small source file that reopens quickly.

More later -- but it's the holiday season for me...