Re: Encodeing of compressed intervals
Michel,
> Dima, I don't understand why you want to complicate things by invoking
> unions or similar constructs.
I worked much on floating-point emulators of wide FP formats,
so I have a shifted sense of simplicty because of this background:
bit-twidding algorithms seem simple to me.
The extraction of decoration octet from your encoding
by bit-twidding (without FP instruction)
seems a little more complicated than from encoding (c),
but not very complicated.
I don't insist on FP x FP + DEC representation.
I tried to search among many variants,
but gradualy your Level 3 representation (NaN,dec) becomes acceptable to me.
Variant (c) can be interpreted as at Level 3 as (NaN,dec*DBL_MIN).
If (c) is not attractive to you, I agree with your representation.
If it is necessary to rollback decoration encoding from octet
to small integer, I agree. Perhaps this should be done at Level 3
instead of Level 4.
-Dima
----- Original Message -----
From: mhack@xxxxxxx
To: stds-1788@xxxxxxxxxxxxxxxxx
Sent: Friday, June 27, 2014 6:53:36 PM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: Encodeing of compressed intervals
On Thu, 26 Jun 2014 21:05:53 -0700 (PDT), Dima wrote:
> It is necessary to define Level 3 representation of compressed
> intervals before definition of their bit-encoding and octet-encoding.
> Now I defined it as disjoint sum (C union)
> Level 3 representation = FP x FP + DEC
Dima, I don't understand why you want to complicate things by invoking
unions or similar constructs. Yes, there are many way to encode all
sorts of things in a bitstring that starts with the representation of a
NaN -- but is there any doubt that (in a 754-conforming implementation)
a compressed interval simply consists of two floating-point datums, for
non-empty bare intervals as well as for threshold-crossing decorations?
Remember that octet-encoding only applies to *single* datums, because
it is at that level that Endianness issues are defined -- NOT across
a bitstring that may span several datums. So we *have to* encode the
compressed decoration in one of the two floating-point datums, and my
proposal avoids all those portability issues of NaNs. Read 754-2008
carefully, and you'll note that there are many SHOULDs and few SHALLs
concerning the propagation of NaNs -- there are reasons for that.
Michel.
---Sent: 2014-06-27 14:52:58 UTC