IEEE 754R minutes from May 30, 2003

• Attendance
• Decimal. Oh joy.

Attendance

The IEEE 754R committee met at UC Berkeley on May 30, 2003. In attendance were

• Dan Zuras, self
• Joe Darcy, Sun
• Leonard Tsai, self
• Eric Schwarz, IBM
• Jason, CS
• Ren-Cang Li, Univ. of Kentucky
• Jim Thomas, HP
• Jeff Kidder, Intel
• W. Kahan, UC Berkeley
• Dick Delp, self
• John, Hauser, self
• Peter Markstein, HP
• Mike Cowlishaw, IBM
• Michael Parks, Sun

Note taker: Jeff Kidder, Intel Corp.

Decimal

Kahan: "An ULP(x) is the difference between the two nearest representable values to x. "

Because of exponent under/overflow, the amount of available redundancy is reduced at the ends. Also, the "range" flag will get raised more near the end of the range.

We all agree that numerical values should be discussed in a radix independent way, and that we should distinguish numerical values from objects that contain additional information.

Sections: Need a separate section for people who care about the string representations. What is the ideal scaling

Yesterday's Call for topics: (*+ handled; *- TODO)

• Goal for the day: settle the arithmetic
• *+ Result not normalized
• *+ Result is value + Format
• *- NaN's and Conversions
• *- Mixed Operations
• *- Decimal types in languages
• *(July) Expression Evaluation
• *- What other operations are supported (ILOGB, nextafter) and how
• *- Names
• *+ If the format matters, how do we get the format
• *- Exposing bits
• *+ NaNs as results (invalid DPD codes, etc)
• *- Should infinite results be fully defined
• *+ Should rescale (or other operations) be added to 754r
• *+ New flags/classes needed? Normalized? Extreme exponent
• *- String conversion (e.g., "00.0")

What was expected:

Discussion snippets:

• We don't want to force people into architectural flags
• Doesn't want the checking to take much time
• We should just leave out any feature that isn't agreed is needed
• Propose: Kahan's flag is the invalid flag (so we don't add new state)
• Don't want to overload Invalid any more than it is, for something only used for decimal
• Speed is unlikely to matter when performing I/O
• Someone who has rules to follow based on data not provided from elsewhere
• If the data is in the wrong format then it should be checked at the source
• Assume that the choice of names is up for grabs
• Quantum: the unit in the last written place, i.e., 10^scale
• Our goal is to enhance the probability that the non-expert user code won't screw us up when it comes over the net. It is not for experts. Non-experts look at decimal numbers as fields. They expect that numbers will either naturally fall into an expected format or they requantize to "coerce" into the right format (specified by the programmer with a decimal floating point template (possibly a variable) for the field), and may include a rounding rule. Examples: COBOL, PL1, Java.
• Rounding rules: how does a user get to the 0.1 rounding level?
• requantise(expr, template, rounding/threshold)
• Convention: evaluating an expression will be kept to, say 31 decimal digits.
• so requantize(A+B/C, template, rounding) leads to a question of
• If we agree to the maximum width (e.g., 31) that would improve reproducibility.
• Should it be system specific? Then the standard wouldn't be a standard.
• Java supports set scale passed into each decimal operation
• That's horrible. Could be mitigated by syntax. I could live with that.
• How does COBOL 2002 do its expression evaluation
• a = b + c * g;
• compute b + c * g to 32 decimal FP (32 specified in the standard)
• then requantize to the type of a and assign
• Do we just want "evaluate to widest"?
• Do we also want "evaluate maintaining quantization"?
• C doesn't allow a way to specify what evaluation is in use.
• Need to define the set of primitives that a set of end users can use to do numeric calculations
• Standard could define
• x = eval(expr, rules)
• requantize(x, specification)
• What happens if coercion is impossible? Exponent over/underflow; or field overflow.
• Coercion happens often. Usually just rounds off digits from the right.
• If a field overflow occurs, someone might want to know:
• checkQuantum(expr, template): causes checking that quantum of the result matches the template
• or
  x = eval (expr, rules)
  checkQ(x,spec)
• or
  checkQ(x,...) := (requantize(x,...) === x)
• May also want to check each assignment in a block of code in the expr
• The banker wouldn't care if the final quanta is correct, rounding occurred, but the result is exact
• A key case is a sum of items that are supposed to have the same quantum
• Can just use the first (or any) value as the template for the chackQuantum of the sum
• With the new checkQuantum and inexact, we can get the right semantics.

• What do you cause to happen from checkQuantum?
• If we want to check often within a block then there are several
• Implementation considerations,
• One way or another, need to OR together a bunch of things
• What happens if requantize encounters a "field overflow"
• Failing case: reQ(1234E+6, -2)
• IBM raised Invalid and returned a NaN
• Result just won't fit into the field
• Should it be rounded? Should it be Inf? Do we need a new Not a "something"?
• The NaN is what you deliver when anything else you deliver would be more confusing.
• Consensus: if we can't produce the requested scale, raise Invalid, return NaN
• Which NaN?
• Should have a name ("Quantum Violation" or "Quantum Error")?

• A potential mental model

  { clear state run with checking check state do something if state set }
• Could be state, or could be a software flag that is implemented by ORing together
• 754r could just specify the operation
• Using invalid would allow using the same state we already have.
• Invalid operation seems too strong.
• CheckQuantum should be defined in 754r as a predicate
• inside the loop it could be implemented as cQ ||= flag
• These are going to come up again when we cover exception handling
• The scope is an important aspect of exception handling
• COBOL #pragma checkQuantum { a = ...; b = ...; ... }
• C #pragma checkQuantum (0.0001) { a = ...; b = ...; ... }
• Could be used implicitly in languages that have decimal semantics
• Some folks want predicates some want flags
• The language may hose us on everything
• The predicate has the advantage of enforcing data ordering
• Let's defer the details until we talk about exceptions

NaNs:

• How do NaNs propagate through decimal operations
• Invalid DPD NaNs.
• Store the NaN Data in the decimal encoding
• i.e., an "invalid declet" with e.g., 999s
• We are trying to make more shoulds shalls.
• Is the information in radix 10 or radix 2
• Could say "If NaN is properly encoded it shall be preserved"
• but allow implementations to change "invalid declets"

Proposed language: "shall preserve properly encoded declets in the significand" [and we are silent on the exponent continuation and invalid declets] (Conditioned on the shall language being in the NaN)

• A vote 11 for, 1 against, 2 abstain
• The one objection was that the "shall" should be "should"

Checking an implementation against the standard:

• Want a compare with all NaNs compare equivalent, but -0 compares different from +0.
• Want a similar thing with decimal that checks the scale and value.
• Could write it with things we have now: (isNaN(x) and isNaN(y)) OR (x===y)
• "Equivalent in the model"
• Don't need to expect it to be fast.
• Let Joe define the predicate and include it in the appendix

Next meeting:

• Thursday 10 July, 2003 1-5PM - host David Hough / Alex Liu Sun, Santa Clara (Menlo Park?)
• 30. Expression Evaluation Rules (part 1) - David Hough (July)
• 31. Expression Evaluation Rules (part 2) - Jason Riedy (July)
• 33. Alternate Expression Evaluation & FMA Compiler Directives - David Hough (July)
• 34. May we combine wider operands to narrower results? - Peter Markstein (July)
• Some interest in going from 10-5 if possible.