Re: Empty interval representations (general) - ordering
Every halfway reasonable ordering has been done, including little endian bytes within 16 bit halfwords but big endian between halfwords and little endian bytes within 32 bit words but big endian between words.
For interval arithmetic, with two range end components (or a middle and one or two radii) and optionally decorations we have many possibilities. For interchange part of it should be specified, but for compatibility with existing hardware and software some should not.
For performance the floating point parts must be aligned "naturally" (ie, an 8 byte _Binary64 must be aligned on an 8 byte boundary) so the floating point values should be first and the decorations last. If mid-radius could have differing precisions then the mid should be first (assuming it would be the larger one).
The most natural ordering of lower and upper bounds (or radii) seems to be the order we write them in (lower first, then upper). The precedent is that complex is implemented with the real part first and imaginary last.
What we shouldn't specify is the particular ordering of bytes within an interval component. We should say that the floating point values should be stored the same way each system's floating point is, and the decorations should be stored the same way an integer of that size is.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
Vincent Lefevre ---05/07/2010 04:44:55 AM---On 2010-05-05 10:12:56 -0500, R. Baker Kearfott wrote: > That's an interesting stance since, I think
From: |
Vincent Lefevre <vincent@xxxxxxxxxx> |
To: |
Ian McIntosh/Toronto/IBM@IBMCA |
Date: |
05/07/2010 04:44 AM |
Subject: |
Re: Empty interval representations (general) |
On 2010-05-05 10:12:56 -0500, R. Baker Kearfott wrote:
> That's an interesting stance since, I think (correct me if
> I am wrong), that, except for "big-endian" and "small-endian",
> 754 does specify formats. Of course, an argument for
> not specifying is: "it does not matter what's inside
> if what is actually seen is as specified."
Actually, there's more than "big-endian" and "small-endian".
ARM FPA has a mixed-endian format for binary64 (little-endian
32-bit words stored as big endian). And any implementation is
free to store the bit string in any order it wishes.
For interval arithmetic, there can be more possibilities since
there are 2 numbers to store, unless we want to specify this.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)