Baker,
I think you are right. compressed intervals are optional and I am
not sure if we need an
interchange format at all. Why not simply interchange uncompressed
intervals ?
may be I don't see the point, but I see the deadline approaching.
Juergen
Am 27.06.2014 19:04, schrieb Ralph
Baker Kearfott:
All,
At some point, we must finalize what we have and submit the
standard. My original target for this was today.
Regarding the interchange format for compressed intervals, it
seems
we are still in the "research" phase and not in the
"cross t's and dot i's" phase of the document wording.
Are there objections to simply dropping interchange encodings
for compressed intervals from the current standards document?
Do we also need to do this for the interchange encodings in
general?
Baker
On 06/27/2014 11:19 AM, Ian McIntosh wrote:
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
Inactive hide details for Dmitry Nadezhin ---2014-06-27 12:05:56
PM---Michel, > Dima, I don't understand why you want to
compliDmitry
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
|