New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make diagonal_matrix accept much more general arguments #3704
Comments
comment:1
Would it be easy as taking the argument to diagonal_matrix and sending it through Sequence?
|
comment:2
The attached patch is a complete rewrite of diagonal_matrix which now does the following:
This changes the syntax slightly; in order to get a matrix of a specific size, you need to pass an nrows and/or ncols option. But it is very nice in that it allows diagonal_matrix(1,2,3) or, as mentioned in this ticket, diagonal_matrix(v) where v is a vector. All doctests in sage/matrix/* pass and all doctests elsewhere that I found using diagonal_matrix also pass. |
comment:4
I guess it really is a defect, as pointed about above; there is a bug that is fixed. |
comment:6
I generally like this patch, and it provides useful functionality. I applied th patch to 3.0.4 with no problem and all tests in Two things seemed strange to me:
That last example would not even work if it were not possible to |
comment:7
The patch looks mostly good, but I heartily agree with points (1) and (2). Also, the following gives an undesired result:
If a ring is specified, it is converted even if there is no coercion. This allows stuff like
despite there being no coercion QQ -> GF(101). |
comment:8
The patch looks mostly good, but I heartily agree with points (1) and (2). Also, the following gives an undesired result:
If a ring is specified, it is converted even if there is no coercion. This allows stuff like
despite there being no coercion QQ -> GF(101). |
comment:9
Thanks for the feedback! I'm at a conference now, so I won't have time to address point 2 for a few days. However, to address point 1: the previous version of diagonal_matrix allowed for the rows to be specified and padded with zeros. I was providing an example which showed how to achieve this effect. Basically, I'm also showing that behavior is like the matrix() command (to which I am just blindly passing all keyword arguments, except for some special behavior about the sparse keyword). So: the behavior is a result of the behavior of matrix() and shows how to achieve a former behavior of diagonal_matrix. Whether or not it is actually useful is another issue: if anyone did use this feature, though, it might be nice to have an example of how to do it with the new diagonal_matrix. I also agree that coercion should play a role, as pointed out in point 2. I'll look at that early next week, hopefully. Thanks again! |
comment:10
Okay, with the example:
that comes from As to another point, I get:
so with x being a symbolic variable, things work fine. However, if we have an iterable object, then things are not so good. In that case, the patch tries to construct a Sequence object from the iterable object, which is where you get your weird results. I'm changing the patch so that if a list or tuple is passed in, then it tries to construct Sequence object from that list or tuple. Note that this is only for backwards-compatibility, so we can still pass a list into diagonal_matrix and have it return what it used to return. |
comment:11
Attachment: trac-3704-diagonal_matrix.patch.gz Okay, new patch is up which should take of the issues in my previous post. |
comment:12
I successfully applied the patch to 3.1.alpha0 and all seems to work as advertised. All tests in sage.matrix pass. Publish! |
comment:13
Patches at #2577 seem to do something very close to this patch, so someone ought to sort out if there are any differences that could be resolved into one unified patch. Cheers, Michael |
comment:15
Attachment: trac-3704-diagonal_matrix-2.patch.gz I just added a patch, to be applied on top of the first patch, which does two things:
|
Attachment: trac-3704-diagonal_matrix-3.patch.gz |
comment:17
Let's agree to kill #2577 since it does nothing which these patches do not do, and these are now a lot better. I applied both patches to 3.1.2.alpha3 with no problems. All the above examples now work and give sensible answers. They are not all included as doctests though. I hit a doctest error in sage/matrix/matrix_integer_dense_hnf.py:
This is trivial to fix, and I added a trivial patch which fixes it. Conclusion: kill #2577 and merge this one (all three patches). I assume mabshoff can take on the responsibility of reviewing the final mini-patch! |
comment:18
Attachment: trac-3704-diagonal_matrix-4.patch.gz PS Forgot to add that doctest: 4th patch does that too. |
comment:19
Is there a reason that we got rid of this construction?
It should at least be deprecated first. |
comment:20
There was exactly one doctest which stopped working with that construction missing, and the fix was just to delete the nrows parameter. I don't have strong feelings about deprecating things like this. I think the point of having nrows in there was so that diagonal_entries could be shorter than nrows and then would be padded out by zeroes. I feel happier requiring the user to provide the whole list of diagonal entries, but if someone wants to put this construction back I don't mind either. |
comment:21
There was some extended discussion on sage-devel and the consensus is that the new non-list constructor will break if more than 255 elements are passed. So this needs work :) Cheers, Michael |
comment:22
I'm attaching a new patch which takes a much lower level approach to solving the problem. If a complete rewrite is really necessary, I propose we open a new ticket for it, since this ticket is just about constructing a diagonal matrix from a vector. |
Attachment: trac-3704.patch.gz Independent of the other patches found here. |
comment:23
Positive review for rlm's patch. It fixes the problem mentioned in the ticket. The new ticket rlm mentioned is #5110. |
comment:24
(because of #5110, do not delete the other patches on this ticket.) |
comment:25
Merged trac-3704.patch only in Sage 3.3.alpha3. Cheers, Michael |
So I think this is a bug
The following fails as well
the only thing that works is
A stupid but easy fix is to try to turn any argument to diagonal_matrix into a list before bailing out (its in matrix/constructor.py), but there should probably be logic actually expecting vectors and analyzing the parents?
Component: linear algebra
Issue created by migration from https://trac.sagemath.org/ticket/3704
The text was updated successfully, but these errors were encountered: