I see, thanks.
Ok, so the Source button toggles the editor's mode. So code could still be formatted by hand. Great. That means that Plain Text mode is still possible, and so still could be useful. This reply itself is done that way, by toggling to Source mode and then toggling the Input format to Plain Text.
Let's see how it comes out.
A problem with doing that is that hitting Preview will compress all the source to a single line in the editor (possibly marked up as an html paragraph). Further plaintext editing can then only be done by re-toggling as Source and splitting the lines and removing the
markup.
It's not clear whether the combination of Source & Plain Text can be Previewed and then Posted without intermediate clean-up of the text.
acer
I too had tried to get rid of the "Recent book pages", but hadn't succeeded.
acer
I suppose that removal of the ability to submit Plain Text posts would depend on the robustness of the wysiwyg editor.
Maybe toggling a post as Plain Text input could throw open the old editor as well as toggle the input form. If that can't be done, then, as you say, the Plain Text input form isn't of much use any more.
If the new editor works well, then we're golden without the ability to submit plain text posts. But if it has issues, then we're at your mercy.
So far, the most idiosyncratic behaviour I've seen in the new editor is related to adding and removing blank lines. It quite often adds 2-3 new lines, or removes too many. It may not be best to have <Enter> shift to a new paragraph.
Trying to join paragraphs by placing the cursor at the end of paragraph and deleting the intervening lines, or by placing the cursor at the start of a new paragraph and backspacing, produces intermittently weird results. Similarly, it can take three or four actions in order to split a paragraph by its usual single blank line.
Also, if I have a few blank lines, and I delete them, then my cursor becomes invisible. Even though that's remindful of the behaviour of the cursor on the last line in the Standard GUI on Linux, it's not so good.
acer
Floating "bubble" hints on the wysiwyg editor buttons would help to explain them. (In case it's just my browser, I'm using netscape 7.2, Linux.)
While I've got this editor open... why does hitting <Enter> always create a new paragraph (skips a line)?
Why doesn't the tag <pre>...</pre> work properly as before if I type in the mark-up code by hand? Can we still mark up the HTML source for a posting, by hand, and if so then how please?
I agree with Jacques -- SCRs submitted from here should be posts here, with discussion allowed. Otherwise they're not significantly different from emails to Tech Support. Ie, people don't always want to bother after having posted an issue here, and the SCRs can't be seen here, people will duplicate them, someone from Maplesoft would still have to scan this site for issues not submitted, etc, etc.
acer
Here's what happens when I use the new wysiwyg posting editor and toggle the "Input format" as "Plain Text (HTML not available).
acer
If the file is already opened by Maple, then fprintf will write to its end.
restart:
fd := fopen("mres.out", WRITE):
M := Matrix([[1.,i],[-i,1]]):
with(LinearAlgebra):
for i from 1 to 10 do
res := LinearAlgebra:-Eigenvalues(M);
fprintf(fd,"%a %a \n", seq(res[j],j=1..2) );
end do:
# flush when ready, to commit the write to the file
fflush(fd);
acer
If the file is already opened by Maple, then fprintf will write to its end.
restart:
fd := fopen("mres.out", WRITE):
M := Matrix([[1.,i],[-i,1]]):
with(LinearAlgebra):
for i from 1 to 10 do
res := LinearAlgebra:-Eigenvalues(M);
fprintf(fd,"%a %a \n", seq(res[j],j=1..2) );
end do:
# flush when ready, to commit the write to the file
fflush(fd);
acer
I see, thanks. So, that method may or may not work, and testing the definition (U.V1-Evals[1]*V1) is the way to find out afterwards (for each eigenvalue). It might work some or most of the time.
The first example I gave seems to be in the problematic space.
restart:
with(LinearAlgebra):
U := Matrix([[a^2+b^2-1,1,0],[1-a^2-b^2,1,0],[1,0,1]]):
Evals := simplify(Eigenvalues(U), {a^2 + b^2 = 1}):
U3:= U - Evals[3]*IdentityMatrix(3):
V3:= LinearSolve(U3[1..2,1..3],Vector(2)):
V3:= eval(V3,_t[3]=1); # or whatever the parameter is.
[0]
[ ]
V3 := [0]
[ ]
[1]
map(simplify,U.V3-Evals[3]*V3,{a^2+b^2=1}); # not OK
[0]
[ ]
[0]
[ ]
[1]
Using the side relations during pivot selection seems to work. I'd advise trying it that way.
Normalizer:=x -> simplify(simplify(x,{a^2+b^2=1})):
LinearSolve(U3,Vector(3));
[-_t0[3]]
[ ]
[ 0 ]
[ ]
[_t0[3] ]
V3:= eval(%,_t0[3]=1); # or whatever the parameter is.
[-1]
[ ]
V3 := [ 0]
[ ]
[ 1]
map(simplify,U.V3-Evals[3]*V3,{a^2+b^2=1}); # OK
[0]
[ ]
[0]
[ ]
[0]
acer
I see, thanks. So, that method may or may not work, and testing the definition (U.V1-Evals[1]*V1) is the way to find out afterwards (for each eigenvalue). It might work some or most of the time.
The first example I gave seems to be in the problematic space.
restart:
with(LinearAlgebra):
U := Matrix([[a^2+b^2-1,1,0],[1-a^2-b^2,1,0],[1,0,1]]):
Evals := simplify(Eigenvalues(U), {a^2 + b^2 = 1}):
U3:= U - Evals[3]*IdentityMatrix(3):
V3:= LinearSolve(U3[1..2,1..3],Vector(2)):
V3:= eval(V3,_t[3]=1); # or whatever the parameter is.
[0]
[ ]
V3 := [0]
[ ]
[1]
map(simplify,U.V3-Evals[3]*V3,{a^2+b^2=1}); # not OK
[0]
[ ]
[0]
[ ]
[1]
Using the side relations during pivot selection seems to work. I'd advise trying it that way.
Normalizer:=x -> simplify(simplify(x,{a^2+b^2=1})):
LinearSolve(U3,Vector(3));
[-_t0[3]]
[ ]
[ 0 ]
[ ]
[_t0[3] ]
V3:= eval(%,_t0[3]=1); # or whatever the parameter is.
[-1]
[ ]
V3 := [ 0]
[ ]
[ 1]
map(simplify,U.V3-Evals[3]*V3,{a^2+b^2=1}); # OK
[0]
[ ]
[0]
[ ]
[0]
acer
There's no provision in this for avoiding using hidden zeros as pivots, during the linear system solving. I still thnik that, in general, that's a serious issue for this class of problem.
Did you mean to have,
V1:= LinearSolve(U1[1..3,1..4],Vector(3));
but perhaps got caught by the < issue?
This seems like just a bit more "by-hand" work, than calling NullSpace.
Also, how can you know that it's "OK" to drop the last row of U1 (as opposed to the 2nd, etc)? What if the 1st and 2nd rows are linear combinations of each other and the 4th is independent of the top 3? Why not just do,
LinearSolve(U1,Vector(4));
which is in effect what NullSpace does?
acer
There's no provision in this for avoiding using hidden zeros as pivots, during the linear system solving. I still thnik that, in general, that's a serious issue for this class of problem.
Did you mean to have,
V1:= LinearSolve(U1[1..3,1..4],Vector(3));
but perhaps got caught by the < issue?
This seems like just a bit more "by-hand" work, than calling NullSpace.
Also, how can you know that it's "OK" to drop the last row of U1 (as opposed to the 2nd, etc)? What if the 1st and 2nd rows are linear combinations of each other and the 4th is independent of the top 3? Why not just do,
LinearSolve(U1,Vector(4));
which is in effect what NullSpace does?
acer
Interesting. Using a simplifier (with side relations) for Normalizer on your Matrix U resulted in a spurious all-zero Matrix of eigenvectors when using the Eigenvectors command. So maybe Eigenvectors is not clever enough about how it goes to work in such a situation.
But I still think that you might be rightfully concerned with Eigenvectors() using hidden zeros as pivots during the kernel computation.
Having computed the eigenvalues as evU, you might then compute the eigenvectors associated with the i'th eigenvalues the good old fashioned way. That is to say, using NullSpace().
You may also find that the Normalizer setting gets the eigenvalues in their simplified form too.
with(LinearAlgebra):
U := Matrix(1/8*[[0, 0, -8*I, 0], [0, 8*I, 0, 8*I], [I*b, I*(a-1), (2*I)*(a-1+b)+8*I, (2*I)*(a-1-b)], [I*(a-1), -I*b, (2*I)*(a-1-b), -(2*I)*(a-1+b)]]):
use_assump := x -> simplify(simplify(x, {a^2+b^2 = 1})):
Normalizer := use_assump:
evU := Eigenvalues(U);
for i from 1 to 4 do
NullSpace(U-evU[i]*IdentityMatrix(4))
end do;
Normalizer := normal:
acer
Interesting. Using a simplifier (with side relations) for Normalizer on your Matrix U resulted in a spurious all-zero Matrix of eigenvectors when using the Eigenvectors command. So maybe Eigenvectors is not clever enough about how it goes to work in such a situation.
But I still think that you might be rightfully concerned with Eigenvectors() using hidden zeros as pivots during the kernel computation.
Having computed the eigenvalues as evU, you might then compute the eigenvectors associated with the i'th eigenvalues the good old fashioned way. That is to say, using NullSpace().
You may also find that the Normalizer setting gets the eigenvalues in their simplified form too.
with(LinearAlgebra):
U := Matrix(1/8*[[0, 0, -8*I, 0], [0, 8*I, 0, 8*I], [I*b, I*(a-1), (2*I)*(a-1+b)+8*I, (2*I)*(a-1-b)], [I*(a-1), -I*b, (2*I)*(a-1-b), -(2*I)*(a-1+b)]]):
use_assump := x -> simplify(simplify(x, {a^2+b^2 = 1})):
Normalizer := use_assump:
evU := Eigenvalues(U);
for i from 1 to 4 do
NullSpace(U-evU[i]*IdentityMatrix(4))
end do;
Normalizer := normal:
acer
Since nobody has yet stated it in just so many words, I will add that `=` does not by itself bring about assignment in Maple.
So, it is not true that, "The symbol = means assignment." Without qualification an assertion like that is completely general. But since it isn't true in Maple in particular, then it also isn't always true.
Assignments in Maple are done using a `:=` statement, or using the `assign` operator.
As for what `=` can in fact mean in Maple, please see other replies to this subthread whose points I won't repeat here.
acer
