(no commit message)

diff --git a/3d_gpu/architecture/dynamic_simd/shape.mdwn b/3d_gpu/architecture/dynamic_simd/shape.mdwn
index 2c834f75207bc7d8200f5c5069da7c8bf11f1e87..86a33b6db4b3a941eb2785c4ef28a4e03eb5d447 100644 (file)
--- a/3d_gpu/architecture/dynamic_simd/shape.mdwn
+++ b/3d_gpu/architecture/dynamic_simd/shape.mdwn
@@ -463,11 +463,17 @@ Summary:
   - Exactly the same as for when RHS is an Integer, given that the
     integer fixed width is, in fact, an integer.
   - the return result is always a fixed-width priority SimdShape
-* **Either LHS or RHS Elwidth Priority**
-  - It is unsafe (not possible) to respect the fixed width therefore
-    it is always ignored
-  - all operators always expected to work (caveat: by only using
-    the elwidths)
-  - all operators work because they match elwidth-for-elwidth
-    in their computations.
-  - the return result is always an elwidth-priority SimdShape
+* **Either LHS or RHS Elwidth Priority** (but not both)
+  - all operators always expected to work because, again, one of
+    RHS or LHS is an integer, and that integer is used as the
+    input to the arithmetic.
+  - reverse-operators (rmul etc) take care of RHS.
+  - the return result is however always an elwidth-priority SimdShape
+* **Both LHS and RHS Elwidth priority**
+  - for mul and shift-left, as long as one of LHS or RHS has identical
+    elwidths, by a mathematical coincidence these are
+    fine. return result may be a dual-priority result.
+  - for add and sub, an exception must be raised.
+  - divide and shift-right are expected to work on the condition
+    that, again, all elwidths have the exact same value, and, again,
+    that no LSBs are lost.