Re: Encodeing of compressed intervals

[Ian McIntosh <ianm@xxxxxxxxxx>]

Please make sure the encoding is equivalent to that of a C / C++ struct or a Fortran derived type.

That means that regardless of endianness, the first member of the struct has to be first, then the second member, etc.  For example, in a struct declared as
struct  { double  inf;  double sup; }  double_interval;
the inf value must be first and the sup second.  Their internal representation will depend on whether the system is big or little endian, or maybe whether they are in some network order, but the inf has to be before the sup.

We should follow this order to be consistent with implementations in those languages.

- Ian McIntosh          IBM Canada Lab         Compiler Back End Support and Development


Dmitry Nadezhin ---2014-06-27 12:05:56 PM---Michel, > Dima, I don't understand why you want to complicate things by invoking

From:	Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA,
Date:	2014-06-27 12:05 PM
Subject:	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