Re: P754 draft 1.8.0

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

In general the members of the BRC were aiming to minimize the scope of any
changes.

> I'm not extatic about the way Clause 7.6 was resolved, but it'll do.

This has to do with the definition of inexact.     I would have preferred
to say something about inexact usually being about roundoff of a result
that didn't fit the destination exactly, but for 
specified operations has the slightly different meaning that the value of
the result differs from the value of the operand.

> (1) Hexadecimal strings.
>
> In 5.4.3 support for hexadecimal strings became optional.

In the previous draft it said "shall" in one place and "should" in 
another, so some resolution was necessary.

> situations.  That's because decimal-strings are now required to be
> converted with correct rounding.  There is one problem area however,
> and that is those extendable formats of Clause 3.7.  Perhaps we should
> consider conditionally-required support:
>
>     If extendable-precision binary formats are supported, conversion
>     from hexadecimal strings must be supported.
>
> The problem also exists if a large number of extended formats are
> supported, because each one requires a different decimal string to
> arrive at the same binary value -- unless H is unbounded, and the
> programmer does not mind entering the EXACT decimal value.

These cases were not discussed at BRC.  A larger issue is that 
it's not even clear whether an extendable format might vary at run
time or at compile time or both and who decides (language, implementation) - 
"an extendable precision format is a format with a precision and range 
that are defined under user control."
And in either case nothing specific
is said about expression evaluation involving
different extendable precisions and ranges.

> (2)  preferredWidth (what widenTo evolved into, via minWidth)
>
> In 10.3 the requirement for radix-specific preferredWidth was removed.
> This may be ok (and even good) for preferredWidthFormat, but it is unclear
> how this applies to preferredWidthFormat.  If the latter is implemented
> as an attribute with a value, e.g. a type name, there should definitely
> be two attributes, preferredWidthBinary and preferredWidthDecimal.  If the
> intent is to have a set of boolean attributes like preferredWidthBinary64,
> then it should be clear that either the preferredWidthNone, or one of the
> preferredWidthFormat attributes for each radix, be asserted.  If none is
> asserted, the language presumably defines the default, and if conflicting
> attributes are set, presumably an error would be reflected.

This certainly could have been clearer - in fact, the draft as a whole is
very vague about attribute names and attribute values.
The counter-argument was that neither does the draft explicitly name
the different roundingDirection attributes, though the draft does say
"Implementations supporting both decimal and binary formats shall provide 
separate rounding-direction attributes for binary and decimal, 
the binary rounding direction and the decimal rounding direction."
9.3.1 for dynamic modes says:

"Language standards that define dynamic mode specification for 
binary rounding direction shall define:
 ? void setBinaryRoundingDirection(binaryRoundingDirection).

Language standards that define dynamic mode specification for 
decimal rounding direction shall define:
? void setDecimalRoundingDirection(decimalRoundingDirection)."

and so I would call the static attributes BinaryRoundingDirection
and DecimalRoundingDirection with values from 4.3.1 and 4.3.2:
roundTiesToEven...roundTowardZero.

Thus likewise BinaryPreferredWidth and DecimalPreferredWidth.

> I would have much preferred an exposition that states that the notion of
> preferred width must be controllable, without delving into the details,
> but I suppose there was a desire to fit this into an environment where
> groups of modes can be controlled, perhaps saved and restored, using a
> common set of interfaces.

PreferredWidth could be implemented with dynamic modes, but I think the
reason it is mandatory is to provide a definite way of dealing with
extended precision expression evaluation when the user definitely wants
it and when the user definitely doesn't want it, regardless of performance
implications in either case.    
It's closely related to the narrowing formatOf arithmetic operations of
5.4.1 and perhaps should be specified in a coordinated way.  

PreferredWidth is
mandatory for implementations, although there is also a value-changing
optimization license in 10.4 which is just a suggestion:

"A language standard should also define, and require implementations to provide,
attributes that allow and
disallow value-changing optimizations, separately or collectively, for a block.
These optimizations might include, but are not limited to:

 ...
  use of wider intermediate results in expression evaluation.
 ...

Programmers license these optimizations when the corresponding changes in 
numerical values or status flags are acceptable."

Decimal exponents should also have been mentioned along with values and 
flags.


> I also have a question about the new Note at the end of 5.4.1, which
> states that some operations can be implemented as sequences of others
> as long as the result and exceptions are the same.  Is that not generally
> the case anyway?  Why single out the conversion operations?

It's a NOTE, and therefore not normative.    The BRC argued a long time
about this, and ultimately didn't want to change the current requirement
that 
        z = x + y
has to be "provided" with one rounding when z, x, and y are all the same format,
as languages often do, and 
        z = fma(w, x, y) 
also has to be "provided" with one rounding
even when all the formats are different, which languages often don't.
There are lots of ways to meet the requirements of 5.4.1 in terms of
composing operations from a limited subset, but what does "provide" mean
for a programming language?     Clause 5 is written "implementations shall
provide" (most of) its operations, but it would be more in tune with the
rest of the draft to say "language standards shall define".

In any case the current wording mixes up the common well-understood language
concept of generic arithmetic operations +-*/ and the 
far less common 754R concept of arithmetic operations with specific 
destinations to be computed with only one rounding.     I think those should
have been specified explicitly and distinctly.

My commentary on draft 1.8.0 is at 
http://754r.ucbtest.org/msc-ballots/comments-180.html