docs: update language

Author: kgryte

src/array_api_stubs/_draft/set_functions.py

@@ -31,13 +31,13 @@ def unique_all(x: array, /) -> Tuple[array, array, array, array]:
     Notes
     -----
 
-    -   The order of unique elements returned by this function is left unspecified and thus implementation-dependent. As a consequence, element order **may** vary between implementations.
+    -   The order of unique elements returned by this function is unspecified and thus implementation-defined. As a consequence, element order **may** vary between implementations.
 
     -   Uniqueness **should** be determined based on value equality (see :func:`~array_api.equal`). For input arrays having floating-point data types, value-based equality implies the following behavior.
 
         -   As ``nan`` values compare as ``False``, ``nan`` values **should** be considered distinct.
         -   As complex floating-point values having at least one ``nan`` component compare as ``False``, complex floating-point values having ``nan`` components **should** be considered distinct.
-        -   As ``-0`` and ``+0`` compare as ``True``, signed zeros **should not** be considered distinct, and the corresponding unique element **may** be implementation-dependent (e.g., an implementation **may** choose to return ``-0`` if ``-0`` occurs before ``+0``).
+        -   As ``-0`` and ``+0`` compare as ``True``, signed zeros **should not** be considered distinct, and the corresponding unique element **may** be implementation-defined (e.g., an implementation **may** choose to return ``-0`` if ``-0`` occurs before ``+0``).
 
         As signed zeros are not distinct, using ``inverse_indices`` to reconstruct the input array is not guaranteed to return an array having the exact same values.
 
@@ -76,13 +76,13 @@ def unique_counts(x: array, /) -> Tuple[array, array]:
     Notes
     -----
 
-    -   The order of unique elements returned by this function is left unspecified and thus implementation-dependent. As a consequence, element order **may** vary between implementations.
+    -   The order of unique elements returned by this function is unspecified and thus implementation-defined. As a consequence, element order **may** vary between implementations.
 
     -   Uniqueness **should** be determined based on value equality (see :func:`~array_api.equal`). For input arrays having floating-point data types, value-based equality implies the following behavior.
 
         -   As ``nan`` values compare as ``False``, ``nan`` values **should** be considered distinct.
         -   As complex floating-point values having at least one ``nan`` component compare as ``False``, complex floating-point values having ``nan`` components **should** be considered distinct.
-        -   As ``-0`` and ``+0`` compare as ``True``, signed zeros **should not** be considered distinct, and the corresponding unique element **may** be implementation-dependent (e.g., an implementation **may** choose to return ``-0`` if ``-0`` occurs before ``+0``).
+        -   As ``-0`` and ``+0`` compare as ``True``, signed zeros **should not** be considered distinct, and the corresponding unique element **may** be implementation-defined (e.g., an implementation **may** choose to return ``-0`` if ``-0`` occurs before ``+0``).
 
         Each ``nan`` value and each complex floating-point value having a ``nan`` component **should** have a count of one, while the counts for signed zeros **should** be aggregated as a single count.
 
@@ -119,13 +119,13 @@ def unique_inverse(x: array, /) -> Tuple[array, array]:
     Notes
     -----
 
-    -   The order of unique elements returned by this function is left unspecified and thus implementation-dependent. As a consequence, element order **may** vary between implementations.
+    -   The order of unique elements returned by this function is unspecified and thus implementation-defined. As a consequence, element order **may** vary between implementations.
 
     -   Uniqueness **should** be determined based on value equality (see :func:`~array_api.equal`). For input arrays having floating-point data types, value-based equality implies the following behavior.
 
         -   As ``nan`` values compare as ``False``, ``nan`` values **should** be considered distinct.
         -   As complex floating-point values having at least one ``nan`` component compare as ``False``, complex floating-point values having ``nan`` components **should** be considered distinct.
-        -   As ``-0`` and ``+0`` compare as ``True``, signed zeros **should not** be considered distinct, and the corresponding unique element **may** be implementation-dependent (e.g., an implementation **may** choose to return ``-0`` if ``-0`` occurs before ``+0``).
+        -   As ``-0`` and ``+0`` compare as ``True``, signed zeros **should not** be considered distinct, and the corresponding unique element **may** be implementation-defined (e.g., an implementation **may** choose to return ``-0`` if ``-0`` occurs before ``+0``).
 
         As signed zeros are not distinct, using ``inverse_indices`` to reconstruct the input array is not guaranteed to return an array having the exact same values.
 
@@ -159,13 +159,13 @@ def unique_values(x: array, /) -> array:
     Notes
     -----
 
-    -   The order of unique elements returned by this function is left unspecified and thus implementation-dependent. As a consequence, element order **may** vary between implementations.
+    -   The order of unique elements returned by this function is unspecified and thus implementation-defined. As a consequence, element order **may** vary between implementations.
 
     -   Uniqueness **should** be determined based on value equality (see :func:`~array_api.equal`). For input arrays having floating-point data types, value-based equality implies the following behavior.
 
         -   As ``nan`` values compare as ``False``, ``nan`` values **should** be considered distinct.
         -   As complex floating-point values having at least one ``nan`` component compare as ``False``, complex floating-point values having ``nan`` components **should** be considered distinct.
-        -   As ``-0`` and ``+0`` compare as ``True``, signed zeros **should not** be considered distinct, and the corresponding unique element **may** be implementation-dependent (e.g., an implementation **may** choose to return ``-0`` if ``-0`` occurs before ``+0``).
+        -   As ``-0`` and ``+0`` compare as ``True``, signed zeros **should not** be considered distinct, and the corresponding unique element **may** be implementation-defined (e.g., an implementation **may** choose to return ``-0`` if ``-0`` occurs before ``+0``).
 
     .. versionchanged:: 2022.12
        Added complex data type support.