A while ago, there was a big discussion about making the echelon_form and echelonize command for matrices automatically work over the fraction field of the base ring, sort of like how the inverse operation works now. The plan then was to make the current echelon functions instead be hermite form functions, and make new echelon functions that would first convert the base ring to a fraction field.
The relevant ticket is #3211. Well, it's been about a year now, and I'm wondering if such a fundamental change is advisable any more. For me, the reason to make the change was because many linear algebra people, and almost all undergraduate students learning linear algebra, always consider a matrix to be over a field, even if the entries of the matrix are just integers. You can see in numerous tutorials and helps for linear algebra in Sage the explanations about why the person really needs to declare a matrix as matrix(QQ, data), not just matrix(data). As of now, I can see several possibilities: 1. Keep everything the way it is, but make a new function, say m.rref(), that automatically works over the fraction field. I don't believe this handles things like row reducing (over QQ) the basis of a nullspace when entries are just integers, though. Compare, for example, matrix(range(9)).right_kernel() and matrix(QQ,range(9)).right_kernel(), where a student would expect the latter answer for the former question. 2. Change all references to echelon form for non-fields to hermite form, and have echelon form first construct the fraction field before doing anything. Of course, echelon form for fields does not need to change. This was the vote from the discussion a long time ago, but it is also a rather invasive change. This leads to the "right" behavior from a student's standpoint that a matrix is always over a field (or, you might say, the matrix by default acts like it is over a field). 3. Keep everything as it is and forever keep explaining to students and linear algebra people that they must declare their matrices as matrix(QQ, ...), etc. I think this was voted down in the previous discussion. Any other ideas? What do you think we should do now? Proceed with option 2, or has the growth of Sage in the last year made it so that option 2 is impractical now? Jason -- Jason Grout --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
