Do you need a /*check_mem_overlap=*/=true here? What if result is self or other?

there will be no problem if result is self or other, but problem might occur when view of tensor overlap with other view, so check_mem_overlap is definitely needed here.

Same check_mem_overlap question as above.

What happens if a == b == inf or -inf?

Same question when a == b == +/- inf

@albanD Take a look, would you?

The formula looks good.
For testing, you want to add an entry here to make sure the gradients will be properly checked.

@albanD What's our plan for testing the derivatives of new functions like this?

I am also curious.

Don't import NumPy, instead assert TEST_NUMPY

You should move these tests into TestTorchDeviceType so you can run them on both the CPU and GPU. Right now you're just testing the CPU. Then see the helper function "_np_compare," which you can use to simplify your tests, and the @dtypes decorator so you can test multiple dtypes. Since you're only enabling logaddexp on float types, you should test at least torch.long (assert throws RuntimeError), torch.float32, and torch.complex64 (assert throws RuntimeError). That way if someone implements logaddexp for complex64, for example, they'll know to update this test.

_np_compare works by taking values to test at. Your value generation is OK but you should add some more "interesting" values like -math.pi, 0, and math.pi, as well as extremal values like nan, -inf, and inf.

This comment is a little misleading. Maybe something like: "the tensor whose exponential is added to the exponential of input before the log is taken"?

your suggestion is too verbose, may be I should just delete it and let the generator generate the second input tensor for it?

Sure.

Same language/doc changes here as with the above.