Re: Motion P1788/M0029.01: Level-3-interface-only --- discussion period begins
On Sat, Nov 19, 2011 at 3:11 PM, Nate Hayes <nh@xxxxxxxxxxxxxxxxx> wrote:
> Lee Winter wrote:
[...]
> "Are you aware of and/or can you describe a case in which the SEM encoding
> is not adequate to represent compressed intervals?"
>
> Strictly speaking I think we could *represent* compressed intervals with
> SEM by using the extra NaN payload bits to indicate the various flavors of
> NaI. They problem, as I understand it, is as follows:
>
> IEEE 754 NaNs, I've been told, don't have any standard rules for how the
> payload bits in the NaN propagate through floating-point operations.
This is a relatively ancient problem. In fact there are many
different sets of propagation rules already in use. There is no
standard because the 754 et seq groups wanted a single set of rules
rather than providing a standard mechanism for users and libraries to
define the rules they need. We should probably avoid that kind of
outcome.
> So if
> we use the NaN payload bits to try and distinguish the various flavors of
> NaI, we won't be able to rely on that information getting propagated through
> the underlying floating-point operations in any consistent manner.
I think you left out the word "automatically". Certainly we could
rely on NaI propagation if the interval standard required it. But it
would take extra effort on the part of implementors because they could
not rely upon the automatic propagation through the underlying FP
operations. Looking upward from the prespective of the standard is
and must be quite distinct from looking downward.
In a fairly massive test suite for a triplex library I had to deal
with this and the NaN sign issues. Part of the problem is the lack of
a standard. But a much larger problem is the lack of documentation by
the hardware and library vendors. On fact most chips (e.g., AMD,
intel, VIA, and Sun) have well defined propagation rules, but the
documentation for them is vary hard to find or even non-existent.
I gave up on signedness and masked off the sign bits of NaNs during
verification. But I found that a UDF was adequate to resolve the
payload problem. The UDF took as arguments an operation indicator and
a list of references to interval arguments and returned the desired
NaN with payload. Naturally the UDF was only invoked to verify
results of operations that had at least one NaN as an argument. It
was an inelegant kludge, but it worked.
So I suggest that we at least require documentation of the
implementor-defined default propagation rules for NaI. There is no
single right answer. If the implementors define and document their
NaI propagation rules then the market will be able to determine the
right answer(s).
I also believe that it would be useful to require a user-defined
propagation function to resolve the propagation of NaI. if the
default propagation function is nil/NULL then the implementor -defined
propagation rules would be in effect. Note that this could have zero
impact on either the time or space requirements of a program that did
not provide a user-defined propagation function because alternative
compilation and the linker can be used to eliminate the underlying
system's use of the propagation override capabilities.
> For
> example, it will be really difficult to ensure in the example above that the
> def NaI propagates through the addition operation over the dac NaI.
It would take more time, but I do not believe it would be difficult in
the sense of complexity. And if the rules for NaN propagation on the
underlying (hardware) system were documented, then the problem of NaI
propagation would disappear almost completely.
Perhaps we should not standardize upon the existing widespread lack of
information that currently prevails in the numeric community.
>
> So possibly SEM is good enough for purely exchanging data between P1788
> implementations. But this may make it real difficult to ensure the NaI
> information is then propagated correctly by using existing IEEE 754 hardware
> once an actual computation is commenced.
I disagree. Your conclusion above appears to be based on the
assumption that the external encoding has some influence upon the
operations over the internal encoding. I suggest that that the
standard should explicitly deny any such influence.
>
> Does any of this help shed light on the issue?
Yes, but I may still be missing some factor or issue that mandates the
influence mentioned immediately above. So I am interested in further
exposition.
It may be useful to divide the discussion into indepedent topics, one
topic being the external representation of interval data, for which
NaN payloads need only be represented, but not propagated, and the
other topic being the propagation of of tag information during
operations on internal representations, for which NaN payloads are
merely one possible representation. Note that I am opposed to the
proposal for using NaNs to encode tags, but I support the notion of
using payloads to annotate NaNs that arise during (lack of)
initialization and later processing.
Thanks for the detailed reply.
Lee Winter
NP Engineering
Nashua, New Hampshire
United States of America (NDY)