You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The specification for linspace is currently underspecified for integer output array dtypes. Namely, the specification is silent concerning the following scenarios:
what should happen start and stop are floating-point numbers with non-integral values and dtype is an integer data type?
linspace( 1.4, 100.75, num=50, dtype="int32" )
what should happen when start and stop are Python ints and dtype is an integer data type, but the computed spacing between adjacent elements is not an integral value?
linspace( 0, 10, num=100, dtype="int32" )
For both scenarios, one option is to add a note to the specification stating that behavior in these instances is implementation-dependent--a conforming implementation would be free to round/truncate, raise an exception, or something else.
Otherwise, for (1), this could be explicitly disallowed in the specification; i.e., if start and stop are floating-point, then only floating-point dtypes are allowed.
For (2), this is somewhat trickier to resolve as the spacing between adjacent elements is an implicit variable which users may find difficult to reason about without explicitly computing the spacing and determining whether, say, a specific argument combination might trigger an exception. However, we could opt to be pedantic and only allow integer dtypes when start, stop, and the computed spacing are all integer values. Otherwise, an exception should be raised.
A final option is that linspace could be restricted to only floating-point data types. If a user wants to return an output array with an integer data type, they could use arange and explicitly specify the step.
Prior Art
NumPy's linspace floors non-integral values when the output array data type is an integer dtype.
MXNet's np.linspace attempts to match NumPy's API.
Observations
In general, returning non-evenly spaced values due to integer rounding seems generally undesired and not particularly useful. If the specification was more restrictive, users wanting to replicate the current functionality of NumPy and PyTorch could generate a floating-point output array using linspace and then perform an explicit cast to the desired integer data type.
The text was updated successfully, but these errors were encountered:
This issue was discussed during the consortium meeting on 2022-02-17. The general consensus is that the primary intended use case of linspace is for floating-point output dtypes. While array libraries, such as NumPy, may have historical reasons for supporting integer output dtypes, other APIs, such as arange, may be better suited for generating integer arrays.
Accordingly, the recommendation is to update the specification to recommend only floating-point output data types for linspace, while allowing conforming implementations to keep support for integer data types should they have a compelling reason to do so. For those libraries choosing to support integer output data types, behavior is implementation-defined.
The specification for
linspace
is currently underspecified for integer output array dtypes. Namely, the specification is silent concerning the following scenarios:what should happen
start
andstop
are floating-point numbers with non-integral values anddtype
is an integer data type?what should happen when
start
andstop
are Pythonint
s anddtype
is an integer data type, but the computed spacing between adjacent elements is not an integral value?For both scenarios, one option is to add a note to the specification stating that behavior in these instances is implementation-dependent--a conforming implementation would be free to round/truncate, raise an exception, or something else.
Otherwise, for (1), this could be explicitly disallowed in the specification; i.e., if
start
andstop
are floating-point, then only floating-pointdtype
s are allowed.For (2), this is somewhat trickier to resolve as the spacing between adjacent elements is an implicit variable which users may find difficult to reason about without explicitly computing the spacing and determining whether, say, a specific argument combination might trigger an exception. However, we could opt to be pedantic and only allow integer
dtype
s whenstart
,stop
, and the computed spacing are all integer values. Otherwise, an exception should be raised.A final option is that
linspace
could be restricted to only floating-point data types. If a user wants to return an output array with an integer data type, they could usearange
and explicitly specify thestep
.Prior Art
NumPy's
linspace
floors non-integral values when the output array data type is an integerdtype
.TensorFlow's
linspace
only supports floating-point data types.PyTorch's
linspace
floors non-integral values when the output array data type is an integerdtype
.MXNet's
np.linspace
attempts to match NumPy's API.Observations
In general, returning non-evenly spaced values due to integer rounding seems generally undesired and not particularly useful. If the specification was more restrictive, users wanting to replicate the current functionality of NumPy and PyTorch could generate a floating-point output array using
linspace
and then perform an explicit cast to the desired integer data type.The text was updated successfully, but these errors were encountered: