Add additional element-wise mathematical functions

[kgryte]

This PR

• adds specifications for additional element-wise mathematical functions.
• is derived from comparing API signatures across array libraries.
• the APIs are used by downstream libraries with at least some frequency.
• The addition of these APIs furthers parity with corresponding C APIs (C99) and those present in IEEE 754-2008.

Notes

• The list of APIs is as follows:

  • expm1: present in all analyzed array libraries
  • log1p: present in all analyzed array libraries
  • log2: not present in TensorFlow (except in experimental NumPy)
  • log10: not present in TensorFlow (except in experimental NumPy)
  • pow: not present in Dask array (or at least not in its docs)
  • sign: present in all analyzed array libraries
  • square: present in all analyzed array libraries

[rgommers]

square: present in all analyzed array libraries

square is a specialization of power, which is also not present yet. The latter also has a stronger justification - it corresponds to the ** operator. Can you add power as well?

[rgommers]

Thanks @kgryte. Adding these functions makes sense to me. Some minor textual comments.

[kgryte]

I've add pow (following C naming conventions as we've done elsewhere).

[kgryte]

I've also added rules for floating-point arithmetic. This PR should be good to go.

[rgommers]

pow: not present in Dask array (or at least not in its docs)

It's present, you can add it to array-api-comparison.

[rgommers]

Thanks @kgryte. LGTM, modulo the "financial application" thing

[asmeurer]

Since out has been removed, then presumably abs and pow are allowed to implemented only via the built-on and __abs__ and __pow__ (unfortunately, min and max cannot).

[rgommers]

Since out has been removed, then presumably abs and pow are allowed to implemented only via the built-on and __abs__ and __pow__ (unfortunately, min and max cannot).

I believe there's a statement somewhere already that all the different ways of spelling this must behave the same. If not, then we should indeed add it.

We shouldn't say how it should be implemented though, we try hard to stay away from that and only spec syntax and semantics - if they need to be 2 or 3 independent implementations with the same behavior, that's fine.

[kgryte]

@rgommers Updated. Should be good to go.

[rgommers]

@kgryte FYI I put in a PR to Dask to add power and ~8 other missing ufuncs. That's now deployed on https://docs.dask.org/en/latest/array-api.html, so you may want to update array-api-comparison.

[rgommers]

LGTM, in it goes. Thanks @kgryte

[kgryte]

@rgommers Thanks for the update on Dask. I'll post an issue on the array-api-comparision repo.