#9562: Add M4RIE to Sage
---------------------------------------------------+------------------------
Reporter: malb | Owner:
Type: enhancement | Status:
needs_work
Priority: major | Milestone: sage-5.0
Component: packages | Keywords: m4ri
Work_issues: Fix some docs and fix "randomize()" | Upstream: N/A
Reviewer: Paul Zimmermann, Simon King | Author: Martin
Albrecht
Merged: | Dependencies: #11574
---------------------------------------------------+------------------------
Comment(by malb):
Replying to [comment:88 SimonKing]:
> 2. I found some issues with the "randomize" methods.
>
> i) The randomize method in sage/libs/ntl/ntl_mat_GF2E.pyx is not
documented (thus, also has no tests), and it lacks the usual optional
arguments `density` and `nonzero`.
Okay, I'll take a look. Note that {{{ntl_mat_GF2E}}} does not have the
same interface as normal matrices though. But it makes sense to make it
consistent where possible.
> ii) The doc of Matrix_mod2e_dense.randomize gives no use cases for the
optional arguments. Actually, the behaviour when passing the optional
arguments is clearly not what we want:
Okay, I'll take a look.
> 3. The doc of many methods needs some polishing.
>
> * It would be nice to have a reference to research articles. I had
never heard of Travolta tables before. Strassen-Winograd and Karatsuba may
be better known, but still, a reference could help.
There is no research article on Travolta tables yet since I made them up
for M4RIE. But for the other ones I can add references.
> * _matrix_times_matrix is not documented.
This is an internal method which is part of the standard matrix interface.
I'd say it is hence understood what it does.
> * `__init__`, `__cinit__` do not specify their arguments.
Okay.
> * `_lmul_`, `__neg__`, `__richcmp__`, `__invert__`, `__reduce__`,
`set_unsafe` and `get_unsafe` do not state what they do, and the method
names do not occur in the example (so, it should be marked as an indirect
doctest).
These are special methods where either Python or our Matrix classes define
what they do. I'd say it is hence understood what they do.
> * cdef'd methods such as rescale_row_c or add_multiple_of_row_c or
swap_rows_c and so on may not be as easily visible by the user than Python
methods. However, as a courtesy to developers who actually read the source
file, the arguments of those methods should be specified.
Okay.
> * "echelonize" should state what it does and what its optional
arguments are. If I am not mistaken, it changes the matrix inplace, and
that should be documented.
Okay.
> * When I read "Classical cubic matrix multiplication.", I first
understood that the matrix is cubic. But perhaps I'm a bit square here...
>
> So, that's "needs work" for now.
> Since there should be a vote on sage-devel anyway, we might also ask
whether it should be included in the docs. I am still not sure: On the one
hand, I think a reference manual should be thorough. On the other hand,
all "new" methods that are no cdef'd methods and do not start with an
underscore overwrite methods from super-classes that are documented
elsewhere.
I'd much rather add a note to the reference manual which lists which
library drives which base field?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9562#comment:95>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
