2

The FPRoundBase [1] uses "tininess before rounding" logic if FPCR.AH != '1':

// Underflow occurs if exponent is too small before rounding, and result is inexact or
// the Underflow exception is trapped. This applies before rounding if FPCR.AH != '1'.
boolean trapped_UF = fpcr.UFE == '1' && (!InStreamingMode() || IsFullA64Enabled());
if !altfp && biased_exp == 0 && (error != 0.0 || trapped_UF) then
    if fpexc then FPProcessException(FPExc_Underflow, fpcr);

https://en.wikipedia.org/wiki/IEEE_754-2008_revision (empasis added):

Annex U of 754r recommended that only tininess after rounding and inexact as loss of accuracy be a cause for underflow signal.

In case of FPCR.AH != '1': what is the rationale for tininess "before rounding" (instead of "after rounding")?

[1] Arm Architecture Reference Manual for A-profile architecture (issue J.a), shared/functions/float/fpround/FPRoundBase on page J1-12437

pmor
  • 5,392
  • 4
  • 17
  • 36

2 Answers2

2

what is the rationale for tininess "before rounding"

Because that is how some implementations did it before IEEE 754 specified that detail about tininess.

Between the smallest positive normal value and the next smallest (a subnormal) there is a "grey zone".

Grey zone near DBL_MIN

Should a computation, before rounding land in that zone, there is a difference in functionality concerning "tininess before/after rounding" as it relates to underflow and signaling.

So why would IEEE 754-2008 allow underflow for tininess "before rounding" and "after rounding"?

Fuzzy memory / speculation:

  • This is a very narrow corner case and IIRC was not considered in early IEEE 754.

  • Manufactures of FPU hardware and software authors did not uniformly detect underflow in the same manner, some before, some after rounding.

  • IEEE 754 today allowed both (thus an implementation detail), yet favors only tininess after rounding to nudge for future uniformity.

  • As an option via FPCR.AH, this allows compatibility with prior work or for moving toward the IEEE recommendation.

IMO, assessing tininess after rounding causes for less exception handing. It also prevents the case of a rounded answer of smallest positive normal value, yet still underflow.

I could see assessing tininess before rounding is easier to implement and test in hardware/software.

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
  • Re: "some implementations did it before IEEE 754" it does make sense (like "truncation-toward-zero", see C99 rationale, 6.3.1.5 Real floating types). Re: "It also prevents the case...": I thought about that, and I agree. Then any ideas _why_ does Annex U of 754r recommends tininess "after rounding"? – pmor Jun 07 '23 at 10:56
  • @pmor --> is the 1st reason. Another might be symmetry with _overflow_. Is overflow exception determined before or after rounding? I'd have to review. – chux - Reinstate Monica Jun 07 '23 at 11:03
  • 1
    Re: "the 1st reason": OK. Re: "overflow": 7.4 Overflow: "... exceeded in magnitude by what would have been the _rounded_ floating-point result ..." – pmor Jun 07 '23 at 11:10
  • @pmor Hmmm, given [that](https://stackoverflow.com/questions/76415860/what-is-the-rationale-for-tininess-before-rounding-instead-of-after-rounding/76416363?noredirect=1#comment134756909_76416363), it does sound more symmetric then for underflow exception to fire after rounding than before. – chux - Reinstate Monica Jun 07 '23 at 11:15
  • 1
    @pmor But actually "some implementations did it before IEEE 754" is not the reason (this is actually the opposite, where Intel was generally regarded as the reference implementation), according to the discussions that occurred in 2006 in the stds-754 list. See [my answer](https://stackoverflow.com/questions/76415860/what-is-the-rationale-for-tininess-before-rounding-instead-of-after-rounding/76424791#76424791). – vinc17 Jun 07 '23 at 15:29
2

The reason is that detecting tininess "before rounding" is simpler to implement. Another reason is that "after rounding" (i.e. the alternative tininess detection) is more difficult to understand. In 2006, David Hough said in the stds-754 list: "the definition of tininess after rounding depends on a hypothetical rounding to a hypothetical intermediate format that has confused everybody who has ever tried to implement underflow." He also said: "Tininess before rounding keeps underflow independent of rounding mode." (But note that overflow depends on the rounding mode, and this does not seem to be an issue.)

The reason is not because some implementations did it before IEEE 754 specified that detail. On the opposite, "after rounding" was for some time proposed to be the standard, and on this subject, Dan Zuras said in the stds-754 list in 2006: "The reason underflow after rounding was selected for section N is because Intel did it that way & it has become a de-facto standard." (Section N probably corresponded to Annex U mentioned on Wikipedia.) Note that there were other reasons for "after rounding", such as symmetry with overflow (which is always after rounding) and avoiding some rare useless underflow exceptions.

vinc17
  • 2,829
  • 17
  • 23