On Thu, May 15, 2008 at 4:04 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On May 15, 2008, at 8:21 AM, Bjake Hammersholt Roune wrote:
>
>>> [...] people are confused that when
>>> they create a matrix with matrix(3, range(9)), for example, that the
>>> echelon_form is not the rref output that they get from most any other
>>> program they have ever used [...]
>>> What do people think about making the default ring for matrices QQ?
>>>
>> I have no objections to making QQ the defailt ring for matrices.
>> However, I don't think this resolves the problem entirely.
>>
>> A part of the confusion stems from echelon_form doing entirely
>> different things based on the type of argument it gets. I would prefer
>> echelon_form to always use fractions, and have some other function
>> avoid the fractions. Another solution I could get behind is for
>> echelon_form to have a parameter for whether to use fractions, and
>> have the default be to use them.
>
> I would second this idea, I like it much better than matrix(3,range
> (9) being over Q. I think that's the way it used to be. It seems odd
> to make matrices by default over their fraction fields (if they
> exist)--other than echelon form is there any other case that one
> wants this. This could slow things down a lot too--matrices over QQ
> have some overhead (only O(n^2)) over matrices over ZZ, but there is
> a huge difference in performance for Z[x] and Frac(Z[x]). Also, then
>
> sage: matrix(3, range(9).charpoly('x')
>
> would return a polynomial over QQ rather than ZZ which I think is odd
> and less efficient.I think based on this whole discussion: (1) matrix(3, range(9)) returning a matrix over QQ is *definitely* out. If there is a trac ticket it should be marked invalid. (2) The echelon_form command should be changed to always return a result over the fraction field, thus making a break with Magma. (3) Rewrite all the rest of code in Sage that depends on the current behavior of echelon_form. This code will have to call hermite_form instead. E.g., code in modules/free_module.py will have to change. Code in a.kernel() will have to change, etc. Doing (1), (2) is almost trivial. Do (3) will be a little more difficult, and could introduce bugs. I'm very much against a.echelon_form(...) being over ZZ or QQ depending on arguments to echelon_form. If for no other reason than even if one does that then it will still be necessary to do all of (3) above. I've cc'd David Kohel on this email, since he is 100% responsible for the current state of affairs regarding echelon form, and I want to give him a chance to speak up before we do (1)-(3) above. -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
