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
mat: add Doer interface and implementations #126
Conversation
e594810
to
6b96e58
Compare
Cleaned up and added PTAL |
Can we find a better name than |
Please suggest a name. I have nothing better. |
How about |
WalkNZ sounds like an adventure tourism campaign. I don't like either of walk or reduce because of loading from other domains (walk is a graph theoretic thing and reduce sounds like it comes from mapreduce). How about DoNonZero, DoRowNonZero and DoColNonZero? |
The problem with |
I'd argue that Do and Call are synonyms when the parameter is a func. |
Okay. SGTM |
PTAL |
I've used "provably non-zero" instead of "filled". I don't like it much, so if you have a better suggestion, I'd happily change it. |
It should be "not provably zero". We don't have any elements that are provably non-zero |
I wonder if it's better that this call the function at the non-zero elements, rather than at the elements which are provably non-zero. First of all, the behavior is easier to understand. Second of all, it means this behavior works correctly for sparse matrices where often no elements are provably non-zero, but many elements will actually be non-zero. |
(and the change improves the important sparsity properties where a bunch of elements are known to be zero, so they don't have to be checked) |
(also the method name doesn't have to be changed :) ) |
I'm happy to call it "non-zero element", except that a band created by |
I understand that is the behavior now, but I'm suggesting the function is more generally useful if it doesn't call the function at all for zero elements. Meaning, for Code that relies on the "provably" part will have to do a type switch anyway, because you can't tell what "provably" means from the interface. In that light, I think it's better to not call at all for zero entries. |
OK. I can't do that today. I'll get back to this later. |
Was less than I thought - the tests were already written with only non-zero elements in the bands. |
mat/matrix_test.go
Outdated
|
||
var got float64 | ||
fn := func(i, j int, v float64) { | ||
got += v |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a comment to the effect of "this sets to the same value to test accessing"? I originally was thinking this was mutating the matrix to have new values for the subsequent tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
mat/matrix_test.go
Outdated
t.Errorf("unexpected Doer sum: got:%f want:%f", got, want) | ||
} | ||
|
||
got = 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also add a comment like "test that the sum over all the rows equals the sum over the matrix"? I was caught up a while on the statefulness of got
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
PTAL |
Also clean up some documentation and missing type checks related to tests for NonZeroDoers.
This is a proposal for an approach to optimising sparse or sparsish matrix accesses raised in #124 (comment)
Only 2eb65a2 is relevant to this PR and I'll revise the history of the PR when #95 is merged.Depends #95.