IEEE 754R minutes from Jan 17, 2002

Attendance and minutes review

The IEEE 754R commitee met Jan 17, 2002 at Intel. In attendence were:

The corrected minutes from November were accepted. The minutes from the December meeting lacked an attendence list, but were otherwise accepted.

Supercommittee draft date

Dan Zuras attended the microprocessor standards supercommittee meeting on Monday night (1/14). They wanted a date for our first draft. The date will be used for planning the assembly of a review committee; six months after that date, we submit our draft to a ballot. The committee, up through this meeting, has been active for one year.

David Hough noted that there were twelve proposals outstanding just from him, and suggested that we will have at least another year working on those.

We tentatively agreed to shoot for a two year deadline (12/2003 supercommittee submission), which we could meet under the optimistic assumption that we finish work on at least one proposal every other meeting. Dan Zuras offered to buy dinner for everyone in the working group if we make that deadline.

Draft review

Dan Zuras recommended that multiply-add be hyphenated. Kahan recommended that we add a definition of what "fused" means, to discourage people from using "fused multiply-add" to mean something else. He pointed to the i860's multiply-add as an example of an operation which did not resemble our fused multiply-add operation. He also observed that there are few (if any) besides him who remember the exact semantics of the i860's multiply-add operation. Hough suggested leaving a single definition for "fused multiply-add" which distinguishes FMA from multiply-add with two rounding errors.

Jim Thomas pointed out that we should use "a widest operand's format" instead of "the widest operand's format" when referring to FMA.

We then discussed quiet operations. Kahan observed that in z := copysign(x,y), x and z must have the same format, but y may have a different format.

There was a question about whether the quiet predicates should be "shalls" or "shoulds". Kahan wished for an fclass function that takes a bit mask to specify a combination of predicates. He agreed to write a proposal for such a function, possibly using the C99 statement as a basis.

There was an argument about whether predicates "return a value" or not. After talking circles for many minutes, we agreed that we will, for the moment, use language to describe the quiet predicates similar to the language used to describe comparisons.

During the discussion the question of the interaction between exceptions and compiler optimizations (which might create spurious exceptions, or lose exceptions) raised its ugly head. When it became clear that was part of what we were arguing, Hough suggested that we defer the discussion to a time when we were not supposedly reviewing past decisions.

Hough observed that, though we use functional notation in the standard, that does not mean the bindings in all programming languages will also use functional notation.

Kahan objected to the phrase "extraordinary accuracy loss" on two grounds. First, the loss is not extraordinary compared to the alternatives; second, it is a loss of significant bits which may or may not result in any actual loss of accuracy. Kahan observed that "denormalization" was a good word, since the marketing people didn't know what it meant and nobody thought it was pejorative. We agreed to go back to the old text ("denormalization loss"), but otherwise defered discussion of the issue (and other underflow issues) until next month.

Hough's changes were otherwise accepted by general concensus. Jason Riedy asked if it would be possible to create a version without change marks, along with the other versions; Hough stated that he would prefer not to battle further with Star Office, but that "anything's possible for a graduate student."

Appendix functions

There was a question about whether the 854 "appendix" functions should actually be in section 9.

Then there was a long debate over logb and scalb. Joe Darcy noted that the definitions of scalb and logb are confusing, and are also completely out of character with the rest of the standard. Because logb and scalb seemed confusing and messy, fast versions were not always implemented -- and so the functions were rarely used.

Jim Thomas pointed out that C99 has two logb variants: logb (with a float n) and ilogb (with an integer n). In order to make logb and scalb work with integers for this standard, though, we need a notion of integer types. At least, we need to say something about the range requirements, unless we are willing to deal with integer exceptions. While there were arguments over the degree to which we need to specify any integer types involved, there was general agreement that we want integer arguments to the logb/scalb pair. We agreed to refer to "signed 32-bit integer formats" for the moment, and argue further another day.

