RE: 754R vs pow

["David James" <dvj@xxxxxxxxxxxx>]

Mark,

Certainly that is possible and pow could be a case in point, if consensus
cannot be reached. I find this an interesting case: no-one complained with
the text, but observed problems in a tabular format. Yet, tabular formats
are found not to be useful...

However, this is not the only cause for concern. We would have to also
exclude
  * every rounded operation that could underflow (and round differently)
  * processing of sNaNs and qNans  (that encode differently)
  * logB/scaleB (that have distinct operand formats)
  * fusedMultiplyAdd (with distinct NaN precedences)
  * decimalCharacters, to and from (with distinct qNaN/sNaN processing)
to achieve the purpose statement. It would certainly please those that like
a thin
standard, but I'm not sure much useful would be left(:>).

Cheers,
DVJ
  -----Original Message-----
  From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of Mark Erle
  Sent: Friday, June 01, 2007 12:31 PM
  To: dvj@xxxxxxxxxxxx
  Cc: David Hough 754R work; Jim Thomas; stds-754@xxxxxxxx
  Subject: RE: 754R vs pow



  David James wrote:
  >  So, one either has to change the purpose or meet the purpose...

  I interpret the purpose statement as pertaining to the operations defined
in the standard, not all conceivable operations.
  With this understanding, we are at liberty to restrict the number of
operations in the standard.

  Regards,
  Mark


  Mark A. Erle



        "David James" <dvj@xxxxxxxxxxxx>
        Sent by: stds-754@xxxxxxxx
        06/01/2007 03:05 PM Please respond to
              <dvj@xxxxxxxxxxxx>


       To "Jim Thomas" <jwthomas@xxxxxxxxxx>, "David Hough 754R work"
<754r@xxxxxxxxxxx>, <stds-754@xxxxxxxx>
              cc
              Subject RE: 754R vs pow







  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.
  >> >
  >> >
  >> >
  >> >