| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Baker,
> Are there objections to simply dropping interchange encodings
> for compressed intervals from the current standards document?
I request to add Michel's paragraph about optional compressed intervals.
We came to agreement, his proposal is acceptable.
I attach the diff file and the changed page.
> Do we also need to do this for the interchange encodings in general?
I think we should keep it in the text.
-Dima
----- Original Message -----
From: rbk5287@xxxxxxxxxxxxx
To: ianm@xxxxxxxxxx, stds-1788@xxxxxxxxxxxxxxxxx
Sent: Friday, June 27, 2014 9:05:35 PM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: Encoding of compressed intervals
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
>
>
>
--
---------------------------------------------------------------
Ralph Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------
Index: P1788G_level3.tex
===================================================================
--- P1788G_level3.tex (revision 378)
+++ P1788G_level3.tex (working copy)
@@ -138,6 +138,26 @@
but an implementation may potentially use cohort information, or a
\nan payload.}
+When (optional) compressed intervals are supported, their interchange
+representation is as described above for bare intervals for non-empty
+intervals, but decorations are represented as a pair of floating-point
+datums, the first of which is a generic \nan (no payload information),
+and the second is a floating-point integer that encodes the decoration
+as follows:
+\bc
+\begin{tabular}{cr}
+ \Dill & 0.0 \\
+ \Demp & 2.0 \\
+ \Dtrv & 4.0 \\
+ \Ddef & 8.0 \\
+ \Ddac & 12.0 \\
+\end{tabular}
+\ec
+\note{These encodings match the octet-encoded decorations
+of decorated intervals, when interpreted as small integers, with
+a new decoration \Demp to represent a compressed \Emp interval.
+The \Dcom decoration cannot occur in a compressed interval.}
+
\medskip
Export and import of interchange formats normally occurs as a sequence
of octets, e.g. in a file or a network packet. There is therefore a need to define the {\bf octet-encoding} that maps the conceptual Level 4
Attachment:
compressed.pdf
Description: Adobe PDF document