RE: 754R vs pow

["David James" <dvj@xxxxxxxxxxxx>]

Jim,

I have seen many documents change in dramatic ways once they
entered the Sponsor Ballot process, often for the better.

The Sponsor Ballot reviewers are the IEEE's attempt to ensure
that documents have passed the muster, when reviewed by industry
experts (ignoring the fact that there is no practical way to
identify industry experts...).


> > Under discussion now are farther reaching substantive changes, for
> > reproducibility, that go well beyond what the working group concluded is
> > reasonable.

There is a bit of a dilema here. Please review:

  1.4 Purpose
  This standard provides a method for computation with floating-point
  numbers that will yield the same result whether the processing is
  done in hardware, software, or a combination of the two. The results
  of the computation will be identical, independent of implementation,
  given the same input data. Errors, and error conditions, in the
  mathematical processing will be reported in a consistent manner
  regardless of implementation.

which (I believe) is in the PAR and has not changed during Sponsor ballot.
So, one either has to change the purpose or meet the purpose...

As per the recent reproducibility discussions, I remain concerned
that the discussions are too abstract and (not surprizingly) have
thus led to fear of the unknown. IMHO, this task can be reasonably
contained and is valuable. I will attempt to clarify in an email
later today.


Cheers,
DVJ



> > -----Original Message-----
> > From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of Jim
> > Thomas
> > Sent: Friday, June 01, 2007 11:28 AM
> > To: David Hough 754R work; stds-754@xxxxxxxx
> > Subject: Re: 754R vs pow
> >
> >
> > There's a more basic point here. The 754R working group did not attempt
> > to specify pow, nor ten other functions that have been added during the
> > ballot review process. To the contrary, it concluded that normative
> > standardization of any transcendental functions is not appropriate at
> > this time, though included some of them in an informative annex as "the
> > working group's consensus on directions that future standard revisions
> > should address." During the ballot review process, the annex has changed
> > to normative (optional per function) and expanded substantially. Under
> > discussion now are farther reaching substantive changes, for
> > reproducibility, that go well beyond what the working group concluded is
> > reasonable. These changes would be made without the breadth of
> > experience and open representation and process of the working group,
> > which was disbanded when the draft first went to ballot. This is not the
> > time to be adding new features. For the next ballot, voters might no
> > longer assume that the draft is, as it claims, "a product of the
> > Floating-Point Working Group".
> >
> > -Jim Thomas
> >
> > David Hough 754R work wrote:
> >
> > > All the arguments back and forth reaffirmed my belief that 754R
> > should not
> > > attempt to standardize "pow."     The following functions might be
> > > profitably standardized now:
> > >
> > > pown(x,n) x**n for integer n
> > > compound(x,n) (1+x)**n for integer n
> > > rootn(x,n) x**(1/n) for positive integer n
> > >
> > > ===
> > >
> > > and maybe:
> > >
> > > explog(x,y) exp(y * log(x))
> > >    with intermediate divbyzero, underflow, overflow suppressed
> > >    but with these invalid cases suggested by the formula:
> > >    x < 0,  (0,0), (inf,0), (1,inf)
> > >
> > > ===
> > >
> > > with the following left as exercises for future generations:
> > >
> > > zpow(u,v) for complex u and v
> > > and
> > > rpow(x,y) which matches Re(zpow(complex(x),complex(y)))
> > >    whenever Im(zpow(complex(x),complex(y))) is identically zero
> > >
> > > Depending on how zpow is defined, rpow might or might not
> > differ from explog.
> > > Languages having complex types might want to bind their "pow"
> > differently
> > > from languages that don't, for all I know.
> > >
> > > ===
> > >
> > > Unlike x*y or hypot(x,y) or even atan2(x,y),  pow(x,y) is not
> > in any sense
> > > symmetric in x and y; usually one is the continuous
> > > independent variable and the other is a parameter, fixed but
> > perhaps unknown.
> > > 754R has more immediate issues to deal with than sorting that out.
> > >
> > > Having n be a non-continuous integer parameter of pown,
> > compound, and rootn
> > > perhaps makes it easier to accept that the function values are
> > 1 when n is 0
> > > for any x whatever, and avoids the issues of infinite n.