Discussion about accuracy modes

["Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>]

Dear P1788,

There has been quite a bit of discussion (public and private) surrounding
the topic of accuracy modes for implict and explicit types.

For example, Vincent has argued (convincingly, I think) that only "valid"
accuracy mode should be required for variable-precision types. Motion 19, on
the other hand, seems to imply that all variable-precision types are
implicit. This raises the question in my mind: does this also imply that
_all_ implicit types will necessarily only be required to statisfy "valid"
accuracy requirements?

The reason I ask this question is because more and more I think that _some_
implicit types, such as mid-rad types with fixed range and precision, could
possibly satisfy "tightest" accuracy mode, at least for certain basic
operations such as +, -, *, /, sqrt, and conversions.

It makes me wonder if the current definition of implicit type in Motion 19
might not be a little too generalized. For example, perhaps accuracy modes
should be specified orthogonally to the distinctions of implicit and
explicit. In other words, perhaps we should not lump all variable-precision
types into the "implicit" category (as was the case in early discussion of
implicit types, e.g., when the more narrow definition of an implicit type
was that the endpoints of an interval didn't necessarily have an exact
representation by the underlying level 3 floating-point elements).

Attached is a PDF that attempts to illustrate some of these points. Notice
in this figure that accuracy modes are largely determined by whether the
interval type has fixed range and precision or not, as opposed to whether
the interval type is explicit or implicit. Alternatively, we could use the
proposed definiton for implicit type in Motion 19. In that case, some
mid-rad types (e.g., the ones depicted with fixed range and precision) could
be "made" explicit by providing some suitable definition of unique hull.

Within the column for types of fixed range and precision, I've further
divided the accuarcy modes into categories defined by operation type. The
"basic" operations include +, -, *, /, sqrt and conversions. The "trans"
operations are transcendentals such as sin, cos, log, exp, etc.

For explicit types with fixed range and precision, existing hardware for
computing the "tightest" enclosures is ubiquitous. IEEE 754 has required at
least this much for conformance. Hardware and software for last-bit accuracy
of transcendentals is not so ubiquitous, however, even though it is now at
least feasible due to the work of the French. But 754-2008 only recommends
transcendentals with last-bit accuracy, and does not require them for
conformance. Also, timing results from J.M. Muller and colleagues show
computing last-bit accurate transcendental functions can in worst cases be
an order of magnitude slower than algorithms that might only be accurate to
within one or two ULPs.

This is the reason I created a "strict" sub-category of explicits that
intersects the fixed range and precision column. For example, this "strict"
category would represent an implementation that provides the recommended
754-2008 accuracy requirements for transcendentals. IMO, this "strict" level
of accuracy for explicit types should be optional, i.e., it could be
recommended but should not be required for P1788 conformance (as is the case
in 754-2008).

In any case, these are the thoughts that have been on my mind lately
regarding these topics. I'm wondering what others think?

Sincerely,

Nate

Attachment: Accuracy Modes.pdf
Description: Adobe PDF document