mat: add Doer interface and implementations

[kortschak]

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.

[kortschak]

Cleaned up and added SymBandDense implementation.

PTAL

[btracey]

Can we find a better name than Do? In particular, the key feature of this is that it only operates on the "non-provably zero" region. The name should reflect that somehow.

[kortschak]

Please suggest a name. I have nothing better.

[btracey]

How about WalkNZ? It iterates over the (provably) non-zero entries. Or, ReduceNZ, because reduce will frequently be the intended purpose?

[kortschak]

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?

[btracey]

The problem with Do is it means nothing. The method iterates over the non-zero entries and calls the function. CallNonZero? IterNonZero?

[kortschak]

I'd argue that Do and Call are synonyms when the parameter is a func.

[btracey]

Okay. SGTM

[kortschak]

PTAL

[kortschak]

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.

[btracey]

It should be "not provably zero". We don't have any elements that are provably non-zero

[btracey]

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.

[btracey]

(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)

[btracey]

(also the method name doesn't have to be changed :) )

[kortschak]

I'm happy to call it "non-zero element", except that a band created by mat.NewBand(3, 3, 0, 0, make([]float64, 3)) is all zero, but the function will be called with {0, 0, 0}, {1, 1, 0} and {2, 2, 0}. This is why I used "filled" before.

[btracey]

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 mat.NewBand(3, 3, 0, 0, make([]float64, 3)), the function isn't called at all. This behavior is much more understandable from an interface perspective.

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.

[kortschak]

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 non-zero entries.

OK. I can't do that today. I'll get back to this later.

[kortschak]

Was less than I thought - the tests were already written with only non-zero elements in the bands.

[btracey]

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.

[kortschak]

Done

[btracey]

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.

[kortschak]

Done

[kortschak]

PTAL