RE: more on rogue comment: IEEE 754R and Reproducibility

["David James" <dvj@xxxxxxxxxxxx>]

David,

Myself and the MSC both share your goal, as evidenced by the
extract from Monday's MSC meeting minutes:

  "The 754 ballot review committee is directed by the MSC to ensure
  that their standard content reflect the unchanged PAR scope and purpose."
  From:
  http://grouper.ieee.org/groups/msc/MSC2007-07/Minutes2007-07-09a.pdf

I also have concerns with options and ambiguous definitions.

However, IMHO:
  * Item (4) is not relevant to "reproducibility",
  * Item (5), location of Annex material, is personal style;
    the document is consistent with common IEEE style usage.
    However, the use of should/shall is much too informal
    in the Annexes and should be fixed.

Cheers,
DVJ


> > -----Original Message-----
> > From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of David
> > Hough 754R work
> > Sent: Tuesday, July 10, 2007 11:27 AM
> > To: stds-754@xxxxxxxx
> > Subject: more on rogue comment: IEEE 754R and Reproducibility
> >
> >
> > > > > You are introducing a comparable requirement into floating-point,
> > > > > by demanding reproducibility in parallel codes.
> >
> > Currently Annex B.3 states
> >
> >  "Languages should provide means for programmers to specify
> > reproducible results that are identical on all platforms
> > supporting that language and this standard, for operations
> > completely specified by this standard"
> >
> > without explaining much about what that means.    The intent is
> > that languages
> > should provide means to suppress, when that's desirable,
> > gratuitous numerical variations among platforms, revolving around
> > associativity foremost and intermediate precisions as well, and
> > many other
> > aspects of secondary importance.      It is not intended to help with
> > irreproducibility built into the semantics of a particular
> > program running
> > on any platform (such as multithreading based on dynamic workload).
> > Nor is it intended that implementations of the same algorithm in
> > different
> > languages should produce the same results; I don't see any way to specify
> > that technically even if it were desirable.
> >
> > (And now, looking at Annex B and C, I don't see anything about
> > the default
> > widenTo method for expression evaluation.
> > I would expect it to be language-defined.)
> >
> > > However, I would agree that it is unreasable to request/demand that
> > > unrelated changes be coupled to the repeatability mantra. Thus, the
> > > following would appear unnecessary:
> > >   4) Identical decimal encodings be used.
> >
> > It's just possible that the standardized API's for converting
> > decimal encodings
> > might not be universally implemented efficiently enough to be
> > suitable for
> > portable code, so as usual people will roll their own... with subsequent
> > latitude for error which would be less likely to arise if there
> > were only one
> > decimal encoding.    So it's one possible unlikely source of error, even
> > if it's not in the same class as rounding errors.
> >
> > >   5) Annex material be moved to other clauses.
> >
> > How many people are aware of the current reproducibility recommendation
> > in Annex B.3?     How much weight does a "normative"
> > annex carry that's all "should" and no "shall" anyway?
> > One would prefer to explain to a reader that the division of normative
> > and non-normative material into body and annexes followed some logical
> > order weightier than a series of frequently-reversed committee votes.