Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion P1788/M0029.01: Level-3-interface-only --- discussion period begins



On Sat, Nov 19, 2011 at 12:16 PM, Nate Hayes <nh@xxxxxxxxxxxxxxxxx> wrote:
> Lee Winter wrote:
>>
>> This strikes me as far too complicated.  There is no need to
>> distinguish NaN values from numeric values.
>
> Hi Lee,
>
> I'm thinking ahead to compressed intervals. In that case, we need some
> encoding that distinguishes the Empty interval from the bare decorations.
> For example:
>   bits(NaN) + bits(NaN)
> could be a good encoding for the Empty interval and
>   bits(NaN) + bits(decoration)
> could be a good encoding for the bare decorations where bits(decoration) is
> a unique (non-NaN) bit string to distinguish between dac, def, ndf, gap,
> etc.

Well modulo the alternative definitions of bits() I understand the
issue, but I do not believe it is as important as the ruthless
application of KISS to this part of the the standard.

Consider that a compressed format will have to be decomposable for
manipulation, simple property inspection routines, and for I/O
purposes.  Thus the potential sophistication of the internal
representation should not dominate or complicate the trivial
operations of the system implementing the standard.  To be blunt one
evaluates the success of KISS by measuring how difficult it is to
described trivial aspects of the system.  If the trivial aspects
require non-trivial descriptions, then KISS has failed.

Also I do not believe space efficiency of the external representation
is a useful property of the standard.

Finally, if the standard mandates a compressed representation then
that representation will of necessity be found in floating-point data
layouts.  Any external representation that faithfully represents the
data layout will carry along the compressed format -- no extra
interpretations would be necessary.  SEM is one such external
representation.  I suggest that it is the second simplest such
representation after a straight binary or hex dump, which are a little
too hardware specific for my taste (c.f., 80-bit, 96-bit, and 128-bit
hardware layouts of extended double precision).

It is possible that I lack comprehension of the issue you are pointing
out.  Are you aware of and/or can you describe a case in which the SEM
encoding is not adequate to represent compressed intervals?

Thanks,

Lee Winter
Nashua, New Hampshire
United States of America (NDY)