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

Tue Aug 22 12:30:34 PDT 2023

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.

> On Aug 21, 2023, at 10:03 PM, Damian McGuckin <damianm at esi.com.au> wrote:
> 
> On Sun, 6 Aug 2023, Jim Thomas wrote:
> 
>> 6 Reduction functions ? Damian
> 
> OK - Here goes:
> 
> Section 6:
> 
> (Page No 2 which is the 10th page of the Document)
> 
> * Line 14-15:
> 
> 	Line 15 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.

The first two lines of clause 6 are:

The header <math.h> declares the type and functions in this subclause.

The type declared is size_t (defined in C23 7.21).

This says were the type is to be declared and gives a normative reference to its description. How it this not clear?

Note also that this follows the style in C. For example, see C 23 7.26.1.

I see in such cases C says “described in” instead of “defined in”. I’ll change back to “described in”.

> 
> * Line 21:
> 
> 	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.
> 
> 	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.

I think what you suggest is clearer and simpler.

> 
> * Line 33:
> 
> 	is the word "may" correct or should it be stronger?

It’s “may" because Annex F generally does not require functions to raise “invalid” as an effect of a signaling NaN input.
> 
> 6.1: (Page No 3)
> 
> * Line 26-27:
> 
> 	... 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 command and replace it with 'and'.

What is “the command”?

> 
> 	Or have I changed the meaning.
> 
> 6.2: (Page No 4)
> 
> * Line 23-26
> 
> 	This text is not consistent with 6.1.  What 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.

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.
> 
> 	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.

This is inconsistent if the array has both an infinity member and a quiet NaN member.

> 
> 	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_sumaq 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.

The parentheses indicate that the conditions are merely to clarify what “otherwise” refers to, unlike the condition “if a term …” which follows the parentheses.
> 
> 6.5: (Page No 7)
> 
> # Lines 33-42 - The Description
> 
> 	The text goes
> 
> 		If ...
> 		If ...
> 		If ...
> 		If ...
> 		Otherwise ...
> 		Otherwise ...
> 		Otherwise ...
> 		If ...
> 
> 	If that was a program, I would be worried.
> 
> 	why use Otherwise? It is not consistent anyway (at least the way
> 	I read it).

What is not consistent?

> But that is a personal opinion and I am open to
> 	change.
> 
> 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.

These specs are somewhat complicated but they are intended to be consistent. Please call out precisely any inconsistencies you see.

- Jim Thomas
> 
> 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
> 
> Pacific Engineering Systems International ..... 20D Grose St, Glebe NSW 2037
> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
> Views & opinions here are mine and not those of any past or present employer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230822/ec515ca5/attachment.htm>