On Mon, Jun 14, 2010 at 2:52 PM, David Kohel <drko...@gmail.com> wrote: > Hi, > > Backwards compatibility or not, I consider this either a bad design > or a bug: > > sage: M = Matrix([[1,-1],[1,0]]) > sage: f = M.minimal_polynomial() > sage: f.roots() > [] > sage: M.eigenvalues() > [0.50000000000000000? - 0.866025403784439?*I, 0.50000000000000000? + > 0.866025403784439?*I]
Yes, this is inconsistent. > First of all, why return roots in some arbitrary field? It's not that arbitrary -- its QQbar, which is the only field in all of Sage that allows for holding all the eigenvalues and doing arithmetic with them. There's is no other such field, which doesn't loose information (e.g., the floating point fields would be lossy). > I don't agree that this is the most natural result for first year > calculus or linear algebra. Many will only consider real > solutions to be valid. The truth of your claim could be determined by doing a survey of undergraduate matrix and linear algebra texts. But Rob Beezer who teaching linear algebra all the time and wrote a big book on the topic says "I wish I had my bookshelf of roughly thirty intro linear algebra textbooks handy, but I'll go out on a limb and suggest most, or all, will claim that a square matrix of size n has n eigenvalues (counting multiplicities), so by implication considering roots outside the base field (usually RR)." > Certainly an algebraist will expect solutions over the given > base ring. > > There is also the lack of consistency with sqrt(3), which returns > a symbolic ring element - why not the same for eigenvalues? In general, arbitrary roots of polynomials can't be represented symbolically in terms of radicals, so I think this is a bit different. > > Over a finite field, one should ask if Sage is consistent: > > sage: FF = FiniteField(Integer(5)) > sage: M = Matrix(FF,[1,-1],[1,0]]) > sage: M.eigenvalues() > > I get a 'Not implemented error' -- but this should be implemented > and should give something consistent. Nobody has implemented Fpbar yet in Sage. On the other hand Qbar is implemented. Obviously, Fpbar should be implemented. > In a general system, > I can't see anything reasonable that one can do in general other > than returning the roots of the characteristic polynomial in the > base ring. The most consistent solution, that extends what is already there is to allow a ring parameter to eigenvalues: sage: M.eigenalues(ring) that returns only eigenvalues in a given ring. > > I find the syntax: > > M.eigenvalues(ring=None, extend=False) > > perfectly well-defined. Since extend=True will fail for most > rings, since a natural algebraically closed field containing > the base ring is unlikely to exist or be implemented in Sage, > so I don't think that default can be extend=True. I prefer M.eigenvalues(ring=None, extend=True) because otherwise we massively break backwards compatibility. This does matter. A lot. "Most rings" above is ambiguous -- most rings in existence, or most rings that actual users use. If the former, then your statement is probably true, since "most rings" are ridiculous iterated polynomial ring extensions. If the latter (what people use), then most rings = QQ, RR, CC, RDF, CDF, which surely accounts for 99% of matrix algebra usage for Sage (and in the long run, probably 99.99%). > > So I must vote > > -1 > > to default extend=True. On the other hand, I think > > M.eigenvalues(CC) > > gives a simple syntax for linear algebra students, and also > lets them do > > M.eigenvalues(RR) > > in order to distinguish between real vector spaces, complex > ones, or different behaviors of these spaces. I'm not sure > all teachers and students would prefer CC over RR -- in my > experience in Sydney complex numbers only existed for > "advanced" first year students, Wow, that's weird. I learned about complex numbers in 8th grade in a small public school in smalltown rural Texas. And when I went to college, I was a Computer Science and Engineering major, and complex numbers played a big role even in basic electrical engineering courses. > and for students in the > "ordinary" track the real numbers were enough (one could > argue that such relative mathematics should not exist but > there are still different teaching needs). When studying > or teaching real solutions for a problem, one needs a simple > syntax for equation solving over RR or CC. > > I would hope that Sage could keep a generic syntax for > linear algebra which doesn't require knowing that one > behavior will result for matrices over the integers, > rationals, or reals, a different one for linear operators, > and a completely different set of behaviors when the > base ring is a finite field, number field, power series > ring, or function field. > > I would argue that one should always ask first whether > a given function makes sense in a general context, and > not implement something which conflicts with the function > in the general context. Statisticians and engineers want pretty much everything to be double precision real or complex, and so do I when I'm doing stats (!). Algebraists want what you want above. Linear algebra teachers/undergrads want something different. When you read mathematics in a given subject area it is often very difficult initially because of the implicit assumptions about what the "default behaviors" of objects are. In the long run though, the writing style that was initially difficult to read becomes very readable. Math is hard. -- William > > --David > > On Jun 14, 7:14 pm, Rob Beezer <goo...@beezer.cotse.net> wrote: >> Miguel, >> >> Having read #8974 carefully, I could see the default for endomorphisms >> going either way. My main concern is that matrices follow practice >> and default to providing eigenvalues (and eigenvectors) outside the >> base field. Endomorphisms could default to behave identically to >> matrices, or they could respect the notion of being functions and only >> return "proper" elements of the domain and range, as you have argued >> in regards to your own teaching. But with options available for >> matrices and endomorphisms, individual opinions/tastes can be >> accomodated. >> >> Thanks for bringing the discussion to sage-devel. >> >> Rob > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
