-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Structured array .= silently ignores unstructured non-zeros #623
Comments
Seems like the most practical solution is to just disallow this with structured and non-structured arguments. Otherwise it would have to test for triangularity, diagonality, etc each time. |
I'm not sure what you mean; we could simply whitelist types in a method signature so that dispatch knows which types it can use. |
Ah, dang. This is an issue for all structured array assignments. All those methods need to check for structure/zero-preserving-ness like the non-in-place broadcasts. |
Sorry, we are on the same page. I misread this part:
What I meant by this was that if we allowed any matrix type, then we would have to call A small problem is that we lose some cases where we have (for example) a |
Previously, broadcasted assignment (`.=`) would happily ignore all nonstructured portions of the destination, regardless of whether the broadcasted expression would actually evaluate to zero or not. This changes these in-place methods to use the same infrastructure that out-of-place broadcast uses to determine the result type. If we are unsure of the structural properties of the output, we fall back to the generic implementation, which will attempt to store into every single location of the destination -- including those structural zeros. Thus we now error in cases where we generate nonzeros in those locations.
Note that it's not just argument types — it also depends on the function. For example, |
…#31678) Previously, broadcasted assignment (`.=`) would happily ignore all nonstructured portions of the destination, regardless of whether the broadcasted expression would actually evaluate to zero or not. This changes these in-place methods to use the same infrastructure that out-of-place broadcast uses to determine the result type. If we are unsure of the structural properties of the output, we fall back to the generic implementation, which will attempt to store into every single location of the destination -- including those structural zeros. Thus we now error in cases where we generate nonzeros in those locations. (cherry picked from commit 6bd3967)
Consider the following:
Note that
U
was updated with the result of elementwise addition withX
. However,U
is still anUpperTriangular
, even though the right hand side of the addition is not. Generally speaking, the result of adding two matrices is only upper triangular if both are.It seems to me that the case of updating a structured matrix should not work except when the operation would produce a matrix of the same structure.
The text was updated successfully, but these errors were encountered: