Sage: Ticket #9720: Add random echelonizable matrices to matrix/constructor.py
https://trac.sagemath.org/ticket/9720
<p>
Adds two routines. One creates random matrices in echelon form to be used in other routines to be added later. The other creates random matrices whose echelon form has desirable properties, with the help of the first routine. These routines are designed as educational tools, generating exam and homework problems, and problem generating interacts.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/9720
Trac 1.1.6bwonderlyTue, 10 Aug 2010 19:05:13 GMTattachment set
https://trac.sagemath.org/ticket/9720
https://trac.sagemath.org/ticket/9720
<ul>
<li><strong>attachment</strong>
set to <em>trac_9720-random-echelonizable-matrices.patch</em>
</li>
</ul>
TicketbwonderlyTue, 10 Aug 2010 19:11:10 GMTstatus changed
https://trac.sagemath.org/ticket/9720#comment:1
https://trac.sagemath.org/ticket/9720#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketwdjWed, 11 Aug 2010 11:12:26 GMT
https://trac.sagemath.org/ticket/9720#comment:2
https://trac.sagemath.org/ticket/9720#comment:2
<p>
Applies fine to 4.5.2.rc0.
</p>
<p>
Two extremely minor comments off the top of my head:
</p>
<ol><li>"Generate a matrix of a desired size and rank, over a desired field,
</li></ol><blockquote>
<p>
whose reduced row-echelon form has only whole values."
</p>
</blockquote>
<p>
IMHO, "integral" sounds better than "whole".
</p>
<ol start="2"><li>It seems to me that, from the point of view of the functionality,
</li></ol><p>
using base_ring = ZZ returns the same result as base_ring = QQ.
(I understand that over QQ the rref algorithm might be different than over
ZZ, but it seems to me that for the matrices you compute in the
random_echelonizable_matrix function, the rref algorithm(s) yield
the same result either way. Correct?
</p>
TicketbwonderlyWed, 11 Aug 2010 22:55:31 GMTattachment set
https://trac.sagemath.org/ticket/9720
https://trac.sagemath.org/ticket/9720
<ul>
<li><strong>attachment</strong>
set to <em>trac_9720-random-echelonizable-matrices-v2.patch</em>
</li>
</ul>
<p>
stand-alone version 2 patch, same patch with one revision
</p>
TicketbwonderlyWed, 11 Aug 2010 23:05:43 GMT
https://trac.sagemath.org/ticket/9720#comment:3
https://trac.sagemath.org/ticket/9720#comment:3
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9720#comment:2" title="Comment 2">wdj</a>:
</p>
<blockquote class="citation">
<p>
Applies fine to 4.5.2.rc0.
</p>
<p>
Two extremely minor comments off the top of my head:
</p>
<ol><li>"Generate a matrix of a desired size and rank, over a desired field,
</li></ol><blockquote>
<p>
whose reduced row-echelon form has only whole values."
</p>
</blockquote>
<p>
IMHO, "integral" sounds better than "whole".
</p>
</blockquote>
<p>
I agree completely and have made the change in the v2 patch.
</p>
<blockquote class="citation">
<ol start="2"><li>It seems to me that, from the point of view of the functionality,
</li></ol><p>
using base_ring = ZZ returns the same result as base_ring = QQ.
(I understand that over QQ the rref algorithm might be different than over
ZZ, but it seems to me that for the matrices you compute in the
random_echelonizable_matrix function, the rref algorithm(s) yield
the same result either way. Correct?
</p>
</blockquote>
<p>
Yes, the rref algorithm yields the same result with base_ring as ZZ or QQ. However, as these matrices are going to be used primarily as student example problems I think it would be better to keep the default as QQ. Although there should be a series of row operations without introducing fractions that achieves rref, a student will likely want to use fractions as they row-reduce an output matrix, and the rescale_row or add_multiple_of_row functions will complain if fractions are introduced working with a matrix over ZZ.
</p>
<blockquote class="citation">
</blockquote>
TicketwdjWed, 11 Aug 2010 23:21:45 GMT
https://trac.sagemath.org/ticket/9720#comment:4
https://trac.sagemath.org/ticket/9720#comment:4
<p>
I am ready to give this patch a positive review. However, although it aplies fine to 4.5.2.rc0, it does not pass sage -testall on a 10.6.4 mac pro. The problems seem to be in some mysterious (to me) failures in
</p>
<pre class="wiki">sage -t "local/lib/python2.6/site-packages/sagenb-0.8.2-py2.6.egg/sagenb/misc/sageinspect.py"./sage -t "local/lib/python2.6/site-packages/sagenb-0.8.2-py2.6.egg/sagenb/misc/sageinspect.py"
-bash: sage: command not found
hera:sage-4.5.2.rc0 davidjoyner$ ./sage -t "local/lib/python2.6/site-packages/sagenb-0.8.2-py2.6.egg/sagenb/misc/sageinspect.py"sage -t "local/lib/python2.6/site-packages/sagenb-0.8.2-py2.6.egg/sagenb/misc/sageinspect.py"
**********************************************************************
File "/Volumes/Bay2/sagefiles2/sage-4.5.2.rc0/local/lib/python2.6/site-packages/sagenb-0.8.2-py2.6.egg/sagenb/misc/sageinspect.py", line 951:
sage: sage_getsourcelines(matrix, True)[1]
Expected:
34
Got:
35
</pre><p>
and a similar failure in
</p>
<pre class="wiki">sage -t "devel/sage/sage/misc/sageinspect.py"
</pre><p>
I'll try investigating this using an ubuntu machine, but this seems to possibly be an issue.
</p>
TicketrbeezerWed, 11 Aug 2010 23:44:51 GMT
https://trac.sagemath.org/ticket/9720#comment:5
https://trac.sagemath.org/ticket/9720#comment:5
<p>
Appears to me that the test that fails is testing an actual line number of source code from the file defining the <code>matrix</code> constructor. Billy added an import statement at the top of the module, so the line numbers will increment by one?
</p>
<p>
Rather than patching sagenb, I'm going to do some tests - maybe adding the import of QQ to the same line as the import of ZZ will be a solution.
</p>
<p>
Rob
</p>
TicketrbeezerThu, 12 Aug 2010 00:11:46 GMTstatus changed
https://trac.sagemath.org/ticket/9720#comment:6
https://trac.sagemath.org/ticket/9720#comment:6
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Billy,
</p>
<p>
Make a v3 patch and replace the two import statements for ZZ and QQ by the statement
</p>
<pre class="wiki">from sage.rings.all import ZZ, QQ
</pre><p>
and subsequent line numbers will return to "normal" and this very technical test should pass. Do the very complete tests
</p>
<pre class="wiki">./sage -testall
</pre><p>
overnight and then post the patch.
</p>
<p>
I've tested this change on matrix/constructor.py and the two files David has failing.
</p>
<p>
David - nice catch!
</p>
<p>
Rob
</p>
TicketjasonThu, 12 Aug 2010 03:11:40 GMT
https://trac.sagemath.org/ticket/9720#comment:7
https://trac.sagemath.org/ticket/9720#comment:7
<p>
In the first line of the docstring for the second function, you say:
</p>
<p>
Generate a matrix of a desired size and rank, over a desired field,
</p>
<p>
Should that say "desired ring"?
</p>
TicketbwonderlyThu, 12 Aug 2010 07:13:22 GMTattachment set
https://trac.sagemath.org/ticket/9720
https://trac.sagemath.org/ticket/9720
<ul>
<li><strong>attachment</strong>
set to <em>trac_9720-random-echelonizable-matrices-v3.patch</em>
</li>
</ul>
<p>
stand-alone version 3 of the same patch, with import statement change and documentation revision
</p>
TicketbwonderlyThu, 12 Aug 2010 07:16:38 GMT
https://trac.sagemath.org/ticket/9720#comment:8
https://trac.sagemath.org/ticket/9720#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9720#comment:7" title="Comment 7">jason</a>:
</p>
<blockquote class="citation">
<p>
In the first line of the docstring for the second function, you say:
</p>
<p>
Generate a matrix of a desired size and rank, over a desired field,
</p>
<p>
Should that say "desired ring"?
</p>
</blockquote>
<p>
Absolutely, I've made that change and the import statement change, and all tests passed.
</p>
TicketrbeezerThu, 12 Aug 2010 17:02:09 GMTstatus changed
https://trac.sagemath.org/ticket/9720#comment:9
https://trac.sagemath.org/ticket/9720#comment:9
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
I think this means you are ready to have the reviewing proceed, so I'll change the status to "needs review".
</p>
TicketwdjThu, 12 Aug 2010 18:12:23 GMTstatus changed
https://trac.sagemath.org/ticket/9720#comment:10
https://trac.sagemath.org/ticket/9720#comment:10
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
The latest patch applies fine to 4.5.2.rc0 and passes sage -testall on a 10.6.4 mac pro.
</p>
<p>
This is a well-documented addition and I definitely will use it teaching linear algebra this semester. Thanks for coding this up!
</p>
TicketmpatelSun, 15 Aug 2010 09:17:23 GMTreviewer set
https://trac.sagemath.org/ticket/9720#comment:11
https://trac.sagemath.org/ticket/9720#comment:11
<ul>
<li><strong>reviewer</strong>
set to <em>David Joyner</em>
</li>
</ul>
TicketbwonderlySun, 15 Aug 2010 19:55:43 GMT
https://trac.sagemath.org/ticket/9720#comment:12
https://trac.sagemath.org/ticket/9720#comment:12
<p>
Thanks everyone for the suggestions and the expeditious review!
</p>
<p>
Release manager: apply only v3 patch.
</p>
TicketmhansenWed, 25 Aug 2010 20:00:35 GMTstatus changed
https://trac.sagemath.org/ticket/9720#comment:13
https://trac.sagemath.org/ticket/9720#comment:13
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
I think that these should really just be options to the random_matrix function so that we don't have a ton of <code>random_*_matrix</code> commands floating around in the global namespace.
</p>
TicketwdjWed, 25 Aug 2010 20:17:43 GMT
https://trac.sagemath.org/ticket/9720#comment:14
https://trac.sagemath.org/ticket/9720#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9720#comment:13" title="Comment 13">mhansen</a>:
</p>
<blockquote class="citation">
<p>
I think that these should really just be options to the random_matrix function so that we don't have a
ton of <code>random_*_matrix</code> commands floating around in the global namespace.
</p>
</blockquote>
<p>
Though this is logical, I personally vote -1 as it will be somewhat harder
to use for those who need it (teachers not necessarily expert in Sage
but needing it for a quick computation for an example or 2 in a lecture note).
</p>
<p>
In any case, I hope this will be approved as I am teaching this *right now*:-)
</p>
TicketrbeezerWed, 25 Aug 2010 20:22:08 GMT
https://trac.sagemath.org/ticket/9720#comment:15
https://trac.sagemath.org/ticket/9720#comment:15
<p>
There won't be tons, just four I think. ;-) But I agree entirely.
</p>
<p>
Would you pass some sort of selector in <code>*args</code>, then make these methods of some class of matrices? How would the documentation be immediately or easily accessible? Is there a model we can follow someplace else in Sage?
</p>
<p>
If you'd be able to suggest a course of action, I can work with Billy to make this happen. He's finished posting all his routines (there aren't any more planned) and classes begin Monday, so it'd be nice to get this going quickly so he can wrap up his summer project.
</p>
<p>
Thanks again, I'd had the same reservations about adding to the global namespace, but hadn't hit on this option.
</p>
<p>
Rob
</p>
TicketrbeezerWed, 25 Aug 2010 20:24:07 GMT
https://trac.sagemath.org/ticket/9720#comment:16
https://trac.sagemath.org/ticket/9720#comment:16
<p>
I agree with David's comments about documentation - maybe we can make that happen smoothly and logically, but its not coming to me right at the moment.
</p>
TicketmhansenWed, 25 Aug 2010 20:34:11 GMT
https://trac.sagemath.org/ticket/9720#comment:17
https://trac.sagemath.org/ticket/9720#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9720#comment:15" title="Comment 15">rbeezer</a>:
</p>
<blockquote class="citation">
<p>
Would you pass some sort of selector in <code>*args</code>, then make these methods of some class of matrices? How would the documentation be immediately or easily accessible? Is there a model we can follow someplace else in Sage?
</p>
</blockquote>
<p>
You can leave the functions as they are -- just don't import them into the global namespace. Then, if you do,
</p>
<pre class="wiki">sage: a = random_matrix(QQ, 3, 3, rref=True)
sage: b = random_matrix(QQ, 3, 3, echelonizable=True)
</pre><p>
which just delegate to the appropriate function. You can add a reference to those functions in the docstring of <code>random_matrix</code>.
Also, the documentation is not clear on why there is special casing for ZZ and QQ, and that these methods don't work for inexact rings. Although, you could argue that if you have one of these matrices over <code>ZZ</code> you could just convert all the entries to <code>RR</code> and things "should" be fine.
</p>
TicketrbeezerWed, 25 Aug 2010 20:49:54 GMT
https://trac.sagemath.org/ticket/9720#comment:18
https://trac.sagemath.org/ticket/9720#comment:18
<p>
Mike -
</p>
<p>
OK, that makes sense - thanks.
</p>
<p>
We also have "diagonalizable", "unimodular" and "subspaceable", so I think something like a single keyword type/category/class/method/algorithm (I don't really like any of those too much) that defaults to the current "randomize" behavior would be better. Is "algorithm" the policy these days for this type of thing? Some constructors must be square so we would have to check for that first. (And we can address the ZZ, QQ, inexact situation.)
</p>
<p>
Thanks for the suggestion and quick help.
</p>
<p>
David - I think I can make the HTML docs work well, and can include the necessary import/qualified statement in the tab-completion documentation to make the notebook/command-line docs relatively easy to access. We'd include at least one full example in the docs for random_matrix() so it could be discovered that way. Does that sound OK?
</p>
<p>
Billy - I'll try to set things up to make current patch work. It won't be too hard then for you to adjust the other two that are outstanding. Sound OK?
</p>
<p>
Rob
</p>
TicketwdjWed, 25 Aug 2010 20:55:15 GMT
https://trac.sagemath.org/ticket/9720#comment:19
https://trac.sagemath.org/ticket/9720#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9720#comment:18" title="Comment 18">rbeezer</a>:
</p>
<blockquote class="citation">
<p>
Mike -
</p>
</blockquote>
<p>
...
</p>
<blockquote class="citation">
<p>
David - I think I can make the HTML docs work well, and can include the necessary import/qualified
statement in the tab-completion documentation to make the notebook/command-line docs relatively
easy to access. We'd include at least one full example in the docs for random_matrix() so it could be
discovered that way. Does that sound OK?
</p>
</blockquote>
<p>
Sounds good - thanks Rob (and Mike)!!
</p>
<blockquote class="citation">
<p>
Rob
</p>
</blockquote>
TicketrbeezerWed, 25 Aug 2010 21:13:15 GMTstatus changed
https://trac.sagemath.org/ticket/9720#comment:20
https://trac.sagemath.org/ticket/9720#comment:20
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_work</em>
</li>
</ul>
TicketjasonWed, 25 Aug 2010 21:25:45 GMT
https://trac.sagemath.org/ticket/9720#comment:21
https://trac.sagemath.org/ticket/9720#comment:21
<p>
To take care of the namespace issue, what about making it work like graphs does? In other words, "random_matrix" behaves like it always has, and "random_matrix.echelonizable(...)", "random_matrix.unimodular()", etc., do the specialized functions?
</p>
<p>
I'm a slight -1 on making random_matrix take a ton of options, a lot of which may be mutually exclusive. For example, if I ask for a random echelonizable matrix over ZZ, with a specific range of entries, will it work?
</p>
TicketrbeezerWed, 25 Aug 2010 21:33:27 GMTattachment set
https://trac.sagemath.org/ticket/9720
https://trac.sagemath.org/ticket/9720
<ul>
<li><strong>attachment</strong>
set to <em>trac_9720-random-echelonizable-matrices-v4.patch</em>
</li>
</ul>
<p>
Same as v3, but removed routines from global namespace
</p>
TicketrbeezerWed, 25 Aug 2010 21:38:32 GMT
https://trac.sagemath.org/ticket/9720#comment:22
https://trac.sagemath.org/ticket/9720#comment:22
<p>
v4 patch is identical to v3, except the two new routines are not imported into the global namespace, and therefore two import commands are needed in the doctests.
</p>
<p>
sage/matrix/constructor.py passes randomized testing (-randorder) with these changes. Full testing later. Upcoming patch will have <code>random_matrix()</code> delegate to these two routines.
</p>
<p>
Billy's name should still be on this patch as the author.
</p>
<p>
Rob
</p>
TicketrbeezerWed, 25 Aug 2010 22:02:56 GMT
https://trac.sagemath.org/ticket/9720#comment:23
https://trac.sagemath.org/ticket/9720#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9720#comment:21" title="Comment 21">jason</a>:
</p>
<blockquote class="citation">
<p>
To take care of the namespace issue, what about making it work like graphs does? In other words, "random_matrix" behaves like it always has, and "random_matrix.echelonizable(...)", "random_matrix.unimodular()", etc., do the specialized functions?
</p>
<p>
I'm a slight -1 on making random_matrix take a ton of options, a lot of which may be mutually exclusive. For example, if I ask for a random echelonizable matrix over ZZ, with a specific range of entries, will it work?
</p>
</blockquote>
<p>
Right now I'm thinking:
</p>
<pre class="wiki">random_matrix(RR, 6, 4, algorithm='randomize')
random_matrix(ZZ, 6, 4, algorithm='echelon_form')
random_matrix(ZZ, 3, 4, algorithm='echelonizable')
random_matrix(ZZ, 8, 8, algorithm='diagonalizable')
</pre><p>
etc. <code>random_matrix()</code> would be a big switch on the value of <code>algorithm</code>. Default would be 'randomize' and preserve current behavior. <code>random_matrix()</code> would throw errors for "wrong" rings, or "wrong" shapes.
</p>
<p>
<code>random_matrix()</code> would have one good example of each type, with link to actual routine's documentation for PDF & HTL version. For notebook or CL docs, the documentation would say "use sage.constructor.random_echelonizable_matrix?" for more detailed documentation right after the example (not tested).
</p>
<p>
<code>random_matrix()</code> already takes lots of options - anything the randomize function of the entry type accepts. I think the new functions only accept <code>upper_bound</code> as an option, as a type of what Billy calls "size control". Currently, the possibilities for arguments is not handled very well:
</p>
<pre class="wiki">sage: random_matrix(QQ, 3, 4, num_bound = 4, den_bound = 10)
[-3/8 -3/5 1 -4/7]
[ 3/2 2/3 -2 -1/2]
[-1/8 1/2 1/8 -3/8]
sage: random_matrix(ZZ, 3, 4, num_bound = 4, den_bound = 10)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/sage/dev/devel/sage-main/<ipython console> in <module>()
/sage/dev/local/lib/python2.6/site-packages/sage/matrix/constructor.pyc in random_matrix(R, nrows, ncols, sparse, density, *args, **kwds)
829 A.randomize(density=float(1), nonzero=False, *args, **kwds)
830 else:
--> 831 A.randomize(density=density, nonzero=True, *args, **kwds)
832 return A
833
/sage/dev/local/lib/python2.6/site-packages/sage/matrix/matrix_integer_dense.so in sage.matrix.matrix_integer_dense.Matrix_integer_dense.randomize (sage/matrix/matrix_integer_dense.c:23941)()
TypeError: randomize() got an unexpected keyword argument 'num_bound'
</pre><p>
I'm -1 to implementing the whole graphs-dot infrastructure for just five or six functions right as Billy is trying to wrap this up. (And possibly having to deprecate any current behavior.) I do want to (but have not found the time yet) to implement the dot-syntax for groups.
</p>
<p>
Just a thought - we could implement a whole random-dot hierarchy: matrices, primes, graphs,....
</p>
TicketjasonWed, 25 Aug 2010 22:09:37 GMT
https://trac.sagemath.org/ticket/9720#comment:24
https://trac.sagemath.org/ticket/9720#comment:24
<p>
The algorithm keyword seems natural enough for me. What I was opposed to was 5 different <a class="missing wiki">True/False?</a> keyword options, each mutually exclusive for the others.
</p>
TicketrbeezerWed, 25 Aug 2010 22:12:49 GMT
https://trac.sagemath.org/ticket/9720#comment:25
https://trac.sagemath.org/ticket/9720#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9720#comment:24" title="Comment 24">jason</a>:
</p>
<blockquote class="citation">
<p>
The algorithm keyword seems natural enough for me. What I was opposed to was 5 different <a class="missing wiki">True/False?</a> keyword options, each mutually exclusive for the others.
</p>
</blockquote>
<p>
Good - I didn't want that either. I'm going to start on the above shortly.
</p>
TicketrbeezerThu, 26 Aug 2010 00:36:10 GMTstatus changed
https://trac.sagemath.org/ticket/9720#comment:26
https://trac.sagemath.org/ticket/9720#comment:26
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Into the <code>random_matrix</code> routine and I've never been happy with the documentation, and I may even change the code now that I've dipped into it. So I'm going to do that work on a new ticket along with allowing for integrating the new constructions. See <a class="closed ticket" href="https://trac.sagemath.org/ticket/9803" title="enhancement: Generalize and document the random_matrix constructor (closed: fixed)">#9803</a>.
</p>
<p>
That means that the v4 patch makes this ready to go. It'll be left hidden until <a class="closed ticket" href="https://trac.sagemath.org/ticket/9803" title="enhancement: Generalize and document the random_matrix constructor (closed: fixed)">#9803</a> is done, but at least David J can import it as needed until then.
</p>
<p>
So if Billy or David want to check-off on my changes from v3 to v4 (undid changes in all.py and added two imports to doctests) then this can go to positive review. I'll add interested parties to <a class="closed ticket" href="https://trac.sagemath.org/ticket/9803" title="enhancement: Generalize and document the random_matrix constructor (closed: fixed)">#9803</a> once I have a patch up, so no need to add yourself yet unless you have more comments.
</p>
<p>
This also allows Billy to be sole author on this.
</p>
TicketwdjThu, 26 Aug 2010 12:01:04 GMT
https://trac.sagemath.org/ticket/9720#comment:27
https://trac.sagemath.org/ticket/9720#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9720#comment:26" title="Comment 26">rbeezer</a>:
</p>
<p>
...
</p>
<blockquote class="citation">
<p>
So if Billy or David want to check-off on my changes from v3 to v4 (undid changes in all.py and added two imports to doctests) then this can go to positive review. I'll add interested parties to <a class="closed ticket" href="https://trac.sagemath.org/ticket/9803" title="enhancement: Generalize and document the random_matrix constructor (closed: fixed)">#9803</a> once I have a patch up, so no need to add yourself yet unless you have more comments.
</p>
</blockquote>
<p>
This looks good to me (I even tested it again for safety's sake:-).
</p>
<blockquote class="citation">
<p>
This also allows Billy to be sole author on this.
</p>
</blockquote>
TicketrbeezerThu, 26 Aug 2010 22:23:15 GMTstatus changed
https://trac.sagemath.org/ticket/9720#comment:28
https://trac.sagemath.org/ticket/9720#comment:28
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Thanks, David. I'm going to move this back to positive review. Patch up at <a class="closed ticket" href="https://trac.sagemath.org/ticket/9803" title="enhancement: Generalize and document the random_matrix constructor (closed: fixed)">#9803</a> to reflect discussion above.
</p>
<h1 id="Releasemanager">Release manager</h1>
<p>
Apply only the v4 patch and please merge with <a class="closed ticket" href="https://trac.sagemath.org/ticket/9803" title="enhancement: Generalize and document the random_matrix constructor (closed: fixed)">#9803</a> once it is ready - the calling syntax changes, so both tickets should go in together.
</p>
TicketbwonderlyFri, 03 Sep 2010 06:27:56 GMT
https://trac.sagemath.org/ticket/9720#comment:29
https://trac.sagemath.org/ticket/9720#comment:29
<h2 id="ReleaseManager">Release Manager</h2>
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/9720" title="enhancement: Add random echelonizable matrices to matrix/constructor.py (closed: fixed)">#9720</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/9803" title="enhancement: Generalize and document the random_matrix constructor (closed: fixed)">#9803</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/9802" title="enhancement: Add random diagonalizable matrix to matrix/constructor.py (closed: fixed)">#9802</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/9754" title="enhancement: Add random unimodular and subspaces matrices to matrix/constructor.py (closed: fixed)">#9754</a> is each dependent on the predecessor, merge in this
order.
</p>
TicketmpatelWed, 15 Sep 2010 09:52:32 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/9720#comment:30
https://trac.sagemath.org/ticket/9720#comment:30
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-4.6.alpha1</em>
</li>
</ul>
Ticket