(no commit message)

diff --git a/3d_gpu/architecture/dynamic_simd/shape.mdwn b/3d_gpu/architecture/dynamic_simd/shape.mdwn
index 44de1e48566873102354d9dd04d867967ecb72d0..4697e4114c82c330129b6ef9d19462685783e594 100644 (file)
--- a/3d_gpu/architecture/dynamic_simd/shape.mdwn
+++ b/3d_gpu/architecture/dynamic_simd/shape.mdwn
@@ -336,3 +336,25 @@ and:
            a = s.Signal(16) # element width set to 16
            b = s.Signal(shape*2)
            o2 = s.Signal(a.shape + b.shape)
+
+From these examples we deduce what the arithmetic operators
+have to cope with:
+
+* RHS of simple integers
+* RHS of another SimdShape
+
+In the latter case, there are further subdivisions because
+SimdShapes can be created as either fixed_width priority
+or elwidths priority
+
+* fixed_width priority (vec_op_widths=None)
+* elwidths priority  (fixed_width=None)
+* equal (no) priority (both are given)
+
+With some thought it becomes clear that when performing operations
+not involving elwidth priority should simply calculate a new fixed
+width based on straight arithmetic on the LHS and RHS fixed width.
+
+However the moment that elwidths (vec_op_widths) are involved then
+the priority switches to the elwidths, even if one of those elwidths were
+calculated initially from a fixed_width.