Re: Comments on David Hough's proposed ballot submissions

[David Hough 754R work <754r@xxxxxxxxxxx>]

> I agree with David that it may be premature to nail down future wide
> formats, but not strongly; I do understand the desire to pre-empt
> unnecessary variation.

There is an argument of economies of scale for standardizing
in the range of 32-128 bits;
relatively few applications have requirements outside that range, 
and their requirements may not overlap much, so there may be no economies
of scale to be obtained by standardizing there.

> I don't understand the purple prose after the raiseFlags() description.

(in 574.pdf) The value of a raised flag is "raised" (or "true")
on all current implementations, but in principle 
it might be something more complicated like an exception record.
Then there would have to be a simple default for flags raised by raiseFlags
rather than by arithmetic, such as an exception record referring to
the operation "raiseFlags" rather than to an arithmetic operation and 
operands.

> I like the clarification, and the definition of the minWidth concept as
> opposed to the widenTo concept.  I don't know the history of the widenTo
> concept; it was new to me when I first heard the term, though I was
> familiar with the old K&R rule for C, which was in fact in terms of
> widening input arguments, and not about narrowing precise intermediate
> results.

> The names minWidth_nobinary and minWidth_nodecimal are really bizarre
> however; noMinWidthBinary might have been better.  But do we need this
> concept at all?  Would minWidth_binary32 (where binary32 would be the
> narrowest supported basic format) not be just as good?

minWidth is different for binary and decimal expressions (754R discourages
mixed radix expressions).   
They could have names minWidth2 and minWidth10 but that's
usually redundant because the format name will indicate the radix.
But the default case of no minimum width has to have a different name
in different radices - it could be "minWidth2 none" and "minWidth10 none"
or almost as I suggested "mindWidth no2" and "minWidth no10"  
I think it's better to have one attribute minWidth per radix, with parameters,
than to have a separate attribute name for the default case.    

Using "minWidth binary32" for the default "minWidth nobinary" 
might cause trouble
on systems with a binary16 format.    But "minWidth binary16" might not
compile on systems without binary16, challenging portable programmers.
Maybe "minWidth binary0" and "minWidth decimal0" are what's needed.