754R Minutes - 15 January 2016
Recorded by David Hough

The fifth meeting of the 754R revision group was a teleconference
on 15 January 2016, convened at 8:00am and adjourned at 9:30am 
Pacific Standard Time.

Teleconference participants:

David Chen
Marius Cornea
Mike Cowlishaw
Jim Demmel
Ken Dockser
Hossam Fahmy
Warren Ferguson
David Gay
Ivan Godard
Michel Hack
David Hough
David Lutz
Terje Mathisen
Jason Riedy
Eric Schwarz
Jim Thomas

The IEEE-SA slides were referred to; the URL is:

 https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.pdf

Officers:
A request for volunteers to serve as vice-chair and secretary was met
with deafening silence.

Meetings:
The next meetings will be held on 12 February and 11 March 2016,
from 8:00 AM to 10:00 AM Silicon Valley time, which will be UT-8 in January
and February.

Website:
The website 754r.ucbtest.org, left over from the previous effort,
is being used for the time being.

=====

We examined the editor's draft 204 incorporating the decisions of the 
previous meeting and approved the changes.

For section 3, 
Michel Hack proposed in email minimum requirements for p and emax.
These were adopted in slightly modified form:

   For binary formats, the precision p should be at least 3, as some
   numerical properties do not hold for lower precisions.

   Similarly, emax should be at least 2 to support the operations
   listed in 9.2.

ACTION for editor: incorporate as notes.

Previous minutes:
it would be helpful to define "operation" and "floating-point operation"
in the glossary.
Editor proposes a definition of floating-point operation as one with 
one or more floating-point operands or results.    Editor could not come
up with a definition of operation useful enough and non-obvious enough to
be worth putting in the glossary.    Nobody else could either.
ACTION for editor: add "floating-point operation" to glossary.

In section 9, there is a major effort required to disambiguate "function"
between the senses of "mathematical function" and "floating-point operation
in function syntax."
Section 9.1 defines "floating-point operations" in terms of 
"mathematical functions."
ACTION item for Hough: propose wording changes for section 9 to clarify
this distinction.

Pow - Hossam Fahmy produced a list of ten additional special case
definitions for infinite operands that apply to both binary and decimal
formats.
Hossam proposed separating certain of these special cases and adding a note 
suggested by Jim Thomas explaining that a language standard might define
an additional power function that defined as many rational-power cases as
possible.
ACTION for editor: reorder pow cases and incorporate that note in the
draft.

The descriptions of pown and pow have parenthetical remarks:

 For the pown function (integral exponents only):

 For the pow function (integral exponents get special treatment):

in which "exponent" refers to the second operand or power, as defined
in Table 9.1, but which could cause confusion with the exponent field in
a floating-point representation.    But the following change seems to
avoid the problem:

 For the pown function (integral powers n only): 
 
 For the pow function (integral powers y get special treatment): 

ACTION for editor: modify draft accordingly.

Jim Thomas requested that all standard operation names be in bold font.
This doesn't change any meaning but costs some pain for the editor.
ACTION item for editor: bold operation names everywhere except section 9.
If that goes well, we will consider doing it for section 9 next time.

Jim Thomas reported from the C Floating-Point Working Group that an issue
had arise around the subexceptions of invalid and division by zero.
These are listed in section 7 and mentioned in section 8.
We agreed that the rules for subexceptions are meant to follow the same
rules as the exceptions:   for operations in the standard, they are only
raised to reflect the intended result of the operation, and not as
gratuitous effects of intermediate steps.     But where and how to say this?
ACTION item for Jim Thomas: propose wording to accomplish this.

Since we had finished our agenda before running out of time, Jim Demmel
introduced the topic of repeatable summations, an area in which a number
of his colleagues and students are working.     The idea is to get
summations which are independent of the order of summation and the number
of processors doing the work.     This could be done by specifying correct
rounding or by specifying an algorithm that was not quite correctly rounding
but portable and much faster.      The cost/benefit ration much favors the
latter approach.    Jim and his colleagues will provide more detailed 
information and proposals by email and at subsequent meetings.
This would be fodder for the next revision after 2018.

That brought to mind the tail operations which were in 2008 for a while 
and then dropped.     They can be defined to be exact for normal cases:

a + b - computed(a+b)
a - b - computed(a-b)
a * b - computed(a*b)
a - b * computed(a/b)
a - computed(sqrt(a))**2

In that form they are useful for building higher precision out of lower.
Perhaps they were dropped from 2008 because of uncertainty about 
how much to specify  exceptional cases, or because the last three are
easily build out of FMA, while the general solution for the first two,
an operation to compute a+b+c, seems rather high cost per benefit.

MKL now has a "reproducible" flag which can be set to obtain more
reproducible results - so perhaps this is an idea whose time has come
commercially.     There is increasing academic and research interest in
the entire question of reproducing numerical results obtained by
other investigators at other institutions using other hardware and other
software.