We also argued about what logb should do for subnormal numbers. From a hardware perspective, it would be easier not to worry about normalizing. From a software perspective, we may want the exponent before or after normalization (for bit twiddling or for scaling). C99 standardized on the normalized version. However, whatever we decide, we want something fast. scalb is useful only if it is faster than multiplication; similarly, logb is only useful if it is faster than log. Kahan felt that the performance issues would be substantially simplified if implementations associate tag bits with floating point registers.

Then we argued about what logb should return for infinities, NaNs, and zero. In C99, logb(0), logb(inf), and logb(NaN) are outside of the ordinary range, with specific values defined by macros. Kahan said that one of the nice things about ilogb is that the output for NaN and infinity are defined independent of the type; David Scott suggested that we mandate that logb of 0, NaN, and inf be far outside the valid range, but that the programmer should use isnan and isinf to check for NaNs and infinities.

Hough agreed to try to write a specific proposal which incorporates some of the ideas from the above discussion.

We turned to nextafter with the question "should nextafter signal?" Kahan suggested not, since he could not think of a place where he would care about the signal. Jim Thomas suggested that it should, since C99 does specify a signal, and we might not want to break compatibility over such a minor point.

If x== y return x with no exception (makes a difference with zero); else if x or y a qNaN then the result is one or the other.

Uses for nextafter include : environmental inquiries; checking on convergence; recomputing when you hit a critical argument where something bad happens (hitting the stagnation point in a flow problem); business calculations where you're computing internal rate of return, and there are two of them -- make a minimal bump to figure out how the perturbed flows change. Different directions for borrower and lender.

We agreed to have a nextup function, defined as nextafter(., INFINITY). We also decided to remove the predicate "x <> y", since it is already in table 4. There was some question over whether we needed the functional form unordered(x,y) for the predicate x ? y, and whether it might not belong in the quiet predicates section.

Action item: Jim Thomas will send David Hough a list of functional names for operands.

We turned to runtime conversion functions with the question: do we want conversion to quad if quad is the largest type supported? Conversion to narrower formats is a good idea, too (otherwise we can get double rounding). We agreed to table further discussion until we talk about extended formats. The main point is that we want functions that convert at runtime, complete with signalling. Hough supported the idea of having this be generic in the sense of the others (in that it will represent a family of functions). Dan Zuras suggested we say there will exist functions that do the conversions, but not necessarily specify names. We decided that we want a name, so that we can have a common terminology, but we recognize that different language bindings may employ different names.

We turned to nearbyinteger, which would convert a number to an integer without an inexact exception, obeying appropriate rounding modes. Kahan stated that there are two kinds of integer conversions: deliberate conversions like floor, ceil, AINT, and RINT, which should not signal inexact; and inadvertent / implicit conversions, which should signal inexact. Jason Riedy asked what this meant for C macros. Jim Thomas asked whether this meant that casting a double to a float should not generate an inexact; Kahan replied that indeed it should not, since the cast is explicit. David Hough suggested that inexact should be signalled if the result depends on the dynamic rounding mode. Hough then proposed that instead of adopting nearbyinteger, we change section 5.5 to say explicitly that no inexact arises.

Jim Thomas objected to invalidating all the places where someone says "This function implements ..." It seemed that we were changing it largely for the sake of simply changing it. There was general agreement that this is a fair objection.

Why not say that both functions should exist? Hough is opposed to having both, since one of them is useless. 754 didn't choose, so we can't be incompatible with that. Proposal: Add to the 754 spec that the (unnamed function) does not generate an inexact flag.

There was general agreement on proposal. Kahan wants a note that says implicit coercions from one type to another in assignment should use instructions that generate the inexact signal, whereas languages that allow no implicit casts should not.

End notes and scheduling

In some future meeting, we need

The next meeting is 21 Feb, 1-5. Future morning meetings shelved until we have more remote interest. Upcoming meetings are

754 | revision | FAQ | references