#3211 - making echelon form work over the fraction field of the base ring of a matrix
Jason Grout
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
Robert Bradshaw
I think (2) is still a viable option.
- Robert
William Stein
I agree. After all, that's what we voted to do, and honestly linear
algebra hasn't changed that dramatically in the last year. And the
arguments for (2) are still as valid as ever, as anybody who teaches
linear algebra will quickly discover.
-- William
Rob Beezer
a case of "explicit is better." If you know you are over a non-field,
then you can request hermite_form() and get what you are after,
staying within your non-field. If you don't know better, or don't
care, having echelon_form() promote your base ring to a field (often
objectionable among developers) will then get you there.
I view the request for echelon form as asking for leading ones in each
row (the form of the result) and you won't generally get that without
division, so the call gives permission to adjust the base ring. If
you don't want your ring messed with, call for hermite form and live
with what you get back.
Rob
kcrisman
On Sep 19, 2:33 pm, Rob Beezer <goo...@beezer.cotse.net> wrote:
> I think (2) is the best solution, and still viable. It strikes me as
> a case of "explicit is better." If you know you are over a non-field,
> then you can request hermite_form() and get what you are after,
> staying within your non-field. If you don't know better, or don't
> care, having echelon_form() promote your base ring to a field (often
> objectionable among developers) will then get you there.
>
changed that much. Honestly, I assumed that had already made it in!
- kcrisman