double rounding in x86

[Tom Lynch]

> Nowhere does the standard require that values in registers be stored bit-for-
> bit to memory.  The accuracy and rounding requirements only apply to the result
> of an operation.  In the case of the x86, results of arithmetic operations

> Furthermore, double rounding does NOT occur - results of operations are
> rounded once before being placed in extended precision registers.  The IEEE
> Standard does not require results to be rounded taking into account the
> narrower exponent range for single and double precision formats if the desti-
> nation is an extended precision format, regardless of how the precision mode
> is set. 


An interesting nuance, but it would seem that a "result" is something
which could be used in further calculation.  Hence, the "result"
should be writable to memory.  If a result can be a fleeting entity
which only provides a hint as to the operand provided for further
calculation, then one could think up conforming systems which truly
produces bizarre final results.

Perhaps one could fix the problem by saying "x86 floating-point
*stack* arithmetic is IEEE std754 compliant" hence, arithmetic where
intermediates go to memory would be non-compliant because of the
double rounding.  Such a definition would be very unfortunate, as it
would be difficult for a compiler/programmer to guarantee that all
calculations would be done on the stack when IEEE 754 arithmetic is
desired.

> are stored in *extended precision* registers, and NOT to double precision
> registers.  When those values are stored to memory, if the destination format
> is double precision, those values *cannot* be stored bit-for-bit - they must
> be converted from extended precision to double precision.  It cannot be other-
> wise. 
     
hmm 

  1) In the case under discussion, it is not true that the destination format
     is x86 style double extended as you imply here.  Actually it is another
     type of extended, one with an larger exponent range, but the same 
     precision as a double.  This is the result of setting the precision control
     register to double.

  2) It could be otherwise, the rounding precision control field  could also 
     limit the exponent range. Unfortunately, a change of this style may
     cause gross behavioral changes in existing code.

  2) 


> Finally, remember the IEEE Standard does NOT guarantee results will
> be bit-for-bit identical on different standard-conforming arithmetic engines -
> some variation is built into the Standard (look, for example, at the rules
> for how underflow may be detected).

Yes, underflow, tiny and inexact, or just tiny.  

ok how about this: If two conformant platforms use the same mechanism for 
 for underflow detection, then the same bit strings result from the same
 calculations.

Hence, one needs to know only two things for there IEEE 754 code and
databases to be platform independent: 

  Compliance Requirements:

     1. standard compliance
     2. underflow detection method (1 of 2 possibilities)


If I could identify items which are in the "spirit" of the standard, they
would be these:

   1. guarantee that round to nearest rounding is sufficiently well behaved
      as to be unbiased.  AND for the fundamental operations, the best that
      can be done.

   2. guarantee that directed rounding is sufficient for enclosure techniques
      such as interval arithmetic.  AND for the fundamental operations, the 
      best that can be done.

   3. fundamental operations yield the same answers on compliant platforms.


I have heard a number of the standard proponents argue that wrong
numerical answers from a conforming platform are ok because "we all
get the same wrong answers". - and I am quoting some informed people
here, also was this not one of the selling points in the first place!.  
Hence #3 seems to have a wide following.  If we reject #3 we
are left trying justify the standard based on its behavior. I know
many would argue this, but it gets messy.  There are very short
calculations which get very wrong answers. Which leaves us justifying
the standard based on some statistical "right more often" argument,
or "easier to work with".  

Also, if #3 is not a criteria, and the x86 intermediate format is
ok, then can I not introduce just about every other method of doing
arithmetic based on the following:

       1) I can supply a function which shows that in some form
          the required "result" is there if I look at it right,
          its just that I don't use it.
 
       2) I can provide the IEEE required format by conversion,
          it just won't be the same bit string as anyone else gets.

We could add another item to the "compliance requirements", of some
kind, I'll let you suggest what that would be.  However, the x86
architecture isn't going to let you signal the case occured.  For
example, in the example under consideration. When the first rounding
is done, the number is not recognized as being tiny because of the
expanded exponent range.  Hence the user cannot know that the "error
free" part of #3 should apply to a result.



> I'd be interested in your reaction to this.

hope it was interesting :-)

>- Sam Figueroa (figueroaacs.nyu.edu)

Tom.Lynchaamd.com