Eigen-stuff in Sage
187 views
Skip to first unread message
Rob Beezer
Jun 21, 2011, 4:59:18 PM6/21/11
to sage-devel
I think I have one more big push left in me as I try to tidy up linear
algebra in Sage to make it even more useful for students studying the
subject for the first time. Eigen-stuff is on my radar. Some
behaviors that I find problematic, most vexing first.
1. Eigenspaces
sage: A = matrix(QQ, [[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]])
sage: A.eigenspaces_right()
[
(a0, Vector space of degree 4 and dimension 2 over Number Field in a0
with defining polynomial x^2 + 1
User basis matrix:
[ 1 -a0 0 0]
[ 0 0 1 -a0])
]
It is real impressive that we can do computations in QQbar and get
Galois conjugates and all, but there is no possible way to explain
this to a student who is fresh out of calculus. I would like to
retain getting eigenspaces as "true" vector spaces, since I think this
is a real strength of Sage. But I'd rather have the textual versions
of the QQbar elements, like the output for eigenvectors:
sage: A.eigenvectors_right()
[(-1*I, [(1, 1*I, 0, 0), (0, 0, 1, 1*I)], 2), (1*I, [(1, -1*I, 0, 0),
(0, 0, 1, -1*I)], 2)]
Question: is it important to only get a limited number of non-
isomorphic eigenspaces back? Most of that information seems available
to me from the factored characteristic polynomial, easily obtainable
with the fcp() method.
sage: A.fcp()
(x^2 + 1)^2
Thoughts or reactions to returning an eigenspace per eigenvalue, with
QQbar elements as entries of basis vectors, etc?
2. Eigenspaces for matrices over RDF/CDF
These eigenspaces come back as dimension 1, always. The method was
adjusted to match the format of returned values for exact matrices
(and I was a party to that). With more experience with the floating
point matrix class, I've come to the conclusion this is a really bad
idea, bordering on criminal. So, I'd propose raising a NotImplemented
exception for an eigenspace request, since all the information
presently returned for eigenspaces can be found with the existing
eigenmatrix commands. Reactions?
3. Algebraically Closed Fields
We return eigenvalues outside the base field, by default, only for the
rationals. Not sure I'm suggesting anything here, it just seems odd
that we do this in the one case, just because we can?
4. Sorting Eigenvalues
Easy and natural to sort eigenvalues over RDF and QQ. Messier in
other cases. Docstrings say things like:
The eigenspaces are returned sorted by the corresponding
characteristic polynomials, where polynomials are sorted in
dictionary order starting with constant terms.
But I do not quite see that implemented unless it comes from deep in
the factorization of the characteristic polynomial somehow. In any
event, trying to get a consistent approach to the sort order looks
like a big job with the existing code. Maybe somebody has some
thoughts about this.
Thanks in advance for thoughts, affirmative or dissident.
Rob
algebra in Sage to make it even more useful for students studying the
subject for the first time. Eigen-stuff is on my radar. Some
behaviors that I find problematic, most vexing first.
1. Eigenspaces
sage: A = matrix(QQ, [[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]])
sage: A.eigenspaces_right()
[
(a0, Vector space of degree 4 and dimension 2 over Number Field in a0
with defining polynomial x^2 + 1
User basis matrix:
[ 1 -a0 0 0]
[ 0 0 1 -a0])
]
It is real impressive that we can do computations in QQbar and get
Galois conjugates and all, but there is no possible way to explain
this to a student who is fresh out of calculus. I would like to
retain getting eigenspaces as "true" vector spaces, since I think this
is a real strength of Sage. But I'd rather have the textual versions
of the QQbar elements, like the output for eigenvectors:
sage: A.eigenvectors_right()
[(-1*I, [(1, 1*I, 0, 0), (0, 0, 1, 1*I)], 2), (1*I, [(1, -1*I, 0, 0),
(0, 0, 1, -1*I)], 2)]
Question: is it important to only get a limited number of non-
isomorphic eigenspaces back? Most of that information seems available
to me from the factored characteristic polynomial, easily obtainable
with the fcp() method.
sage: A.fcp()
(x^2 + 1)^2
Thoughts or reactions to returning an eigenspace per eigenvalue, with
QQbar elements as entries of basis vectors, etc?
2. Eigenspaces for matrices over RDF/CDF
These eigenspaces come back as dimension 1, always. The method was
adjusted to match the format of returned values for exact matrices
(and I was a party to that). With more experience with the floating
point matrix class, I've come to the conclusion this is a really bad
idea, bordering on criminal. So, I'd propose raising a NotImplemented
exception for an eigenspace request, since all the information
presently returned for eigenspaces can be found with the existing
eigenmatrix commands. Reactions?
3. Algebraically Closed Fields
We return eigenvalues outside the base field, by default, only for the
rationals. Not sure I'm suggesting anything here, it just seems odd
that we do this in the one case, just because we can?
4. Sorting Eigenvalues
Easy and natural to sort eigenvalues over RDF and QQ. Messier in
other cases. Docstrings say things like:
The eigenspaces are returned sorted by the corresponding
characteristic polynomials, where polynomials are sorted in
dictionary order starting with constant terms.
But I do not quite see that implemented unless it comes from deep in
the factorization of the characteristic polynomial somehow. In any
event, trying to get a consistent approach to the sort order looks
like a big job with the existing code. Maybe somebody has some
thoughts about this.
Thanks in advance for thoughts, affirmative or dissident.
Rob
mmarco
Jun 22, 2011, 3:07:10 AM6/22/11
to sage-devel
I faced that kind of decissions when i implemented the eigen-stuff
for endomorphisms (see ticket 8974).
My opinion was to stick to the base field, and only look for
extensions when directly requested. David Loefler argued that, for
consistency reasons, it would be preferable to continue with the same
philosophy. The compromise solution was to introduce the option
extend=False to say sage to work only on the base field.
I don't remember now if it solved all the issues you present here, but
i do remember that it helped to solve some cases over finite fields
where the option extend=True (default) fails.
for endomorphisms (see ticket 8974).
My opinion was to stick to the base field, and only look for
extensions when directly requested. David Loefler argued that, for
consistency reasons, it would be preferable to continue with the same
philosophy. The compromise solution was to introduce the option
extend=False to say sage to work only on the base field.
I don't remember now if it solved all the issues you present here, but
i do remember that it helped to solve some cases over finite fields
where the option extend=True (default) fails.
Dima Pasechnik
Jun 22, 2011, 10:37:11 AM6/22/11
to sage-devel
On Jun 21, 9:59 pm, Rob Beezer <goo...@beezer.cotse.net> wrote:
> I think I have one more big push left in me as I try to tidy up linear
> algebra in Sage to make it even more useful for students studying the
> subject for the first time. Eigen-stuff is on my radar. Some
> behaviors that I find problematic, most vexing first.
>
> 1. Eigenspaces
>
> sage: A = matrix(QQ, [[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]])
> sage: A.eigenspaces_right()
> [
> (a0, Vector space of degree 4 and dimension 2 over Number Field in a0
> with defining polynomial x^2 + 1
> User basis matrix:
> [ 1 -a0 0 0]
> [ 0 0 1 -a0])
> ]
>
> It is real impressive that we can do computations in QQbar and get
> Galois conjugates and all, but there is no possible way to explain
> this to a student who is fresh out of calculus.
sage: A = matrix(QQbar, [[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]])
sage: A.eigenspaces_right()
[
(1*I, Vector space of degree 4 and dimension 2 over Algebraic Field
User basis matrix:
[ 1 -1*I 0 0]
[ 0 0 1 -1*I]),
(-1*I, Vector space of degree 4 and dimension 2 over Algebraic Field
User basis matrix:
[ 1 1*I 0 0]
[ 0 0 1 1*I])
]
isn't it what you need?
> I would like to
> retain getting eigenspaces as "true" vector spaces, since I think this
> is a real strength of Sage. But I'd rather have the textual versions
> of the QQbar elements, like the output for eigenvectors:
>
> sage: A.eigenvectors_right()
> [(-1*I, [(1, 1*I, 0, 0), (0, 0, 1, 1*I)], 2), (1*I, [(1, -1*I, 0, 0),
> (0, 0, 1, -1*I)], 2)]
>
> Question: is it important to only get a limited number of non-
> isomorphic eigenspaces back? Most of that information seems available
> to me from the factored characteristic polynomial, easily obtainable
> with the fcp() method.
>
> sage: A.fcp()
> (x^2 + 1)^2
>
> Thoughts or reactions to returning an eigenspace per eigenvalue, with
> QQbar elements as entries of basis vectors, etc?
>
> 2. Eigenspaces for matrices over RDF/CDF
>
> These eigenspaces come back as dimension 1, always. The method was
> adjusted to match the format of returned values for exact matrices
> (and I was a party to that). With more experience with the floating
> point matrix class, I've come to the conclusion this is a really bad
> idea, bordering on criminal.
> So, I'd propose raising a NotImplemented
> exception for an eigenspace request, since all the information
> presently returned for eigenspaces can be found with the existing
> eigenmatrix commands. Reactions?
>
> 3. Algebraically Closed Fields
>
> We return eigenvalues outside the base field, by default, only for the
> rationals. Not sure I'm suggesting anything here, it just seems odd
> that we do this in the one case, just because we can?
>
> 4. Sorting Eigenvalues
>
> Easy and natural to sort eigenvalues over RDF and QQ. Messier in
> other cases. Docstrings say things like:
>
> The eigenspaces are returned sorted by the corresponding
> characteristic polynomials, where polynomials are sorted in
> dictionary order starting with constant terms.
>
> But I do not quite see that implemented unless it comes from deep in
> the factorization of the characteristic polynomial somehow. In any
> event, trying to get a consistent approach to the sort order looks
> like a big job with the existing code. Maybe somebody has some
> thoughts about this.
IMHO...
>
> Thanks in advance for thoughts, affirmative or dissident.
>
> Rob
John H Palmieri
Jun 22, 2011, 11:44:28 AM6/22/11
to sage-...@googlegroups.com
On Wednesday, June 22, 2011 7:37:11 AM UTC-7, Dima Pasechnik wrote:
On Jun 21, 9:59 pm, Rob Beezer <goo...@beezer.cotse.net> wrote:
> I think I have one more big push left in me as I try to tidy up linear
> algebra in Sage to make it even more useful for students studying the
> subject for the first time. Eigen-stuff is on my radar. Some
> behaviors that I find problematic, most vexing first.
>
> 1. Eigenspaces
>
> sage: A = matrix(QQ, [[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]])
> sage: A.eigenspaces_right()
> [
> (a0, Vector space of degree 4 and dimension 2 over Number Field in a0
> with defining polynomial x^2 + 1
> User basis matrix:
> [ 1 -a0 0 0]
> [ 0 0 1 -a0])
> ]
>
> It is real impressive that we can do computations in QQbar and get
> Galois conjugates and all, but there is no possible way to explain
> this to a student who is fresh out of calculus.
what about
sage: A = matrix(QQbar, [[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]])
sage: A.eigenspaces_right()
As Rob basically said in the last sentence that you quoted, you don't want to have to use QQbar when you're teaching a sophomore-level linear algebra class, populated by science and engineering majors: the students there don't have any idea what QQbar is; they don't even know what a field is. Students will want to be able to do
A = matrix([[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]]) # no field explicitly specified
and then compute eigenvalues, eigenspaces, etc.
--
John
Jason Grout
Jun 22, 2011, 12:31:54 PM6/22/11
to sage-...@googlegroups.com
Now let's compare a more nontrivial example. Mathematica does basically
what you suggest, and it looks like a *mess*. Part of this is because
the Mathematica output can be directly copied and pasted to be
mathematica input, but part of the mess also comes from it not
formatting the vectors as using Galois conjugates
m = ( {
{0, -1, 0, 4},
{1, 0, 0, 3},
{0, 2, 0, -1},
{5, -1, 1, 0}
} )
Eigensystem[m]
{{Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1],
Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2],
Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4],
Root[-7 + 13 #1 - 15 #1^2 + #1^4 &,
3]}, {{-(23/10) + 24/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1] -
1/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1]^2 -
3/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1]^3,
61/10 - 8/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1] -
3/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1]^2 +
1/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1]^3,
88/5 - 123/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1] +
1/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1]^2 +
8/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 1]^3,
1}, {-(23/10) + 24/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2] -
1/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2]^2 -
3/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2]^3,
61/10 - 8/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2] -
3/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2]^2 +
1/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2]^3,
88/5 - 123/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2] +
1/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2]^2 +
8/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 2]^3,
1}, {-(23/10) + 24/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4] -
1/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4]^2 -
3/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4]^3,
61/10 - 8/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4] -
3/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4]^2 +
1/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4]^3,
88/5 - 123/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4] +
1/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4]^2 +
8/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 4]^3,
1}, {-(23/10) + 24/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 3] -
1/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 3]^2 -
3/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 3]^3,
61/10 - 8/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 3] -
3/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 3]^2 +
1/10 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 3]^3,
88/5 - 123/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 3] +
1/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 3]^2 +
8/5 Root[-7 + 13 #1 - 15 #1^2 + #1^4 &, 3]^3, 1}}}
Now here is Sage's output:
sage: m=matrix([[0, -1, 0, 4], [1, 0, 0, 3], [0, 2, 0, -1], [5, -1, 1, 0]])
sage: m.eigenspaces_right()
[
(a0, Vector space of degree 4 and dimension 1 over Number Field in a0
with defining polynomial x^4 - 15*x^2 + 13*x - 7
User basis matrix:
[ 1 16/55*a0^3 + 12/55*a0^2 -
21/5*a0 + 76/55 19/55*a0^3 + 28/55*a0^2 - 24/5*a0 - 171/55 4/55*a0^3
+ 3/55*a0^2 - 4/5*a0 + 19/55])
]
To me, it is much easier to explain: okay, we have 4 roots to our
characteristic polynomial. Each root is an eigenvalue and each
eigenvalue has a one-dimensional eigenspace. Whatever your root is,
plug it into this formula and you'll get a corresponding eigenvector.
Personally, I find this is more elegant and it is clearer what is going
on. Of course, I haven't actually explained it to a student that way,
so I might change my mind after I try :). The output from the same
matrix over QQbar is also pretty reasonable, but it is not nearly as
clear what is going on mathematically:
sage: m.change_ring(QQbar).eigenspaces_right()
[
(3.436547504370473?, Vector space of degree 4 and dimension 1 over
Algebraic Field
User basis matrix:
[ 1.000000000000000? 1.331601478275790? 0.4280940999706945?
1.192037245661566?]),
(0.4270724496970427? + 0.540685587055116?*I, Vector space of degree 4
and dimension 1 over Algebraic Field
User basis matrix:
[ 1 -0.5221757474677046? -
2.130035329012798?*I -5.317495122489429? - 2.312582446540107?*I
-0.02377582444266547? - 0.3973374354894205?*I]),
(0.4270724496970427? - 0.540685587055116?*I, Vector space of degree 4
and dimension 1 over Algebraic Field
User basis matrix:
[ 1 -0.5221757474677046? +
2.130035329012798?*I -5.317495122489429? + 2.312582446540107?*I
-0.02377582444266547? + 0.3973374354894205?*I]),
(-4.290692403764558?, Vector space of degree 4 and dimension 1 over
Algebraic Field
User basis matrix:
[ 1.000000000000000? 0.4400227439323470? -0.4294674913554725?
-0.9626674149580528?])
]
How do you propose getting the Galois conjugate type of output if your
suggested change is made?
Thanks,
Jason
Rob Beezer
Jun 22, 2011, 4:14:15 PM6/22/11
to sage-devel
Thanks, Dima, John, mmarco and Jason, for the very helpful comments.
Dima - had not thought about using QQbar! That pretty much gives the
output I would like to have as the default, other than the reference
to the "Algebraic Field" in the output. John sees my dilemma
exactly. The less I have to say about field extensions, the better.
I have broached QQbar in my textbook, since it is also useful for
orthogonality computations over QQ, but I have not belabored the
details.
Jason - I'd forgotten what Mathematica does on a problem like this.
Ouch. We are certainly doing better already. But we have QQbar,
rather than all that Root[] nonsense.
I agree that the current output is extremely interesting and
informative, with common "formulas" for eigenvectors across the Galois
conjugates of set of roots of an irreducible factor of the
characteristic polynomial. But look at the terms I used in that last
phrase. I *have* tried to explain this a couple times in seminar
presentations at a couple of undergradaute institutions and it did not
go so smoothly. I'd see nothing wrong with preserving this behavior
as an option, I'm just queasy about having it as the default. The
output when you change the base ring to QQbar originally is even
easier to explain - it doesn't require an explanation (other than the
question marks in the QQbar representations).
So I guess I'm wondering if there is a real argument against moving
the default output from one requiring Galois theory to understand to
something (ie like the QQbar examples above) more familiar to a
beginning student, engineer or scientist.
Dima - Eigenspaces from matrices over RDF/CDF make claims about
dimensions of eigenspaces that are either false or misleading,
depending on your viewpoint. We apply other exact ideas to this class
of matrices, such as rank, that I think should also be dealt with.
But that is a post for another day. Better would be to have a routine
that groups "equal" eigenvalues according to a user-supplied tolerance
for the equality.
sage: A = identity_matrix(3).change_ring(RDF)
sage: A.eigenspaces_right()
[(1.0, Vector space of degree 3 and dimension 1 over Real Double Field
User basis matrix:
[1.0 0.0 0.0]), (1.0, Vector space of degree 3 and dimension 1 over
Real Double Field
User basis matrix:
[0.0 1.0 0.0]), (1.0, Vector space of degree 3 and dimension 1 over
Real Double Field
User basis matrix:
[0.0 0.0 1.0])]
sage: A.eigenmatrix_right()
(
[1.0 0 0] [1.0 0.0 0.0]
[ 0 1.0 0] [0.0 1.0 0.0]
[ 0 0 1.0], [0.0 0.0 1.0]
)
mmarco - thanks for the background. Right now we have extend=True for
eigenvalues of all matrices, but it only takes effect if the
eigenvalues are in QQbar, so the matrix base ring needs to be QQ, or a
number field, or ... I don't have a real opinion myself here - just
bringing it up as part of the discussion to see what others think.
Rob
Dima - had not thought about using QQbar! That pretty much gives the
output I would like to have as the default, other than the reference
to the "Algebraic Field" in the output. John sees my dilemma
exactly. The less I have to say about field extensions, the better.
I have broached QQbar in my textbook, since it is also useful for
orthogonality computations over QQ, but I have not belabored the
details.
Jason - I'd forgotten what Mathematica does on a problem like this.
Ouch. We are certainly doing better already. But we have QQbar,
rather than all that Root[] nonsense.
I agree that the current output is extremely interesting and
informative, with common "formulas" for eigenvectors across the Galois
conjugates of set of roots of an irreducible factor of the
characteristic polynomial. But look at the terms I used in that last
phrase. I *have* tried to explain this a couple times in seminar
presentations at a couple of undergradaute institutions and it did not
go so smoothly. I'd see nothing wrong with preserving this behavior
as an option, I'm just queasy about having it as the default. The
output when you change the base ring to QQbar originally is even
easier to explain - it doesn't require an explanation (other than the
question marks in the QQbar representations).
So I guess I'm wondering if there is a real argument against moving
the default output from one requiring Galois theory to understand to
something (ie like the QQbar examples above) more familiar to a
beginning student, engineer or scientist.
Dima - Eigenspaces from matrices over RDF/CDF make claims about
dimensions of eigenspaces that are either false or misleading,
depending on your viewpoint. We apply other exact ideas to this class
of matrices, such as rank, that I think should also be dealt with.
But that is a post for another day. Better would be to have a routine
that groups "equal" eigenvalues according to a user-supplied tolerance
for the equality.
sage: A = identity_matrix(3).change_ring(RDF)
sage: A.eigenspaces_right()
[(1.0, Vector space of degree 3 and dimension 1 over Real Double Field
User basis matrix:
[1.0 0.0 0.0]), (1.0, Vector space of degree 3 and dimension 1 over
Real Double Field
User basis matrix:
[0.0 1.0 0.0]), (1.0, Vector space of degree 3 and dimension 1 over
Real Double Field
User basis matrix:
[0.0 0.0 1.0])]
sage: A.eigenmatrix_right()
(
[1.0 0 0] [1.0 0.0 0.0]
[ 0 1.0 0] [0.0 1.0 0.0]
[ 0 0 1.0], [0.0 0.0 1.0]
)
mmarco - thanks for the background. Right now we have extend=True for
eigenvalues of all matrices, but it only takes effect if the
eigenvalues are in QQbar, so the matrix base ring needs to be QQ, or a
number field, or ... I don't have a real opinion myself here - just
bringing it up as part of the discussion to see what others think.
Rob
Dima Pasechnik
Jun 23, 2011, 7:37:07 AM6/23/11
to sage-devel
Or are we talking about some dark ages situation when complex numbers
were considered
a heresy? :–)
I don't thing Sage should suffer from bad decisions made by designers
of stupidifying curricula...
A way out is to make a dumbstudentLA.spkg (hopefully, optional :))
where one can make matrices do whatever is needed ––– even dance like
paperclips in MS Word...
> Students
> will want to be able to do
>
> A = matrix([[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]]) # no field
> explicitly specified
>
> and then compute eigenvalues, eigenspaces, etc.
From my limited experience in tutoring linear algebra to undergrads, I
only saw confusion when
eigenvalues were required to be in R.
I would never go for this in any class I teach myself; I would always
say that we allow any root of
det(A-xI) to occur, not only real one.
Dima
>
> --
> John
mmarco
Jun 23, 2011, 12:35:55 PM6/23/11
to sage-devel
> Over R? Over C?
> From my limited experience in tutoring linear algebra to undergrads, I
> only saw confusion when
> eigenvalues were required to be in R.
> I would never go for this in any class I teach myself; I would always
> say that we allow any root of
> det(A-xI) to occur, not only real one.
>
> Dima
>
is to consider only the eigenvalues that lie in that field. If you
talk about plain matrices, that's another stuff (the same matrix may
represent an endomorphism of different vector spaces). But considering
that in sage the matrices have a base ring, i don't consider the idea
of taking the eigenvalues in that same base ring to be stupid.
Dima Pasechnik
Jun 23, 2011, 12:48:26 PM6/23/11
to sage-devel
A = matrix([[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]]) # no field
explicitly specified
do you suggest that Sage should restrict itself to eigenvalues in Z,
explicitly specified
which is the base ring of A?
Do you suggest that Sage should check whether we create a proper
extension of a base ring when we adjoin
a particular eigenvalue to it?
Eigenvalues, without a specialization to a ring/field, are the roots
of characteristic polynomial, that's it.
One can introduce real, etc, eigenvalues, perhaps...
kcrisman
Jun 23, 2011, 1:43:08 PM6/23/11
to sage-devel
>
> > > Dima
>
> > If you are talking about vector spaces over a field, what makes sense
> > is to consider only the eigenvalues that lie in that field. If you
> > talk about plain matrices, that's another stuff (the same matrix may
> > represent an endomorphism of different vector spaces). But considering
> > that in sage the matrices have a base ring, i don't consider the idea
> > of taking the eigenvalues in that same base ring to be stupid.
>
> Given that we talk about
> A = matrix([[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]]) # no field
> explicitly specified
> do you suggest that Sage should restrict itself to eigenvalues in Z,
> which is the base ring of A?
I don't have a horse in this contest, but this matrix is nonetheless
> > > Dima
>
> > If you are talking about vector spaces over a field, what makes sense
> > is to consider only the eigenvalues that lie in that field. If you
> > talk about plain matrices, that's another stuff (the same matrix may
> > represent an endomorphism of different vector spaces). But considering
> > that in sage the matrices have a base ring, i don't consider the idea
> > of taking the eigenvalues in that same base ring to be stupid.
>
> Given that we talk about
> A = matrix([[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]]) # no field
> explicitly specified
> do you suggest that Sage should restrict itself to eigenvalues in Z,
> which is the base ring of A?
over ZZ, as witness the annoyance before we had the .rref() function:
sage: A = matrix([[0,-2,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]])
sage: A.echelon_form()
[1 0 0 0]
[0 2 0 0]
[0 0 1 0]
[0 0 0 1]
sage: A.rref()
[1 0 0 0]
[0 1 0 0]
[0 0 1 0]
[0 0 0 1]
which presumably should carry some weight. Though interestingly,
sage: A.eigenvalues()
[-1*I, 1*I, -1.414213562373095?*I, 1.414213562373095?*I]
but
sage: A.eigenspaces()
[
(a0, Vector space of degree 4 and dimension 1 over Number Field in a0
with defining polynomial x^2 + 1
User basis matrix:
[ 0 0 1 a0]),
User basis matrix:
(a1, Vector space of degree 4 and dimension 1 over Number Field in a1
with defining polynomial x^2 + 2
User basis matrix:
[ 1 a1 0 0])
]
which seems a bit inconsistent, presumably as Rob's original post was
intended to address. Probably this is one of those things that has
no optimal answer for all needs.
- kcrisman
mmarco
Jun 23, 2011, 2:35:21 PM6/23/11
to sage-devel
> Given that we talk about
> A = matrix([[0,-1,0,0],[1,0,0,0],[0,0,0,-1],[0,0,1,0]]) # no field
> explicitly specified
> do you suggest that Sage should restrict itself to eigenvalues in Z,
> which is the base ring of A?
> Do you suggest that Sage should check whether we create a proper
> extension of a base ring when we adjoin
> a particular eigenvalue to it?
>
may be more complicated than just a "take all the complex roots and
that's the only possible choice; period".
In your example, i don't see any reason why we should look for the
roots over the complexes and not over the algebraic closure of a
finite field, for example.
> Eigenvalues, without a specialization to a ring/field, are the roots
> of characteristic polynomial, that's it.
image under a certain endomorpshism is a multiple of them. And
eigenvalues are, by definition, the scalars that multiply the
eigenvectors. So no, it is not true that "eigenvalues are the roots of
a charcteristic polynomial and thats it". Actually, the concept of
eigenvalue does not make sense without specializing to a base ring. We
may discuss what should be the default specialization when there is
none given, but that would be just the chosen convention, not "the
only possible right answer".
Rob Beezer
Jun 23, 2011, 3:49:32 PM6/23/11
to sage-devel
On Jun 23, 4:37 am, Dima Pasechnik <dimp...@gmail.com> wrote:
> Don't they at least know about complex numbers?!
> Or are we talking about some dark ages situation when complex numbers
> were considered
> a heresy? :–)
> I don't thing Sage should suffer from bad decisions made by designers
> of stupidifying curricula...
Hi Dima,
> Don't they at least know about complex numbers?!
> Or are we talking about some dark ages situation when complex numbers
> were considered
> a heresy? :–)
> I don't thing Sage should suffer from bad decisions made by designers
> of stupidifying curricula...
No, I'm not talking about banning the complex numbers, or ignoring
them, or restricting eigenvalues to the reals. Perhaps the opposite
in some sense - I want to see complex numbers, not some notion of
Galois conjugates over QQ. And when it comes to whether or not to
leave the base field, I do not really have a dog in that race -
probably just more interested in a consistent approach, which perhaps
is a pipe dream.
Here is the root problem in my view - the output/format of eigenspaces
when characteristic polynomials have non-trivial irreducible factors
over QQ. This is the second random matrix over ZZ that I got back
(the first had a linear factor):
sage: B = matrix(ZZ, [[-87, -1, 1], [17, 2, -6], [-1, -2, 7]])
sage: B.eigenspaces_right()
[
(a0, Vector space of degree 3 and dimension 1 over Number Field in a0
with defining polynomial x^3 + 78*x^2 - 763*x + 93
User basis matrix:
[ 1 1/9*a0^2 + 74/9*a0 - 371/3 1/9*a0^2 +
83/9*a0 - 110/3])
]
To my eye, that is incomprehensible (or worse, extremely misleading)
to a second-year undergraduate taking their first post-calculus
algebra course. What is a0? Why just one eigenspace (when in truth
there are 3)? Where are the 3 eigenvalues I expect? I want to see
eigenvalues and eigenvectors that a student, engineer or scientist
will recognize, and they would likely be complex numbers in a larger
example.
This is more like what I would like to see from Sage in this setting,
as KDC has shown:
sage: B.change_ring(QQbar).eigenspaces_right()
[
(8.67897278866459?, Vector space of degree 3 and dimension 1 over
Algebraic Field
User basis matrix:
[ 1.000000000000000? -43.93682721916003? 51.74214556950456?]),
User basis matrix:
(0.12344763849958892?, Vector space of degree 3 and dimension 1 over
Algebraic Field
User basis matrix:
[ 1.000000000000000? -122.6499594923977? -35.52651185389811?]),
User basis matrix:
(-86.80242042716417?, Vector space of degree 3 and dimension 1 over
Algebraic Field
User basis matrix:
[ 1.000000000000000? -0.1909910662200515? 0.006588506615773059?])
User basis matrix:
]
since, for example:
sage: B.change_ring(RDF).eigenmatrix_right()
(
[-86.8024204272 0 0]
[ 0 8.67897278866 0]
[ 0 0 0.1234476385],
[ -0.982224919531 -0.014730281408 -0.00783112834928]
[ 0.187596184649 0.647201829113 0.960487574819]
[ -0.0064713953805 -0.762176364893 0.27821267413]
)
As Jason has noted, the first example has output that is very
interesting "mathematically." I agree entirely. And I'd like to
preserve that view. So to make the discussion more concrete, a
precise
Proposal: For matrices over QQ (or implicitly ZZ) with eigenvalues
outside QQ, make the default output like the second example above,
while retaining the current output as optional behavior via a keyword.
Jason Grout
Jun 23, 2011, 3:55:15 PM6/23/11
to sage-...@googlegroups.com
On 6/23/11 2:49 PM, Rob Beezer wrote:
> Proposal: For matrices over QQ (or implicitly ZZ) with eigenvalues
> outside QQ, make the default output like the second example above,
> while retaining the current output as optional behavior via a keyword.
> Proposal: For matrices over QQ (or implicitly ZZ) with eigenvalues
> outside QQ, make the default output like the second example above,
> while retaining the current output as optional behavior via a keyword.
I'd be okay with that. So +epsilon. Or maybe +2*epsilon.
Jason
Gonzalo Tornaria
Jun 24, 2011, 11:06:23 AM6/24/11
to sage-...@googlegroups.com
On Thu, Jun 23, 2011 at 4:49 PM, Rob Beezer <goo...@beezer.cotse.net> wrote:
> Proposal: For matrices over QQ (or implicitly ZZ) with eigenvalues
> outside QQ, make the default output like the second example above,
> while retaining the current output as optional behavior via a keyword.
> Proposal: For matrices over QQ (or implicitly ZZ) with eigenvalues
> outside QQ, make the default output like the second example above,
> while retaining the current output as optional behavior via a keyword.
What's wrong with:
sage: B = matrix(ZZ, [[-87, -1, 1], [17, 2, -6], [-1, -2, 7]])
sage: B.eigenvectors_right()
[(-86.80242042716417?, [(1, -0.190991066220052?, 0.006588506615773?)],
1), (0.12344763849958892?, [(1, -122.6499594923977?,
-35.52651185389811?)], 1), (8.67897278866459?, [(1,
-43.93682721916003?, 51.74214556950456?)], 1)]
?
And what if the output of "B.eigenspaces_right()" is a bit confusing?
I'd argue that's actually a feature, because it will make the student
*think* about it, get a glimpse of some interesting mathematics, and
maybe open a door to a new world.
We can just tell students to use the eigenvectors_* methods, and
challenge them to figure out how to read the output of the
eigenspaces_* methods.
Best,
Gonzalo
Rob Beezer
Jun 24, 2011, 2:48:34 PM6/24/11
to sage-devel
Hi Gonzalo,
Thanks for your comments.
On Jun 24, 8:06 am, Gonzalo Tornaria <torna...@math.utexas.edu> wrote:
> What's wrong with:
Nothing - except there are no vector spaces in sight. I'd like to
retain the exposure to vector spaces (eigenspaces) without going as
far as Galois theory. They are a nice lead-in to invariant subspaces,
which would be a central topic for a second course.
> And what if the output of "B.eigenspaces_right()" is a bit confusing?
> I'd argue that's actually a feature, because it will make the student
> *think* about it, get a glimpse of some interesting mathematics, and
> maybe open a door to a new world.
I agree entirely with the sentiment. The students I teach have had a
minimum of two semesters of calculus, and afterwards are expected to
be ready for real analysis and abstract algebra. Many do not major in
mathematics, but are from physics, computer science and economics. My
course is different from many, in that we do not have an engineering
college, so we don't serve that audience.
I'll play the experience card - I've taught this course about 30
times. My experience tells me that if the only way to get an
eigenspace of matrix over QQ is to take a detour into roots of
irreducible polynomials, then I will just skip it entirely. It just
goes too far down a road that I don't find beneficial for the vast
majority of the students at that point - they are already struggling
with ideas like matrix representations of linear transformations.
With the Galois conjugate version optionally available, it will still
be there via a keyword to challenge students (or inform our own
research).
I am just now about to implement optionally promoting a QQ matrix to a
QQbar matrix when the eigenvalues lie outside QQ, to obtain an
alternate format for output, as described above. I don't think there
will be any disagreement with making that available. The question
will be - what should the default be? So far, there is a +2\epsilon
in favor of the QQbar version replacing the Galois conjugate version.
Rob
Thanks for your comments.
On Jun 24, 8:06 am, Gonzalo Tornaria <torna...@math.utexas.edu> wrote:
> What's wrong with:
Nothing - except there are no vector spaces in sight. I'd like to
retain the exposure to vector spaces (eigenspaces) without going as
far as Galois theory. They are a nice lead-in to invariant subspaces,
which would be a central topic for a second course.
> And what if the output of "B.eigenspaces_right()" is a bit confusing?
> I'd argue that's actually a feature, because it will make the student
> *think* about it, get a glimpse of some interesting mathematics, and
> maybe open a door to a new world.
minimum of two semesters of calculus, and afterwards are expected to
be ready for real analysis and abstract algebra. Many do not major in
mathematics, but are from physics, computer science and economics. My
course is different from many, in that we do not have an engineering
college, so we don't serve that audience.
I'll play the experience card - I've taught this course about 30
times. My experience tells me that if the only way to get an
eigenspace of matrix over QQ is to take a detour into roots of
irreducible polynomials, then I will just skip it entirely. It just
goes too far down a road that I don't find beneficial for the vast
majority of the students at that point - they are already struggling
with ideas like matrix representations of linear transformations.
With the Galois conjugate version optionally available, it will still
be there via a keyword to challenge students (or inform our own
research).
I am just now about to implement optionally promoting a QQ matrix to a
QQbar matrix when the eigenvalues lie outside QQ, to obtain an
alternate format for output, as described above. I don't think there
will be any disagreement with making that available. The question
will be - what should the default be? So far, there is a +2\epsilon
in favor of the QQbar version replacing the Galois conjugate version.
Rob
John Cremona
Jun 24, 2011, 4:35:47 PM6/24/11
to sage-...@googlegroups.com
I'll add my vote for that.
John
> Rob
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
Nils Bruin
Jun 24, 2011, 5:37:11 PM6/24/11
to sage-devel
On Jun 24, 11:48 am, Rob Beezer <goo...@beezer.cotse.net> wrote:
> I am just now about to implement optionally promoting a QQ matrix to a
> QQbar matrix when the eigenvalues lie outside QQ, to obtain an
> alternate format for output, as described above. I don't think there
> will be any disagreement with making that available. The question
> will be - what should the default be?
For the core functionality methods, we should not be guided by
> I am just now about to implement optionally promoting a QQ matrix to a
> QQbar matrix when the eigenvalues lie outside QQ, to obtain an
> alternate format for output, as described above. I don't think there
> will be any disagreement with making that available. The question
> will be - what should the default be?
pedagogical concerns but with what makes most sense in the entire
system. It is valuable to have consistent defaults. For general fields
(e.g., and algebraic extension of the function field Q(x,y)) we won't
have any reasonable analogues of QQbar, so I don't think there is a
reasonable default possible other than giving eigenvalues/vectors/
spaces defined over the original base field. For rings the whole
concept becomes a little more complicated anyway.
However, if these are methods that are already added to provide a
pedagogical/convenient interface, then core consistency is of course
not an issue.
In general, I would say the methods are the place for core
functionality offered in a consistent (because ducktyped!) way and
toplevel functions exist to do funny, convenient, less consistent
tricks (such as the injecting "var" on interactive toplevel), but
putting extra eigenspace/value/vector functions in toplevel might be
too much pollution.
Rob Beezer
Jul 14, 2011, 1:22:22 AM7/14/11
to sage-devel
I've tackled #1 on my original list, the subject of the most
discussion here. Found a variety of bugs in the process - caching
mistakes and the problem with matrices over QQbar discussed elsewhere.
My approach to eigenspaces and Galois conjugates was to introduce a
"format" keyword with possible values of 'all' and 'galois'. The
former attempts to locate eigenvalues in the base field, or extend to
QQbar. When this fails, the exception message mentions the 'galois'
option. This latter option preserves current behavior. The change in
current behavior is that the 'all' option would become the default.
So newbies could see QQbar elements that look familiar by default,
pros can chose Galois conjugates when required (and will discover this
possibility in an exception message).
Two relevant comments from having my head in the code: (1) outside of
the eigen-stuff code, the only place it was necessary to supply the
'galois' option was in the method for eigenspaces of a graph, (2)
looking at doctests and code for the other eigen-routines, the more I
felt this change would make for more consistency in the output across
routines.
http://trac.sagemath.org/sage_trac/ticket/11595
discussion here. Found a variety of bugs in the process - caching
mistakes and the problem with matrices over QQbar discussed elsewhere.
My approach to eigenspaces and Galois conjugates was to introduce a
"format" keyword with possible values of 'all' and 'galois'. The
former attempts to locate eigenvalues in the base field, or extend to
QQbar. When this fails, the exception message mentions the 'galois'
option. This latter option preserves current behavior. The change in
current behavior is that the 'all' option would become the default.
So newbies could see QQbar elements that look familiar by default,
pros can chose Galois conjugates when required (and will discover this
possibility in an exception message).
Two relevant comments from having my head in the code: (1) outside of
the eigen-stuff code, the only place it was necessary to supply the
'galois' option was in the method for eigenspaces of a graph, (2)
looking at doctests and code for the other eigen-routines, the more I
felt this change would make for more consistency in the output across
routines.
http://trac.sagemath.org/sage_trac/ticket/11595
Reply all
Reply to author
Forward
0 new messages