<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Damian, it looks like you’re referring to the 20230726 draft instead of the updated 20230806 one. Line numbers changed but otherwise I don’t think it matters for your comments.<br><div><br><blockquote type="cite"><div>On Aug 21, 2023, at 10:03 PM, Damian McGuckin <damianm@esi.com.au> wrote:</div><br class="Apple-interchange-newline"><div><div>On Sun, 6 Aug 2023, Jim Thomas wrote:<br><br><blockquote type="cite">6 Reduction functions ? Damian<br></blockquote><br>OK - Here goes:<br><br>Section 6:<br><br>(Page No 2 which is the 10th page of the Document)<br><br>* Line 14-15:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Line 15 says:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>The type declared is size_t.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>It is not obvious what "the type" is all about.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>I know that size_t corresponds to the requirement by IEEE 754 for<br><span class="Apple-tab-span" style="white-space:pre"> </span>integralFormat to be defined.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>However, the sentence seems like is it missing but I am not exactly<br><span class="Apple-tab-span" style="white-space:pre"> </span>what sure what it is trying to say. Should it be<br><br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>The size_t type is declared within <math.h>??<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Or maybe that means that the previous sentence (Line 14)<br><span class="Apple-tab-span" style="white-space:pre"> </span>needs to be reworded.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Sorry, I do not have the answer but Line 14 and 15 seem vague<br><span class="Apple-tab-span" style="white-space:pre"> </span>unless you read in at the same time as you read the IEE 754<br><span class="Apple-tab-span" style="white-space:pre"> </span>standard. And then it is obvious.<br></div></div></blockquote><div><br></div></div><div>The first two lines of clause 6 are:</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>The header <math.h> declares the type and functions in this subclause.</div><div><div><br></div></div><div><div>The type declared is size_t (defined in C23 7.21).</div><div><br></div></div></blockquote><div><div>This says were the type is to be declared and gives a normative reference to its description. How it this not clear?</div><div><br></div><div><div>Note also that this follows the style in C. For example, see C 23 7.26.1.</div><div><br></div><div>I see in such cases C says “described in” instead of “defined in”. I’ll change back to “described in”.</div><div><br></div></div></div><div><blockquote type="cite"><div><div><br>* Line 21:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>the overflow or underflow floating-point exception is raised and a range<br><span class="Apple-tab-span" style="white-space:pre"> </span>error occurs if and only if the determination of the final result overflows<br><span class="Apple-tab-span" style="white-space:pre"> </span>or underflows.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>The phrase<br><br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>determination of the final result<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>implies (to me) the actual process that produces the final result.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>And the whole idea is to avoid redundant exceptions during that<br><span class="Apple-tab-span" style="white-space:pre"> </span>process.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Does it mean the same if you use less words and say just:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>... if and only if the final result overflows or underflows.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>That is also simpler.<br></div></div></blockquote><div><br></div>I think what you suggest is clearer and simpler.</div><div><br><blockquote type="cite"><div><div><br>* Line 33:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>is the word "may" correct or should it be stronger?<br></div></div></blockquote><div><br></div>It’s “may" because Annex F generally does not require functions to raise “invalid” as an effect of a signaling NaN input.<br><blockquote type="cite"><div><div><br>6.1: (Page No 3)<br><br>* Line 26-27:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>... Otherwise (if no member of p is a NaN and no two members of p<br><span class="Apple-tab-span" style="white-space:pre"> </span>are infinities with different signs), if any member of array p is<br><span class="Apple-tab-span" style="white-space:pre"> </span>an infinity, the functions return that same infinity.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>I would personally omit the command and replace it with 'and'.<br></div></div></blockquote><div><br></div>What is “the command”?</div><div><br><blockquote type="cite"><div><div><br><span class="Apple-tab-span" style="white-space:pre"> </span>Or have I changed the meaning.<br><br>6.2: (Page No 4)<br><br>* Line 23-26<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>This text is not consistent with 6.1. What were two sentences are<br><span class="Apple-tab-span" style="white-space:pre"> </span>now linked into a single sentence with a semi-colon and "otherwise,".<br><span class="Apple-tab-span" style="white-space:pre"> </span>But the second half of that sentence is about NaN, the first half is<br><span class="Apple-tab-span" style="white-space:pre"> </span>about Infinity. They are strictly unrelated. Why merge them.<br></div></div></blockquote><div><br></div>A tricky part of the specification is to make clear what “otherwise” means. The use of a semicolon (instead of a period) here is to link “otherwise” to the “if” clause in the first part of the sentence, not the earlier “if” in the paragraph. In 6.1 (which has more cases) it seemed better to write out explicitly what “otherwise” means.<br><blockquote type="cite"><div><div><br><span class="Apple-tab-span" style="white-space:pre"> </span>I suggest keeping the text consistent with 6.1 which also reduces<br><span class="Apple-tab-span" style="white-space:pre"> </span>the sentence length.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>The reduc_sumabs functions compute the sum of the absolute values of<br><span class="Apple-tab-span" style="white-space:pre"> </span>the n members of array p: (SIGMA stuff) |p[i]|. If the length n = 0,<br><span class="Apple-tab-span" style="white-space:pre"> </span>the functions return the value +0. If any member of array p is an<br><span class="Apple-tab-span" style="white-space:pre"> </span>infinity, the functions return INFINITY-symbol; If any member of<br><span class="Apple-tab-span" style="white-space:pre"> </span>array p is a NaN, the functions return a quiet NaN.<br></div></div></blockquote><div><br></div>This is inconsistent if the array has both an infinity member and a quiet NaN member.</div><div><br><blockquote type="cite"><div><div><br><span class="Apple-tab-span" style="white-space:pre"> </span>My 2c.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>(Questionable comment)<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Why, when we use Mag[nitude] in the max/min function, do we use the<br><span class="Apple-tab-span" style="white-space:pre"> </span>abs[solute-value] concept here. This is a sum by magnitudes.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Yes, I know that is to match IEEE 754 2019.<br><br>6.3: (Page No 5)<br><br>* Line 23-26<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Same comment as for 6.2.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>The reduc_sumaq functions compute the sum of the squares of<br><span class="Apple-tab-span" style="white-space:pre"> </span>the n members of array p: (SIGMA stuff) (p[i]*p[i]). If the length n = 0,<br><span class="Apple-tab-span" style="white-space:pre"> </span>the functions return the value +0. If any member of array p is an<br><span class="Apple-tab-span" style="white-space:pre"> </span>infinity, the functions return INFINITY-symbol; If any member of<br><span class="Apple-tab-span" style="white-space:pre"> </span>array p is a NaN, the functions return a quiet NaN.<br><br>6.4: (Page No 6)<br><br>* Line 36<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>I suggest replacing the comma with<br><br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>and<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>and removing the parentheses.<br></div></div></blockquote><div><br></div>The parentheses indicate that the conditions are merely to clarify what “otherwise” refers to, unlike the condition “if a term …” which follows the parentheses.<br><blockquote type="cite"><div><div><br>6.5: (Page No 7)<br><br># Lines 33-42 - The Description<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>The text goes<br><br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>If ...<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>If ...<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>If ...<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>If ...<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>Otherwise ...<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>Otherwise ...<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>Otherwise ...<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>If ...<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>If that was a program, I would be worried.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>why use Otherwise? It is not consistent anyway (at least the way<br><span class="Apple-tab-span" style="white-space:pre"> </span>I read it). </div></div></blockquote><div><br></div><div>What is not consistent?</div><br><blockquote type="cite"><div><div>But that is a personal opinion and I am open to<br><span class="Apple-tab-span" style="white-space:pre"> </span>change.<br><br>6.6: (Page No 8)<br><br>* Lines 40-overpage - The Description:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Same comment as for 6.5.<br><br>6.7: (Page No 9)<br><br>* Lines 44-overpage - The Description:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Same comment as for 6.5.<br></div></div></blockquote><div><br></div>These specs are somewhat complicated but they are intended to be consistent. Please call out precisely any inconsistencies you see.</div><div><br></div><div>- Jim Thomas<br><blockquote type="cite"><div><div><br>Note that something tells me that implementing those to avoid redundant<br>exceptions is going to be a nightmare. But that is not what we are doing<br>here.<br><br>Thanks - Damian<br><br>Pacific Engineering Systems International ..... 20D Grose St, Glebe NSW 2037<br>Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here<br>Views & opinions here are mine and not those of any past or present employer</div></div></blockquote></div><br></body></html>