I'm not proposing to add the operators as that are already there. I believe Micheal added them a couple of years ago. Look in ov.h(enum compound_binary_ops). The operators

    op_trans_mul,
    op_mul_trans,
    op_herm_mul,
    op_mul_herm,
    op_trans_ldiv,
    op_herm_ldiv,
    op_el_not_and,
    op_el_not_or,
    op_el_and_not,
    op_el_or_not,
    num_compound_binary_ops,

are already defined and used for full matrices. I have a first try of the operators op_el_not_and, op_el_not_or, op_el_and_not and op_el_or_not written for scalar-sparse, sparse-scalar, full-sparse, sparse-full and sparse-sparse with the exception of op_el_not_or and op_el_or_not for sparse-sparse binary operators as I can't see a way of efficently implementing that.I just need to debug it as it doesn't quite work yet ;-)

D.

PS: I was probably optomistic for the effort needed to implement the other compound operators though UMFPACK and CHOLMOD seem to natively support the transpose and hermitian version of the solvers

I was proposing a new operator, but only because I didn't know it was possible to specially handle a recognized sequence.  Yes, of course it would be better to handle & and ~ together specially if possible (since it may optimize existing code).

But, I still think it is important to have the functional equivalent so that it can be used with bsxfun (that is, once http://savannah.gnu.org/bugs/?41441 is resolved)

Do we want to also provide the functional equivalents such as and_not, or_not in the same way that we provide functional forms of the operators 'and' and 'or'.  Or is it enough for people to call

and (a, not(b))

In pretty much every project I write, I always end up writing an andnot.m

function [r] = andnot(a,b)
  a(logical(b)) = false
  r = logical(a)
end

It comes up consistently with logical operations and if you're dealing with sparse matrices, you can't say a & ~b without invoking an OOM