Update image paths to shared _static/

Author: honno

spec/2021.12/API_specification/data_types.rst

@@ -72,7 +72,7 @@ IEEE 754 double-precision (64-bit) binary floating-point number (see IEEE 754-20
 
    ``complex64`` and ``complex128`` data types are expected to be included in the next version of this standard and to have the following casting rules (will be added to :ref:`type-promotion`):
 
-   .. image:: /_static/images/dtype_promotion_complex.png
+   .. image:: ../../_static/images/dtype_promotion_complex.png
 
    See `array-api/issues/102 <https://github.com/data-apis/array-api/issues/102>`_ for more details
 

spec/2021.12/API_specification/type_promotion.rst

@@ -7,7 +7,7 @@ Type Promotion Rules
 
 Type promotion rules can be understood at a high level from the following diagram:
 
-.. image:: /_static/images/dtype_promotion_lattice.png
+.. image:: ../../_static/images/dtype_promotion_lattice.png
     :target: Type promotion diagram
 
 *Type promotion diagram. Promotion between any two types is given by their join on this lattice. Only the types of participating arrays matter, not their values. Dashed lines indicate that behavior for Python scalars is undefined on overflow. Boolean, integer and floating-point dtypes are not connected, indicating mixed-kind promotion is undefined.*

spec/2021.12/assumptions.md

@@ -35,7 +35,7 @@ such a coupling. Facilitation support of multiple array types in downstream
 libraries is an important use case however, the assumed dependency structure
 for that is:
 
-![dependency assumptions diagram](_static/images/dependency_assumption_diagram.png)
+![dependency assumptions diagram](../_static/images/dependency_assumption_diagram.png)
 
 Array libraries may know how to interoperate with each other, for example by
 constructing their own array type from that of another library or by shared

spec/2021.12/purpose_and_scope.md

@@ -111,7 +111,7 @@ Furthermore, meta-topics included in this standard include:
 The concrete set of functionality that is in scope for this version of the
 standard is shown in this diagram:
 
-![Scope of array API](_static/images/scope_of_array_API.png)
+![Scope of array API](../_static/images/scope_of_array_API.png)
 
 
 **Goals** for the API standard include:

spec/draft/API_specification/type_promotion.rst

@@ -7,7 +7,7 @@ Type Promotion Rules
 
 Type promotion rules can be understood at a high level from the following diagram:
 
-.. image:: /_static/images/dtype_promotion_lattice.png
+.. image:: ../../_static/images/dtype_promotion_lattice.png
     :target: Type promotion diagram
 
 *Type promotion diagram. Promotion between any two types is given by their join on this lattice. Only the types of participating arrays matter, not their values. Dashed lines indicate that behavior for Python scalars is undefined on overflow. Boolean, integer and floating-point dtypes are not connected, indicating mixed-kind promotion is undefined.*

spec/draft/assumptions.md

@@ -35,7 +35,7 @@ such a coupling. Facilitation support of multiple array types in downstream
 libraries is an important use case however, the assumed dependency structure
 for that is:
 
-![dependency assumptions diagram](_static/images/dependency_assumption_diagram.png)
+![dependency assumptions diagram](../_static/images/dependency_assumption_diagram.png)
 
 Array libraries may know how to interoperate with each other, for example by
 constructing their own array type from that of another library or by shared

spec/draft/purpose_and_scope.md

@@ -111,7 +111,7 @@ Furthermore, meta-topics included in this standard include:
 The concrete set of functionality that is in scope for this version of the
 standard is shown in this diagram:
 
-![Scope of array API](_static/images/scope_of_array_API.png)
+![Scope of array API](../_static/images/scope_of_array_API.png)
 
 
 **Goals** for the API standard include: