So William knows my memory is faulty, and I finally overcame my own laziness and looked at the code (and the ticket where this originated, http://trac.sagemath.org/sage_trac/ticket/10746). IML, PARI, Sage generic code produce right kernels. These come in different formats, so one option for the right_kernel_matrix() function is to do no extra processing of the result by asking for a "computed" basis. ('padic' uses IML.)
sage: A = matrix(ZZ, [[-1, 0, -2, 2, -3], [1, -1, 4, 0, 0], [2, -2, 8, 0, 0], [0, -2, 4, 4, -6]]) sage: A.right_kernel_matrix(algorithm='padic', basis='computed') [ 2 -2 -1 0 0] [-2 -2 0 -1 0] [ 3 3 0 0 -1] sage: A.right_kernel_matrix(algorithm='pari', basis='computed') [-1 -1 0 1 1] [ 1 1 0 2 1] [-2 2 1 0 0] Over fields, the results of a "basis matrix" of a kernel are a list of vectors as rows, echelonized, whereas the computed basis of the Sage generic code comes naturally (and simply) from the echelon form. sage: A.change_ring(QQ).right_kernel_matrix(algorithm='generic', basis='computed') [-2 2 1 0 0] [ 2 2 0 1 0] [-3 -3 0 0 1] sage: A.change_ring(QQ).right_kernel().basis_matrix() [ 1 0 -1/4 0 -1/6] [ 0 1 1/4 0 -1/6] [ 0 0 0 1 2/3] The existing code before the ticket had a "_right_kernel_matrix()" over the integers, which was called one place (sage/algebras/quatalg/quaternion_algebra.py) and this was the model for the new non-underscore method which replaced it (available for almost any ring). Previously Sage had a preference for left kernels, so a matrix would be transposed *before* the call to a specialized procedure that was designed to compute right kernels. For a right kernel, the matrix would be transposed to compute a left kernel, then transposed again to be correct input for the routine. I think this inefficiency is now gone. I would be in favor of a right kernel matrix having its vectors as columns. It looks like this would save some transposes on the exit from the actual routines doing the computations. In refactoring, I was concentrating on the organization of the code and packaging of the results, so left a lot of things alone. It looks to me now like some of this old code could be made more efficient in terms of packaging the results. However, changing the format of an output of a function like this, especially for square matrices, would probably be unwise. Anyway, short answer is that there looks to be some room for further (minor) improvements. But you'd have to look at the code. Rob -- 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
