From 39e823114a59c7e851d7e3e49a618857aa489518 Mon Sep 17 00:00:00 2001
From: Sandeep Dasgupta <sdasgup@google.com>
Date: Tue, 29 Aug 2023 20:46:53 +0000
Subject: [PATCH] review iteration: various typo fixes

---
 rfcs/20230622-quantized-reduction.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/rfcs/20230622-quantized-reduction.md b/rfcs/20230622-quantized-reduction.md
index 248d97c097a..baeb522ee45 100644
--- a/rfcs/20230622-quantized-reduction.md
+++ b/rfcs/20230622-quantized-reduction.md
@@ -42,7 +42,7 @@ The RFC introduces the following proposal, emerged out of discussion in the
 , along with their tradeoffs.
 
 The proposal allows the reducer block to express the computation in a different
-element type (preferably higher accumulation type) than the one used in reduce
+element type (preferably wider accumulation type) than the one used in reduce
 op's ops arguments and return type. For illustrative purposes, in the following
 example, the operand element type `tensor<!quant.uniform<ui8:f32,
     input_scale:input_zp>>`  is different from the element type for
@@ -71,7 +71,7 @@ example, the operand element type `tensor<!quant.uniform<ui8:f32,
 
 ### Semantics
 
-Depending on (1) the input operand type is different from the reduction block
+If (1) the input operand type is different from the reduction block
 argument type or (2) the op result type is different from the reduction block
 return type, there will be implicit type conversion defined by either
 `stablehlo.convert`, `stablehlo.uniform_quantize`, or
@@ -86,17 +86,17 @@ return type, there will be implicit type conversion defined by either
  | (E) `stablehlo.convert`           | integer                                | floating-point                                      |
  | (F) `stablehlo.convert`           | floating-point                         | floating-point                                      |
  | (G) `stablehlo.convert`           | integer                                | integer                                             |
- | (G) `stablehlo.convert`           | complex                                | complex                                             |
+ | (H) `stablehlo.convert`           | complex                                | complex                                             |
 
 At this point there is no use for cases other than (A), (F), and (G).  My
 proposal here would be to address (A), (F), and (G) only.  Note that the (F)
-    partially addresses [Decide on mixed
-    precision](https://github.com/openxla/stablehlo/issues/369) for reduce op in
-    that it allows the the input or init value to differ from the corresponding
-    block arguments w.r.t the precision of floating-point types. However, the
-    mixed precision implementation in HLO seems more detailed in the sense that
-    even allows `inputs` and `init_values` to differ in floating-point
-    precision. My proposal would be to treat the above ticket separately.
+partially addresses
+[Decide on mixed precision](https://github.com/openxla/stablehlo/issues/369)
+for reduce op in that it allows the the input or init value to differ from the
+corresponding block arguments w.r.t the precision of floating-point types.
+However, the mixed precision implementation in HLO seems more detailed in the
+sense that even allows `inputs` and `init_values` to differ in floating-point
+precision. My proposal would be to treat the above ticket separately.
 
 ## Appendix