Deploy: 0cd4bdf

Author: array-api-bot

2021.12/_sources/extensions/linear_algebra_functions.rst.txt

@@ -48,8 +48,8 @@ Accordingly, the standardization process affords the opportunity to reduce inter
 
     In general, interfaces should avoid polymorphic return values (e.g., returning an array **or** a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:
 
-    -   ``eig``: computing both eigenvalues and eignvectors.
-    -   ``eigvals``: computing only eigenvalues.
+    -   ``eigh``: computing both eigenvalues and eigenvectors.
+    -   ``eigvalsh``: computing only eigenvalues.
 
 4.  **Implementation agnosticism**: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.
 

2021.12/extensions/linear_algebra_functions.html

@@ -374,8 +374,8 @@ <h2 id="design-principles">Design Principles<a class="headerlink" href="#design-
 <li><p><strong>Return values</strong>: if an interface has more than one return value, the interface should return a namedtuple consisting of each value.</p>
 <p>In general, interfaces should avoid polymorphic return values (e.g., returning an array <strong>or</strong> a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:</p>
 <ul class="simple">
-<li><p><code class="docutils literal notranslate"><span class="pre">eig</span></code>: computing both eigenvalues and eignvectors.</p></li>
-<li><p><code class="docutils literal notranslate"><span class="pre">eigvals</span></code>: computing only eigenvalues.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigh</span></code>: computing both eigenvalues and eigenvectors.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigvalsh</span></code>: computing only eigenvalues.</p></li>
 </ul>
 </li>
 <li><p><strong>Implementation agnosticism</strong>: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.</p>

2021.12/searchindex.js

@@ -51,8 +51,8 @@ Accordingly, the standardization process affords the opportunity to reduce inter
 
     In general, interfaces should avoid polymorphic return values (e.g., returning an array **or** a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:
 
-    -   ``eig``: computing both eigenvalues and eignvectors.
-    -   ``eigvals``: computing only eigenvalues.
+    -   ``eigh``: computing both eigenvalues and eigenvectors.
+    -   ``eigvalsh``: computing only eigenvalues.
 
 4.  **Implementation agnosticism**: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.
 

2022.12/_sources/extensions/linear_algebra_functions.rst.txt

@@ -378,8 +378,8 @@ <h2 id="design-principles">Design Principles<a class="headerlink" href="#design-
 <li><p><strong>Return values</strong>: if an interface has more than one return value, the interface should return a namedtuple consisting of each value.</p>
 <p>In general, interfaces should avoid polymorphic return values (e.g., returning an array <strong>or</strong> a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:</p>
 <ul class="simple">
-<li><p><code class="docutils literal notranslate"><span class="pre">eig</span></code>: computing both eigenvalues and eignvectors.</p></li>
-<li><p><code class="docutils literal notranslate"><span class="pre">eigvals</span></code>: computing only eigenvalues.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigh</span></code>: computing both eigenvalues and eigenvectors.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigvalsh</span></code>: computing only eigenvalues.</p></li>
 </ul>
 </li>
 <li><p><strong>Implementation agnosticism</strong>: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.</p>

2022.12/extensions/linear_algebra_functions.html

@@ -51,8 +51,8 @@ Accordingly, the standardization process affords the opportunity to reduce inter
 
     In general, interfaces should avoid polymorphic return values (e.g., returning an array **or** a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:
 
-    -   ``eig``: computing both eigenvalues and eignvectors.
-    -   ``eigvals``: computing only eigenvalues.
+    -   ``eigh``: computing both eigenvalues and eigenvectors.
+    -   ``eigvalsh``: computing only eigenvalues.
 
 4.  **Implementation agnosticism**: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.
 

2022.12/searchindex.js

@@ -405,8 +405,8 @@ <h2 id="design-principles">Design Principles<a class="headerlink" href="#design-
 <li><p><strong>Return values</strong>: if an interface has more than one return value, the interface should return a namedtuple consisting of each value.</p>
 <p>In general, interfaces should avoid polymorphic return values (e.g., returning an array <strong>or</strong> a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:</p>
 <ul class="simple">
-<li><p><code class="docutils literal notranslate"><span class="pre">eig</span></code>: computing both eigenvalues and eignvectors.</p></li>
-<li><p><code class="docutils literal notranslate"><span class="pre">eigvals</span></code>: computing only eigenvalues.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigh</span></code>: computing both eigenvalues and eigenvectors.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigvalsh</span></code>: computing only eigenvalues.</p></li>
 </ul>
 </li>
 <li><p><strong>Implementation agnosticism</strong>: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.</p>

2023.12/_sources/extensions/linear_algebra_functions.rst.txt

@@ -51,8 +51,8 @@ Accordingly, the standardization process affords the opportunity to reduce inter
 
     In general, interfaces should avoid polymorphic return values (e.g., returning an array **or** a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:
 
-    -   ``eig``: computing both eigenvalues and eignvectors.
-    -   ``eigvals``: computing only eigenvalues.
+    -   ``eigh``: computing both eigenvalues and eigenvectors.
+    -   ``eigvalsh``: computing only eigenvalues.
 
 4.  **Implementation agnosticism**: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.
 

2023.12/extensions/linear_algebra_functions.html

@@ -405,8 +405,8 @@ <h2 id="design-principles">Design Principles<a class="headerlink" href="#design-
 <li><p><strong>Return values</strong>: if an interface has more than one return value, the interface should return a namedtuple consisting of each value.</p>
 <p>In general, interfaces should avoid polymorphic return values (e.g., returning an array <strong>or</strong> a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:</p>
 <ul class="simple">
-<li><p><code class="docutils literal notranslate"><span class="pre">eig</span></code>: computing both eigenvalues and eignvectors.</p></li>
-<li><p><code class="docutils literal notranslate"><span class="pre">eigvals</span></code>: computing only eigenvalues.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigh</span></code>: computing both eigenvalues and eigenvectors.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigvalsh</span></code>: computing only eigenvalues.</p></li>
 </ul>
 </li>
 <li><p><strong>Implementation agnosticism</strong>: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.</p>

2023.12/searchindex.js

@@ -51,8 +51,8 @@ Accordingly, the standardization process affords the opportunity to reduce inter
 
     In general, interfaces should avoid polymorphic return values (e.g., returning an array **or** a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:
 
-    -   ``eig``: computing both eigenvalues and eignvectors.
-    -   ``eigvals``: computing only eigenvalues.
+    -   ``eigh``: computing both eigenvalues and eigenvectors.
+    -   ``eigvalsh``: computing only eigenvalues.
 
 4.  **Implementation agnosticism**: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.
 

draft/_sources/extensions/linear_algebra_functions.rst.txt

@@ -405,8 +405,8 @@ <h2 id="design-principles">Design Principles<a class="headerlink" href="#design-
 <li><p><strong>Return values</strong>: if an interface has more than one return value, the interface should return a namedtuple consisting of each value.</p>
 <p>In general, interfaces should avoid polymorphic return values (e.g., returning an array <strong>or</strong> a namedtuple, dependent on, e.g., an optional keyword argument). Dedicated interfaces for each return value type are preferred, as dedicated interfaces are easier to reason about at both the implementation level and user level. Example interfaces which could be combined into a single overloaded interface, but are not, include:</p>
 <ul class="simple">
-<li><p><code class="docutils literal notranslate"><span class="pre">eig</span></code>: computing both eigenvalues and eignvectors.</p></li>
-<li><p><code class="docutils literal notranslate"><span class="pre">eigvals</span></code>: computing only eigenvalues.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigh</span></code>: computing both eigenvalues and eigenvectors.</p></li>
+<li><p><code class="docutils literal notranslate"><span class="pre">eigvalsh</span></code>: computing only eigenvalues.</p></li>
 </ul>
 </li>
 <li><p><strong>Implementation agnosticism</strong>: a standardized interface should eschew parameterization (including keyword arguments) biased toward particular implementations.</p>