As Andrew says, verification/compliance concerns outweighed allowing
more flexible definition.

This is a policy decision ensuring reasonable limits on fragmentation in this space.

  Also, the fixed 7b implementation was seen
as being cheap to provide

To be clear, this was a tactical decision to move forward with the proposal as presented.
The proposal has not been fully vetted.
Further research was and is encouraged.
Improvements on the algorithm are possible and will get consideration but will remain constrained by the above policy decision.

Specifically, Brian, if you have proposal(s) for a preferred algorithm that is equally cheap to provide and verify,
  but provides equivalent or better worst case accuracy and provides equivalent or better distribution of error then
  experience has demonstrated that this TG has been receptive to consider such improvements.

The greatest benefit that can possibly be achieved by providing this mailing list in-the-open is to garner active participation from the wider community that will contribute;
 what might be for each individually a narrow area of interest/expertise, collectively provides a breadth of knowledge and insight that we as a TG do not possess.

 even if more accurate approximations are
added later.

To be clear, this is not a justification to limit due diligence of the current proposal.
Rather it does make clear that iterative improvement is possible and not impeded by adopting this or similar tangible proposals.

Krste
On Thu, 13 Aug 2020 17:37:01 -0700, "Andrew Waterman" <andrew@...> said:
 On Thu, 13 Aug 2020 17:37:01 -0700, "Andrew Waterman" <andrew@...> said:

 The task group did consider that possibility but concluded that forcing compatibility is more important.  As Bill points out, more precise (or flexibly precise) variants can be defined in the future, since there's beaucoup opcode space available for unary operations.

 On Thu, Aug 13, 2020 at 4:55 PM Brian Grayson <brian.grayson@...> wrote:
 As it stands, I think the spec prevents an implementer from being more accurate than described, right? Should the spec specify "accurate to at least 7 bits" instead?
 I could envision an embedded implementer who would like just a few bits more accuracy and fewer (or none) Newton-Raphson iterations for their specific use-case.
 (I've seen architectures that state a minimum accuracy, but leave the actual accuracy up to the implementer, which is enough for standard software to do the right thing.)

 Brian

The task group did consider that possibility but concluded that forcing compatibility is more important.  As Bill points out, more precise (or flexibly precise) variants can be defined in the future, since there's beaucoup opcode space available for unary operations.

On Thu, Aug 13, 2020 at 4:55 PM Brian Grayson <brian.grayson@...> wrote:

As it stands, I think the spec prevents an implementer from being more accurate than described, right? Should the spec specify "accurate to at least 7 bits" instead?

I could envision an embedded implementer who would like just a few bits more accuracy and fewer (or none) Newton-Raphson iterations for their specific use-case.

(I've seen architectures that state a minimum accuracy, but leave the actual accuracy up to the implementer, which is enough for standard software to do the right thing.)

Brian

  
On Thu, 13 Aug 2020 17:37:01 -0700, "Andrew Waterman" <andrew@...> said:


  
The task group did consider that possibility but concluded that 
forcing compatibility is more important.  As Bill points out, more 
precise (or flexibly precise) variants can be defined in the future, 
since there's beaucoup opcode space available for unary operations.
  

  
On Thu, Aug 13, 2020 at 4:55 PM Brian Grayson <brian.grayson@...> wrote:

  
As it stands, I think the spec prevents an implementer from being more accurate than described, right? Should the spec specify "accurate to at least 7 bits" instead?
I
 could envision an embedded implementer who would like just a few bits 
more accuracy and fewer (or none) Newton-Raphson iterations for their 
specific use-case.
(I've seen architectures that state a 
minimum accuracy, but leave the actual accuracy up to the implementer, 
which is enough for standard software to do the right thing.)

Brian