(±1)^-n should not throw a DomainError

[stevengj]

Since this has an integer result, no need to throw an exception.

[ivarne]

What does @JeffBezanson think about the hidden copy(x) in this case? Is it (un)expected as it apparently was with fill?

[stevengj]

@ivarne, I used copy(x) because that is what power_by_squaring already does in the p == 1 case; I don't have strong opinions about it, but both cases should clearly be consistent.

[stevengj]

The travis failure looks unrelated to me.

[JeffBezanson]

It doesn't bother me. First, I'm not sure copy(x) would ever do anything when x==1 is true. Perhaps it should use x == one(x) instead?

Second, I don't think anything is expected about the aliasing behavior of x^p. It would be quite crazy to rely on that returning the same x object in some cases. In contrast, it's reasonable to assume that fill(x, n) reuses the same x object, because (1) there are legitimate uses for arrays of many references to the same object, (2) fill is a structural kind of operation that doesn't transform x.

However, calling copy in ^ would ideally be unnecessary. Those who use mutation need to be careful, not everybody else. But for this function it really doesn't matter.

[stevengj]

@JeffBezanson, changed to x == one(x).

[StefanKarpinski]

Comparing x == 1 should suffice here. If you want to make the comparison is between like types, it may make sense to construct u = one(x) only once and then also return that instance since this is faster for numeric types that do actually require allocation (e.g. BigInt, BigFloat, etc.). However, it seems like not constructing this object at all would be better in such cases.

[ivarne]

When would there be a difference between x == 1 and x == one(x), apart from the efficiency loss associated with initializing a new object?

It might be the case that typeof(x) hasn't defined integer comparisons, but it seems quite dubious to me to have one(::X), but not ==(::X, ::Int).

[StefanKarpinski]

There shouldn't be a difference but of course people can define these functions to do whatever they want.

[JeffBezanson]

This function was originally written to also handle matrices, where one(x) is quite different.

[StefanKarpinski]

Ah, yes. Good point. In that case you definitely don't want to construct it twice.

[stevengj]

Note that this function is never actually called for matrices when the power is negative, as far as I can tell. (And for general matrices, a DomainError is the wrong fallback in any case.). But I will modify it to call one only once just to be on the safe side.

[ivarne]

Just in case anyone else is as confused as me.

one() is defined as multiplicative identity, so for arrays it is the identity matrix.

[stevengj]

I'm less concerned about matrices (which follow a different code branch for negative powers) than I am about other user-defined fields where one(T) != 1.

[JeffBezanson]

Can be rebased and merged I think.

[stevengj]

rebased

[ararslan]

Superceded by #18342?

[stevengj]

Ah right, I forgot I had already filed a PR for this.