[Cfp-interest] FUNCTIONS first attempt at defining calling sequences for reduction operations
Stephen Canon
scanon at apple.com
Tue May 18 16:07:21 PDT 2010
As discussed during the meeting, the lengths should have type "size_t".
The question remains of what the type of the scale factor for the scaled functions is. "int" may not suffice, as it is easily overflowed for reasonable sized vectors, even on a 32-bit machine[*]. As I see it, the "desirable" constraints on the type of the scale factor are:
1. it should be a signed integer type
2. unscaling can easily be done using library functions.
3. it should be wide enough to make overflow unlikely, when possible
To my mind, this points to "long" as the type for the scale factor. Rescaling can be done with scalbln( ), which was standardized in C99. On most 64-bit platforms whose name isn't "Windows", long is 64 bits, which gives plenty of headroom for reasonable uses, and Windows will probably never implement whatever we codify, anyway.
Additionally, there is the matter of what these functions should do if the scale factor is overflowed. 754 says:
"If the scale factor is too large in magnitude to be represented exactly in the format of sf, then these operations shall signal the invalid operation exception and by default return quiet NaN for pr, and also for sf if integralFormat is a floating-point format."
In hindsight, I might have preferred that they over/underflow to inf/zero, but I don't have a good argument for it; it seems reasonable to honor to the 754 behavior. One detail is that to stick strictly to the 754 behavior, if you overflow scale, you can't just return NaN; you need to continue processing the inputs to ensure that there is no infinity lurking that would force you to return inf instead.
- Steve
[*] for suitable definitions of "easily" and "reasonable". I don't think that a product of a billion modestly scaled values on a 64-bit platform is too terribly far fetched. One would like to support such usages if it can be easily done.
On May 14, 2010, at 4:32 PM, David Hough CFP wrote:
> Here's an orthogonal list.
> We could reserve all these names.
> Let me know how this might be better.
>
>
> /* 754 sum: reduc_sum = sum(p[i]) */
> _FloatN reduc_sumN( _FloatN *p, int n );
>
> /* not 754: scalb(scaled_sum, *sf) = sum(p[i]) */
> _FloatN scaled_sumN( _FloatN *p, int n, int *sf );
>
> /* 754 sumAbs: reduc_sumabs = sum(fabs(p[i])) */
> _FloatN reduc_sumabsN( _FloatN *p, int n );
>
> /* not 754: scalb(scaled_sumabs, *sf) = sum(fabs(p[i])) */
> _FloatN scaled_sumabsN( _FloatN *p, int n, int *sf );
>
> /* 754 sumSquare: reduc_sumsquare = sum(p[i]*p[i]) */
> _FloatN reduc_sumsquareN( _FloatN *p, int n );
>
> /* not 754: scalb(scaled_sumsquare, *sf) = sum(p[i]*p[i]) */
> _FloatN scaled_sumsquareN( _FloatN *p, int n, int *sf );
>
> /* 754 dot: reduc_sumprod = sum(p[i]*q[i]) */
> _FloatN reduc_sumprodN( _FloatN *p, _FloatN *q, int n );
>
> /* not 754: scalb(scaled_sumprod, *sf) = sum(p[i]*q[i]) */
> _FloatN scaled_sumprodN( _FloatN *p, _FloatN *q, int n, int *sf );
>
> /* not 754: reduc_prod = product(p[i]) */
> _FloatN reduc_prodN( _FloatN *p, int n );
>
> /* 754 scaledProd: scalb(scaled_prod, *sf) = product(p[i]) */
> _FloatN scaled_prodN( _FloatN *p, int n, int *sf );
>
> /* not 754: reduc_prodsum = product(p[i]+q[i]) */
> _FloatN reduc_prodsumN( _FloatN *p, _FloatN *q, int n );
>
> /* 754 scaledProdSum: scalb(scaled_prodsum, *sf) = product(p[i]+q[i]) */
> _FloatN scaled_prodsumN( _FloatN *p, _FloatN *q, int n, int *sf );
>
> /* not 754: reduc_prodiff = product(p[i]-q[i]) */
> _FloatN reduc_proddiffN( _FloatN *p, _FloatN *q, int n );
>
> /* 754 scaledProdDiff: scalb(scaled_proddiff, *sf) = product(p[i]-q[i]) */
> _FloatN scaled_proddiffN( _FloatN *p, _FloatN *q, int n, int *sf );
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
More information about the Cfp-interest
mailing list