GrB_MINUS_INT8 interacts interestingly with implicit zero elements about graphblas HOT 8 CLOSED

from graphblas.

Say f(x,y) is a binary op (not a monoid). Then f (nothing,y) and f(x,nothing) are not defined; there is no identity value. The binary op is only applied on the intersection of the pattern of A and B, for both ewise add and ewise mult. The only difference with ewiseAdd is that it results in the set intersection of the pattern of A and B, where entries in A setminus B, and B setminus A, go directly to the output matrix C, bypassing the op.

from graphblas.

Right!
The lack of identity value in a binary operations means the one value just bypasses it. Then it makes sense that plus and minus produce the same result. Neat, thank you so much for explaning!

from graphblas.

I can be a bit surprising, I admit. It's something I noticed when I first started working on GraphBLAS.

It would be possible to consider a new kind of method, like eWiseAdd but with two extra GrB_Scalars, say anothing and bnothing. Then for an entry A(i,j) in A but not B, the computation would be C(i,j) = f (A(i,j), bnothing), and similarly for anothing. Then your anothing and bnothing would both be zero. But I haven't really considered that seriously yet. So far, its potential use seems only to come up in exactly this situation, with the MINUS operator and anothing = bnothing = zero.

For an operator like DIV, anothing might be zero and bnothing might be 1. Or something else entirely. These 2 values (anothing and bnothing) are not really properties of a binary function; they do not have have to be identity values. In particular, if f(x,y) = x-y, what should be the value of x if the op is applied to f(nothing,y)? In your case, you would like to have nothing==0. But I think that's not the only answer. f(x,y)=x-y doesn't have an identity value i where x = f(x,i) = f(i,x) for all x. Since GraphBLAS deals with many many operators, this lack means there can't be an implied value i for all ops.

There are many other cases where "the entry not there" is +inf, 1, -inf, 42, or whatever. It depends on the semiring the matrix "lives" in, but in fact a GrB_Matrix can bounce around from semiring to semiring, and the implicit value of "the entry that is not there" changes.

from graphblas.

In contrast, when dealing with sparse matrices in MATLAB, if you write C = A-B, you expect to get the answer MATLAB would get. For MATLAB, any entry not present in a sparse matrix is zero, so I follow that rule when overloading the C=A-B syntax. In the GraphBLAS/GraphBLAS/@GrB/minus.m function, which MATLAB calls for A-B when either A or B are @GRB objects, I do this:

function C = minus (A, B)
%MINUS sparse matrix subtraction, C = A-B.
% C = A-B subtracts the two matrices A and B.  If A and B are matrices,
% the pattern of C is the set union of A and B.  If one of A or B is a
% scalar, the scalar is expanded into a full matrix the size of the
% other matrix, and the result is a full matrix.
%
% See also GrB.eadd, GrB/plus, GrB/uminus.
...
type = gboptype (gbtype (A), gbtype (B)) ;
C = GrB (gb_eadd (A, '+', gbapply (['-.' type], B))) ;

It's very different from a plain eWiseAdd. In particular, this minus function does what you would want, by computing C=A+(-B). In addition, eWiseAdd for a scalar plus a matrix is not defined in GraphBLAS as an intrinsic operation, but this minus function can handle that case (that is done inside gb_eadd).

from graphblas.

However, when doing C = GrB.eadd (A, '-', B) in MATLAB, I return the GraphBLAS computation of GrB_eWiseAdd (C, ... GrB_MINUS_type, A, B, ...), because with GrB.eadd, the MATLAB user is explicitly asking for the GraphBLAS result, not the MATLAB result.

from graphblas.

Right. So because monoids and by extension element-wise addition assume associativity of operators, element-wise subtraction can't really be done the same way as in, say, MATLAB.
Would a possible addition to the standard, that maybe doesn't go against the philosphy, be to allow A, B or both to have a unary operator applied to them as part of the element-wise addition? Or perhaps that would just add too much confusion and complexity for what you say is a somewhat narrow use-case. I'm not sure it would actually make the logic easier to parse than just using "apply" either, so in that case the "element-wise add"-like method but with non-associative operators and/or nothing-values you suggested might be better.

from graphblas.

That's another approach, but it starts to get really complicated. It would be slow to have 3 ops: one unary op for A, one for B, and a binary op for the intersection. The reason it would be slow is because of the combinatorial explosion of possible cases. To make this fast, I create versions of GrB_mxm for each builtin semiring, versions of eWiseAdd for each builtin binary op, and so on. Already, that is a large number of functions (one per binary op): 388 of them in fact. If I add all combinations of those 388 with about 8 unary ops for ints and bools, I'd end up with 388 times 8 times 8 functions, or nearly 25 thousand functions. And this excludes any typecasting. For floating point, I have dozens of unary ops, so it would be even more. That's just impossible.

from graphblas.