double rounding in x86

[Tom Lynch]

  > lynch:
  > This statement is a bit inaccurate - in the situation I described,
  > the rounding precision is set.  The problem is that rounding precision
  > does not effect the exponent range, except when performing a store.

  moshier:
  I have heard about that in connection with the 8087 and 80287, but
  thought it was supposedly fixed in later models.  Could you please
  send me a specific numerical case, if you have one handy?

It hasn't been "fixed".  There are many cases, in addition to the
one I gave originally.  

   1) Any calculation which has an intermediate value which is
      larger than the double/single exponent can represent, but still within
      range for the double extended exponent - while the precision 
      control field is set to double/single.  

      The IEEE conformant** arithmetic will produce an infinity, the
      x86 machine will not.

      ** there is a footnote in the IEEE spec which "allows" for extended
      range.  It is not clear what the meaning of the foot notes is, but
      this is at least arguably compliant.  However, it certainly causes
      one to diverge from the values that would be produced on other platforms.

      It has also been argued that such divergence is immaterial.  I
      fail to see a purpose for the standard if this is the case.

   2) Any calculation which produces a very small number in analogy to #1

   3) The case that was brought out by Paranoia (described earlier):

      A small value rounds to a value half way between two representable
      values in the reduced exponent range.  A store is done, hence
      a second rounding.  Double rounding of a result is certainly not
      IEEE 754 compliant.

      Some have argued that this memory value is not a *result*.  I
      do not accept this argument, as memory values are operands for
      further calculation.  Obviously they are results.

      It has also been argued that memory versus local stack is a 
      compiler issues - and the standard doesn't deal with compiler
      issues.  I find this argument has a conclusion that doesn't 
      follow from the supposition.  It is true that the memory versus
      stack isn't an issue according to the standard.  And I would 
      conclude therefore, it should work both ways - if it is used
      both ways.  It is immaterial where the code and operands come
      from.  Yes, this is not a compiler issue.

      Yet another argument has been, who really cares, it is close enough,
      there is a huge user base, and PC code isn't numerical intensive
      anyway.  I disagree with this on the basis that this that compliance
      is a technical issues, so marketing studies and forcasts irrelevant.
      (One may decide that the IEEE std. 754 is not appropriate to there
      application, but one can not decide they are compliant because the
      it is not "important").


-tom