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
Copy file name to clipboardExpand all lines: lib/node_modules/@stdlib/ndarray/input-casting-policies/README.md
+16-1Lines changed: 16 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,7 @@ var out = policies();
51
51
52
52
The output array contains the following policies:
53
53
54
-
-`none`: do not cast an input ndarray.
54
+
-`none`: no guidance on specific casting behavior. An input ndarray may or may not be cast depending on the needs of an implementation.
55
55
-`promoted`: cast an input ndarray to a promoted data type.
56
56
-`accumulation`: cast an input ndarray to a data type amenable to accumulation.
57
57
-`output`: cast an input ndarray to the data type of the output ndarray.
@@ -64,6 +64,17 @@ The output array contains the following policies:
64
64
65
65
<sectionclass="notes">
66
66
67
+
## Notes
68
+
69
+
- The following is some general guidance for the casting policies listed above:
70
+
71
+
-**none**: applies whenever an input ndarray casting behavior should be entirely left up to an implementation. For example, an implementation may choose to cast internally in order to take advantage of specialized algorithms operating on specific data types.
72
+
-**promoted**: applies whenever an input ndarray should be cast to the data type resolved from applying the rules of [type promotion][@stdlib/ndarray/promotion-rules] to an implementation's input and output ndarrays. For example, suppose an implementation is computing the sum and the data type of the input ndarray is `int32` and the data type of the output ndarray is `float32`. In this scenario, casting `int32` to `float32` is not desirable as not all `int32` values can be safely represented in `float32`, thus potentially leading to significant accumulated numerical error. Instead, we can promote `int32` to `float64`, compute the sum, and then downcast the result for more accurate summation.
73
+
-**accumulation**: applies whenever an input ndarray should be cast to a data type amenable to accumulation, irrespective of the output ndarray or other input ndarrays. For example, suppose an implementation is computing the sum and determining whether the sum passes a threshold, and further suppose that the data type of the input ndarray is `int8` and the data type of the output ndarray is `bool`. In this scenario, as `int8` has a small range of values, computing the sum has a high risk of overflow, rending the results potentially meaningless, and type promotion is not applicable. As such, an implementation may prefer to internally cast `int8` to a data type more amenable to accumulation, such as `int32`.
74
+
-**output**: applies whenever an input ndarray should always be cast to the data type of the output ndarray. This might apply whenever an implementation wraps a type homogeneous interface, such as those commonly found in BLAS/LAPACK routines.
75
+
76
+
- Whether an implementation supports a casting policy depends on the implementation. Supporting casting policies is mainly envisioned for generalized utilities wrapping lower-level APIs and needing to accommodate varied use cases (e.g., [`@stdlib/ndarray/base/unary-reduce-strided1d-dispatch`][@stdlib/ndarray/base/unary-reduce-strided1d-dispatch]). Exposing casting policies as part of user-facing APIs is generally not a good idea.
0 commit comments