[Cfp-interest 2837] Re: CFP review of TS-4 and TS-5 revisions

[Damian McGuckin]

Here are the line numbers against the 20230806 revision.  Sorry about
missing that.

I hope I got these updated numbers right.

I have not tried to incorporate anything Fred or Jim have mentioned

That said, there is one of my comments below which is related to Fred
and Jim's comments about SNANs.

Section 6:

(Page No 2 which is the 10th page of the Document)

* Line 21-22:

  	Line 22 says:

  		The type declared is size_t.

  	It is not obvious what "the type" is all about.

  	I know that size_t corresponds to the requirement by IEEE 754 for
  	integralFormat to be defined.

  	However, the sentence seems like is it missing but I am not exactly
  	what sure what it is trying to say. Should it be

  		The size_t type is declared within <math.h>??

  	Or maybe that means that the previous sentence (Line 14)
  	needs to be reworded.

  	Sorry, I do not have the answer but Line 14 and 15 seem vague
  	unless you read in at the same time as you read the IEE 754
  	standard. And then it is obvious.

* Line 28:

  	the overflow or underflow floating-point exception is raised and a range
  	error occurs if and only if the determination of the final result overflows
  	or underflows.

  	The phrase

  		determination of the final result

  	implies (to me) the actual process that produces the final result.

  	And the whole idea is to avoid redundant exceptions during that
  	process. (I really have no idea how to do achieve this from an
 	implementation viewpoint but this is not about implementation)

  	Does it mean the same if you use less words and say just:

  		... if and only if the final result overflows or underflows.

  	That is also simpler.

Page No 3

* Line 8:

  	is the word "may" correct or should it be stronger?

 	(This related to Fred and Jim comments about SNANs. But I guess it
 	is "may" in case SNANs are not supported)

6.1:

* Line 37-39:

  	... Otherwise (if no member of p is a NaN and no two members of p
  	are infinities with different signs), if any member of array p is
  	an infinity, the functions return that same infinity.

  	I would personally omit the comma and replace it with 'and'.

  	Or have I changed the meaning.

6.2: (Page No 4)

* Line 23-26

  	This text is not consistent with 6.1.  What in 6.1 were two sentences
 	are now linked into a single sentence with a semi-colon and "otherwise,".
  	But the second half of that sentence is about NaN, the first half is
  	about Infinity. They are strictly unrelated. Why merge them?

  	I suggest keeping the text consistent with 6.1 which also reduces
  	the sentence length.

  	The reduc_sumabs functions compute the sum of the absolute values of
  	the n members of array p: (SIGMA stuff) |p[i]|. If the length n = 0,
  	the functions return the value +0. If any member of array p is an
  	infinity, the functions return INFINITY-symbol. If any member of
  	array p is a NaN, the functions return a quiet NaN.

  	My 2c.

  	(Questionable comment)

  	Why, when we use Mag[nitude] in the max/min function, do we use the
  	abs[solute-value] concept here. This is a sum by magnitudes.

  	Yes, I know that is to match IEEE 754 2019.

6.3: (Page No 5)

* Line 23-26

  	Same comment as for 6.2.

  	The reduc_sumsq functions compute the sum of the squares of
  	the n members of array p: (SIGMA stuff) (p[i]*p[i]). If the length n = 0,
  	the functions return the value +0. If any member of array p is an
  	infinity, the functions return INFINITY-symbol; If any member of
  	array p is a NaN, the functions return a quiet NaN.

6.4: (Page No 6)

* Line 36

  	I suggest replacing the comma with

  		and

  	and removing the parentheses which means a comma goes after Otherwise,

 	I am not sure that Otherwise is needed.

6.5: (Page No 7)

# Lines 33-42 - The Description

  	The text goes

  		If ...
  		If ...
  		If ...
B 		Otherwise ...
  		Otherwise ...
  		Otherwise ...
  		If ...

  	why use Otherwise? It is not consistent anyway (at least the way
  	I read it). But that is a personal opinion and I am open to change.

 	The first 2 otherwises belong with the preceding IF.

 	The 3rd otherwise if not related to any of the other Ifs.

 	It is hard to read.

6.6: (Page No 8)

* Lines 40-overpage - The Description:

  	Same comment as for 6.5.

6.7: (Page No 9)

* Lines 44-overpage - The Description:

  	Same comment as for 6.5.

Note that something tells me that implementing those to avoid redundant
exceptions is going to be a nightmare. But that is not what we are doing
here.

Thanks - Damian