RE: rogue comment: IEEE 754R and Reproducibility (revised to clocks and mistakes :>)

["David James" <dvj@xxxxxxxxxxxx>]

Nick,

> > You are introducing a comparable requirement into floating-point,
> > by demanding reproducibility in parallel codes.

I don't recall "demanding" anything; nor do I have such authority.
If I had any such authority, the 754 draft would have used
FrameMaker and normative tables would be present throughout.

Back to the issue at hand...

IMHO, it does seem reasonable to request that:
  1) The 754 standard does not prevent repeatability.
     Ambiguous/optional definitions must be clarified and/or
     selected throughout.
  2) The 754 standard recommends a repeatibility mode be implemented
     and (if implemented) provides guidance on that mode's behavior.
  3) The 754 standard conform to its purpose, as stated in the
     original PAR, in which repeatability is a primary objective.
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.
  5) Annex material be moved to other clauses.

Cheers,
DVJ


> > -----Original Message-----
> > From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of Nick
> > Maclaren
> > Sent: Friday, June 22, 2007 1:36 PM
> > To: stds-754@xxxxxxxx
> > Subject: RE: rogue comment: IEEE 754R and Reproducibility (revised to
> > clocks and mistakes :>)
> >
> >
> > "David James" <dvj@xxxxxxxxxxxx> wrote:
> > > There is a bit of confusion herein.
> > > There are two time of clocks:
> > >   1) Circuit clocks, that run processor pipeline, etc.
> > >   2) Timing clocks, that provide accurte time-of-day
> > >      synchronization between entities.
> > > Examples of (2) include:
> > >   IEEE p1588
> > >   IEEE p802.1as
> > > I believe you quotes to the literature are on the topic of (1),
> > > my statement was on the topic of (2).
> >
> > Yes, you are right, as far as that goes.
> >
> > And, if we were talking about the synchronisation of separate
> > processes (say, at an MPI level), it would be correct.  But, once
> > we are talking about reproducibility at the cache coherence level,
> > there is a requirement for the timing clocks to reflect the circuit
> > clocks to perfection.
> >
> > > > > the (main) technical mistake, and not the managerial ones.
> > >
> > > IMHO, the managerial mistakes are the primary cause for
> > > most technical mistakes. You can't really separate the two.
> > >
> > > I would certainly hesitate to state there was any one
> > > "(main)" technical mistake; there were many. The "main"
> > > ranking depends on your area of interest.
> >
> > Not at all.  There was one that stood out, because it was actually
> > insoluble.  Even if there had been no managerial mistakes, it would
> > have caused the Itanic to fail in its original objective.
> >
> > If you know of a second INSOLUBLE problem that was assumed to be
> > soluble by the initial proposal, you know more than me.  And, when
> > I say insoluble, I mean theoretically (i.e. mathematically) insoluble,
> > not just practically insoluble.
> >
> > You are introducing a comparable requirement into floating-point,
> > by demanding reproducibility in parallel codes.
> >
> >
> > Regards,
> > Nick Maclaren,
> > University of Cambridge Computing Service,
> > New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> > Email:  nmm1@xxxxxxxxx
> > Tel.:  +44 1223 334761    Fax:  +44 1223 334679