Skip to content
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.

Sign up for GitHub

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

Jump to bottom

fix off-by-one in findn and findnz #5386

Merged
merged 2 commits into from
Jan 13, 2014
Merged

fix off-by-one in findn and findnz #5386

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5446521
fix off-by-one in findn and findnz
mlubin Jan 13, 2014
e9f0c66
add test for #5386
mlubin Jan 13, 2014
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions base/sparse/sparsematrix.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -298,7 +298,8 @@ function findn{Tv,Ti}(S::SparseMatrixCSC{Tv,Ti})
end
end

if numnz != count-1
count -= 1
if numnz != count
I = I[1:count]
J = J[1:count]
end
Expand All @@ -324,7 +325,8 @@ function findnz{Tv,Ti}(S::SparseMatrixCSC{Tv,Ti})
end
end

if numnz != count-1
count -= 1
if numnz != count
I = I[1:count]
J = J[1:count]
V = V[1:count]
Expand Down
4 changes: 4 additions & 0 deletions test/sparse.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -182,3 +182,7 @@ mfe22 = eye(Float64, 2)

# issue #5169
@test nnz(sparse([1,1],[1,2],[0.0,-0.0])) == 0

# issue #5386
I,J,V = findnz(SparseMatrixCSC(2,1,[1,3],[1,2],[1.0,0.0]))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although this constructor is available, one should really not be creating sparse matrices with stored zeros. A lot of routines assume no stored zeros. Maybe we should not export SparseMatrixCSC?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Creating a sparse matrix with zeros should obviously be discouraged but I
don't think it should be an error. One should just have to pay for the cost
of the extra operations.
In JuMP the sparse constraint matrix follows the structure of the model,
and it's possible for some coefficients to be zero in some instances.

In test/sparse.jl:

@@ -182,3 +182,7 @@ mfe22 = eye(Float64, 2)

issue #5169

@test nnz(sparse([1,1],[1,2],[0.0,-0.0])) == 0
+
+# issue #5386
+I,J,V = findnz(SparseMatrixCSC(2,1,[1,3],[1,2],[1.0,0.0]))

Although this constructor is available, one should really not be creating
sparse matrices with stored zeros. A lot of routines assume no stored
zeros. Maybe we should not export SparseMatrixCSC?

—
Reply to this email directly or view it on
GitHubhttps://github.com//pull/5386/files#r8894990
.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of routines assume no stored zeros.

Do they run slower with stored zeros, or do they actually crash and burn? If the former, then I would agree with @mlubin; otherwise the routines for which stored zeros would be fatal should just trap any divide-by-zero errors and the like as they happen.

Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT the only way to make a sparse matrix with stored zeros is to call SparseMatrixCSC directly, so if nobody did that there would be no problem. @mlubin do you call it directly for performance reasons?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In JuMP we translate the constraint matrix into a SparseMatrixCSC in a single pass. Yes, we could filter out zeros here.

But I think the point is, sparse matrix formats are definitely not one-size-fits-all, so trying to be strict about having no non-zeros is just going to make some applications more difficult. For example, a common trick is to leave "gaps" between columns if it's possible that we may need to occasionally insert new elements. This could be implemented with a SparseMatrixCSC if zeros are accepted. If not, one would need to use a custom data structure and would instantly lose all of the functionality in Base that might be useful, such as sparse mat-vec products.

What's an example of a routine that crashes if explicit nonzeros are stored?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once you start doing linear algebra, you always have to check for small values and cancellations. An algorithm that fails with zero entries is likely also going to fail with 1e-50 entries.

Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would keeping track of the number of filled entries and how many of those are zero be an option? You'd have to check each inserted value to see if it is zero, but I feel like that might be a trivial cost in the face of the rest of the operation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure the extra complexity is worthwhile. When would one actually need the number of nonzero entries instead of the number of filled entries?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The dense nnz actually counts the number of nonzeros.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping track of the number of filled nonzeros is going to be expensive, and not practical. We already do not have good performance on sparse operations, and it would be good not to slow down further.

@test length(I) == length(J) == length(V) == 1