Also equivalent to the % operator, right?

Also add the equivalent for divmod(in, 1.):

modf : Return the fractional and integral parts of an array, element-wise.

I wonder if we should be using div, ldiv, and lldiv here?

Scrap that, apparently it's better to leave the compiler to it. Might be sensible to have a const @type@ quo = in1 / in2; line right beside this one though, just to help it out

Agreed, that is definitely clearer. Done.

You can use wrap_array_like here, right?

Yes, but I think it's actually clearer to call ArrayLike() separately in cases where we know the arity of the arguments

Also add the equivalent for divmod(in, 1.):

modf : Return the fractional and integral parts of an array, element-wise.

Note that See doc.ufuncs doesn't actually produce a link of any kind, so should probably not be there at all, to avoid furthering the myth that it works.

Once we merge #9026, we'll get those links for every ufunc anyway.

If you're mentioning floor division above, then presumably you should do so here too?

It puzzles me that operator.pow is a thing, but operator.divmod is not

All these are operators in the sense that they have a corresponding symbol. (Hopefully, we'll have a operator.matmul in here shortly...)

Good catch. In particular, operator.pow has two arguments, but pow has three

Nit: resulting should probably be in both places or neither

The quotient is the result of floor division, but the remainder is a by-product. So I think the current language makes sense (but I'm open to alternatives if you have a concrete suggestion).

I'm not convinced results and byproducts are disjoint sets, but I'm happy to leave this as is based on your rationale.

Perhaps before this loop, or even at the file level:

signs = {
    d: (+1,) if dt in np.typecodes['UnsignedInteger'] else (+1, -1)
    for d in dt
}

And then itertools.product(signs[dt1], signs[dt2]) below, which removes the continues

Actually, better would be, in the class level:

def _signs(self, dt):
    if dt in np.typecodes['UnsignedInteger']:
        return (+1,)
    else:
        return (+1, -1)

Constructing that dict is kinda clunky, and you'd end up repeating it over multiple tests

done

Probably worth pointing out that the builtin divmod now dispatches to this - I'm an idiot, you've already done this

And before release I'm going to gather all the new ufuncs into a New ufuncs section. There are enough of them in the 1.13 release to justify that.

Is there a reason we use mod here and not remainder? If mod is preferable, then should we reverse the alias, so that np.mod.__name__ == 'mod'?

I'd vote for just using remainder here.

Yeah, no particular reason for this. Switched to use remainder.

Can we add a reference from these functions back to divmod too?

The modf function comes from the C library and doesn't agree with the Python divmod for negative floats.

In [1]: np.modf(-1.5)
Out[1]: (-0.5, -1.0)

In [2]: divmod(-1.5, 1)
Out[2]: (-2.0, 0.5)

Also note the reversed output values.

updated

Darn, I'd missed that this was in two different files, which makes extracting it a little less useful. I guess this is still a minor improvement though

Can modf link to divmod as well?

Mention of the C library would be helpful: The C library ``modf`` function. Like ....

Isn't this what the modf docstring is for? :)

Not convinced the alignment of the colons buys anything here except extra spaces.

I was envisaging likening divmod(x, 1) to modf here, in the same way we do the reverse in divmod. If anything, this direction is more important to get the message across, since most users probably want the behaviour of divmod on negative values

Spoke too soon - missing parentheses here