Issues with array creation functions

Some issues I noticed in the array creation functions from adding tests to the test suite:

arange

• stop and step should not be keyword-only (this was also mentioned at https://github.com/data-apis/array-api/issues/85)
• Does not specify the behavior if stop or start are out of range for the dtype
• Says “If dtype is None, the output array data type must be the default floating-point data type.” I think the default for arange should be int if all the arguments are integers.
• step cannot be 0.
• The function is only defined for numeric dtypes (https://github.com/data-apis/array-api/issues/98)
• “The length of the output array must be ceil((stop-start)/step)” should be caveated (stop and step provided, stop >= start for step > 0 and stop <= start for step < 0)

eye

• May be worth explicitly saying elements with index i, j should be 1 if j - i = k and 0 otherwise.
• The function is only defined for numeric dtypes (https://github.com/data-apis/array-api/issues/98)

full (and full_like)

• Says “If dtype is None, the output array data type must be the default floating-point data type.” I think the default should be a corresponding dtype to the input value (we don’t have a notion of a “default” integer dtype).

linspace

• It’s a bit ambiguous whether it actually says this right now, but I think the stop value should not be required to be included (when endpoint=True). Consider

>>> np.linspace(0, 9288674231451855, 2, dtype=np.int64)
array([               0, 9288674231451856])

The stop value is different from what is given because of floating point loss of precision when computing the linspace.

[shoyer]

A few other suggestions:

• To resurface concerns from https://github.com/data-apis/array-api/issues/85:
  • Why allow shape arguments to be passed as keyword arguments, too? This is a pretty unambiguous name, and code can be clearer when it uses names.
  • Likewise, could num be allowed as a keyword for linespace and fill_value be allowed as a keyword for full/full_like?
• empty and empty_like may not necessarily make sense for libraries that do not support mutation (e.g., JAX, Dask, TensorFlow) It might be worth calling this out.

[rgommers]

That looks like a clear bug, not even a subtle one. The integer start point and step size calculation should just not use floats.