Type promotion tests

[asmeurer]

Here is the spec for type promotion rules: https://github.com/data-apis/array-api/blob/master/spec/API_specification/type_promotion.md

Questions:

• As with Broadcasting tests #1, how do I create inputs for the tests? I didn't see any specification on how to create arrays or how to specify dtypes.

• Do I read the document correctly in that all the listed dtypes are required to be implemented?

• The bullet points at the bottom specify different semantics for zero-dimensional arrays and scalars. Is the distinction between these two spelled out somewhere? As far as I know, NumPy distinguishes these types but they mostly behave the same (and they seem to both participate in type promotion).

[rgommers]

• As with Broadcasting tests #1, how do I create inputs for the tests? I didn't see any specification on how to create arrays or how to specify dtypes.

Yes we need to write those sections still. You can assume numpy names for dtypes and array creation functions (don't use np.random ones though, random number generation may not be in the core).

Do I read the document correctly in that all the listed dtypes are required to be implemented?

Yes indeed. That's why the set of dtypes is quite conservative - all libraries have the listed dtypes.

The bullet points at the bottom specify different semantics for zero-dimensional arrays and scalars. Is the distinction between these two spelled out somewhere? As far as I know, NumPy distinguishes these types but they mostly behave the same (and they seem to both participate in type promotion).

I think those two bullet points are a complete specification (the first one just emphasizes that 0-D arrays are not special - they're just arrays). NumPy's rules are much more complicated. Scalars in the spec are Python scalars, the NumPy "array scalars" are not a thing.

[asmeurer]

Scalars in the spec are Python scalars

OK, that's a bit confusing, especially since Python ints don't fit any of the given dtypes. I would use the word "native Python types" rather than scalars.

And just to clarify then, what is the spec behavior on Python scalars? Is it implementation dependent? Should a Python float always cast like a float64? Should int cast to some int type, assuming it is small enough? The bullet point seems to imply that they should give an error in all cases. Is that really intended?

[rgommers]

And just to clarify then, what is the spec behavior on Python scalars? Is it implementation dependent? Should a Python float always cast like a float64? Should int cast to some int type, assuming it is small enough? The bullet point seems to imply that they should give an error in all cases. Is that really intended?

Native types should never upcast. That is consistent with what libraries do now I believe. (EDIT: modulo the "no mixed types below)

The main thing that isn't specified well is what happens for dtypes not present in the table. Most importantly, mixed float/int tables are left out. Those are all inconsistently implemented: TensorFlow raises, PyTorch has (e.g.) float32 + int64 -> float32, NumPy is more aggressive in upcasting and returns float64. Hence it was decided to disallow that - raise an exception and make the user do an explicit cast.

@kgryte we have that discussion in the meeting minutes, but I'm thinking we should add both the decision and the rationale to the spec, maybe in a note box that can fold out (the theme has those). WDYT?

[kgryte]

@rgommers I don't know if we ever came to a decision regarding dtypes which are not specified in the tables. Currently, it is implementation-dependent, but I cannot recall whether we came to consensus on whether, e.g., this should remain the case or whether these situations should be "disallowed"/trigger an exception.

Regardless, agreed that we should add a section explaining the rationale for not including every combination and why we have not yet sought to standardize behavior in this particular circumstance.

[kgryte]

@asmeurer See here for likely array creation APIs. I should have a PR up for these within the next day or so.

[rgommers]

@rgommers I don't know if we ever came to a decision regarding dtypes which are not specified in the tables. Currently, it is implementation-dependent, but I cannot recall whether we came to consensus on whether, e.g., this should remain the case or whether these situations should be "disallowed"/trigger an exception.

Yes you are totally right, don't know what I was thinking when I wrote that. If we say "must raise an exception", that is standardizing it.

[asmeurer]

What's the best way to create empty arrays (arrays with 0 in their shape)? empty isn't on that list. Should it just be array([]).reshape(shape)? It would be nice if array([], shape=shape) worked, but it doesn't in NumPy (numpy/numpy#16665) and I don't know if it does in any of the other libraries.

[rgommers]

np.ones((4,2,0), dtype=np.float64) should do it.

[rgommers]

Interesting that empty isn't on it, I had expected it to be. It may end up in the spec anyway, but for this purpose it doesn't matter, ones, zeros, or full all do the same thing if one dimension is size 0.

[asmeurer]

Native types should never upcast. That is consistent with what libraries do now I believe. (EDIT: modulo the "no mixed types below)

I guess I'm still very confused by what is meant here. As far as I can tell NumPy treats int the same as int64 and float the same as float64:

>>> 1 + np.int64(1)
2
>>> type(1 + np.int16(1))
<class 'numpy.int64'>
>>> type(1 + np.int8(1))
<class 'numpy.int64'>
>>> type(1 + np.int16(1))
<class 'numpy.int64'>
>>> type(1 + np.int32(1))
<class 'numpy.int64'>
>>> type(1 + np.int64(1))
<class 'numpy.int64'>

>>> 1.0 + np.float64(1.0)
2.0
>>> type(1.0 + np.float32(1.0))
<class 'numpy.float64'>
>>> type(1.0 + np.float64(1.0))
<class 'numpy.float64'>

If the int doesn't fit in the type it gives an int64, and if it doesn't fit in that it gives an int:

>>> 2**10 + np.int8(1)
1025
>>> type(2**10 + np.int8(1))
<class 'numpy.int64'>
>>> 2**100 + np.int64(1)
1267650600228229401496703205377
>>> type(2**100 + np.int64(1))
<class 'int'>

[rgommers]

Those are all "scalar + scalar". I thought you meant "scalar + array", which is the interesting case.

This type of thing, np.float64(1.0), gives array scalars - those do not exist in other array libraries, and are largely considered a mistake for numpy. So they won't be in the spec, no need to worry about them.

Example:

In [2]: a = torch.float64(1.5)                                                
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-d09d5b5a50e6> in <module>
----> 1 a = torch.float64(1.5)

TypeError: 'torch.dtype' object is not callable

[rgommers]

So all there is is Python int/float/bool, and arrays with the dtypes that are in scope.

[asmeurer]

Are shape () arrays not part of the spec? I didn't see anything about that. In NumPy shape () arrays seem to behave the same as "array scalars" in my examples, with the exception of 2**10 + np.ones((), dtype=np.int64) which gives a result of 1025 of dtype int64. My understanding was that shape () arrays basically are scalar arrays, and should more or less behave the same as "dtype scalars" in NumPy, and in the few places there are differences, the spec should focus on the shape () array behavior. From what I can tell, int + array acts like int64(int) + array and float + array acts like float64(float) + array.

[rgommers]

Are shape () arrays not part of the spec?

Yes they are, but those are different from your examples. You'd construct them with np.array(1.5, dtype=np.float64), and they'd have type ndarray rather than a dtype instance.