Pop quiz: what do y'all think x - y will do (or should do) when x and y both have unsigned integer dtypes? Similarly, what about with -x?

I'm assuming you're hinting at overflows? If so, then perhaps we should follow numpy's style, which is to assume modular arithmetic and in so doing ignore overflows.

Yup, that's exactly right. The result stays an unsigned integer. This follows numpy rules.

I'm not 100% sold on the API

def ewise_union(self, other, op, left_default, right_default):

@jim22k what do you think?

I like the ordering, but the names left_default and right_default leave a lot to be desired. Maybe we should think of them as fill values rather than defaults. What do you think of lfill and rfill? I'm all about brevity if we don't lose too much clarity in the names.

I don't like rfill and lfill.

How about default, which may be a single scalar or an iterable with two items? I suspect it may be common to use the same value for both the left and the right.

btw, SuiteSparse:GraphBLAS calls these alpha and beta.

An even funkier spelling that is both concise and convenient could be:

def ewise_union(self, other, op, *defaults):

where defaults could be length 1 or 2 (or 0 if we ever want a default value).

Okay, I think this (and all my current PRs) is ready pending a final decision on function signature.

Current options:

1. def ewise_union(self, other, op, left_default, right_default):
2. def ewise_union(self, other, op, left_default, right_default=None):
3. def ewise_union(self, other, op, lfill, rfill):
4. def ewise_union(self, other, op, left, right):
5. def ewise_union(self, other, op, alpha, beta):
6. def ewise_union(self, other, op, default):
7. def ewise_union(self, other, op, *defaults):

My top two choices are 1 and 2.

Merging as is. @jim22k we can continue discussing the function signature and make changes before releasing if necessary.