|
There may be an end to precision (does anybody really need quad?) but
there's no end to range. The only realistic way to deal with extended
range is to use polyadic operators of the general form f([x, m],
[x, m]) -> [x, m] (where x is exponent and m is
significand, considered as separate values). This in turn requires
integral operations f(m, m) -> [x, m] (multiply) or f(s,
m, m) -> [x, m] (add) with s a scaling factor
(prenormalization), the result m properly normalized and
rounded as appropriate, and the resulting x reflecting the
scaling arising from normalization.. However, the representation of m
is of course normalized, so while these operations are integral they
are not integer, but what are commonly called fraction types.
In our terminology, we call the above operation a scaling fraction. Essentially all these range problems can be handled with the above model. Because the exponent and significant are separate and integral, they may be represented in any integer size supported by the hardware. In particular, the exponents may be accumulated in 64- or 128-bit integer if desired. I have an easy implementation to deal with inf/NaN, which I will sketch out if there's interest. The hardware is no more difficult (and largely the same as) a standard FP unit, except for the unusual number of arguments and results. The solution generalizes naturally to reductions such as the bio guys need, although that is not the only use of course. Ivan p.s. NOTE: this described mechanism is proprietary to and the property of Out-of-the-Box Computing and will be patented. It (and any subsequent details) is disclosed for purposes of potential standardization, and if so standardized the intellectual property involved will be made available as required by the IEEE rules. However, if not accepted for standardization, it is and will remain the property of OOTBC and no release of rights is made by this disclosure. Please do not pass this information beyond the confines of the committee unless and until it is formally incorporated in a Draft Standard for public review. r754@xxxxxxxxxxxxxx wrote: To: r754@xxxxxxxxxxxxxx Cc: stds-754@xxxxxxxx, ejr@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [...] my rant on reductions... Date: Fri, 12 Aug 2005 17:07:31 -0700 And r754@xxxxxxxxxxxxxx writes: - The REAL solution is to provide them with the ability to take - long products & sums & not worry about overflow or underflow. No, the REAL solution is to use one of the zillion packages out there that already solves this problem. Some are listed at http://www.cs.ubc.ca/~murphyk/Bayes/bnsoft.html If you want to support these through reduction operations, please provide examples where the reductions would make some of these packages easier to read, debug, and modify. JasonI fear the answer may not be so simple, Jason. While I am not familiar with this particular package, the package these people are using IS a standard package for Markov modelling with Bayesian statistics. It appears that such standard packages are unfit for modelling something as complex as proteins as utterances over an alphabet of amino acids. The calculations involve far too much dynamic range for double. While it IS true that double extended or quad would be barely sufficient for the toy problem the graduate student was working on, the REAL problems require even more dynamic range. Standard packages that are good for the rest of the world don't begin to approach the range needed. They need our help. - Dan |