Resending two items that got lost yesterday...

[Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>]

| =============================  06/07/19  19:01:16  ==========================
| Date:  Wednesday 19 Jul 2006 at 2:37 p.m. EDT     (2006-07-19 18:37 GMT)
| To:    stds-754                            <stds-754@xxxxxxxxxxxxxxxxx>,
|        (backup)                                   <stds-754@xxxxxxxxxxx>
| From:  Michel Hack (1-914-784-7648)                <hack@xxxxxxxxxxxxxx>
| Subject: Regarding Items 15 and 17 on the agenda today (decimal 
floating-point)
|
| Well, we still suffer from an availability problem, and I guess IBM
| is as much to blame as Intel for this.  DecNumber (whatever version)
| is simply not the right library, even if among its functions are some
| that match the functions being evaluated.  Of course, if nothing else
| is available to evaluate software DPD performance, it will have to do.
|
| One thing that is missing if we are to evaluate the min/avg/med/max
| numbers is what the distribution of test cases is.  Minimum numbers
| are almost meaningless as one can always pick some special cases for
| bypass processing (e.g. zero or inf), and a library that does not
| use bypass processing will differ by orders of magnitude from one
| that does.
|
| Most functions measured depend only on the proportion of special cases.
| Some depend on the number of significant digits.  More information is
| required for Addition and Comparison, however, because the interesting
| cases are when the exponent difference is small or zero.  If exponents
| are uniformly distributed, most cases would fall into the non-overlap
| case, which does not reflect the true complexity of these functions.
|
| So I would like to know what the proportion of special cases was
| (zero, Inf, NaNs), what the range of significance was, and how the
| exponents were distributed -- or whether the input was simply random
| bitstrings, in which case the proportions could simply be derived.
| In this last case I'd like to know how many cases were tried, so I
| can get a feel of how many of the special cases are likely to have
| arisen by chance.
|
| Michel.
| =============================  06/07/19  19:40:01  ==========================
| Date:  Wednesday 19 Jul 2006 at 3:39 p.m. EDT     (2006-07-19 19:39 GMT)
| To:    David James                             <david.v.james@xxxxxxxxx>
| CC:    stds-754                            <stds-754@xxxxxxxxxxxxxxxxx>,
|        (backup)                                   <stds-754@xxxxxxxxxxx>
| From:  Michel Hack (1-914-784-7648)                <hack@xxxxxxxxxxxxxx>
| Subject:  Your 7.5 scaledProduct operations
|
| (Page 68 of JggDvj2004Oct12 -- July 12, 2006)
|
| Not sure this will reach you before this afternoon's meeting, but
| here are some corrections/suggestions.
|
| The function Scalar() is not defined, but I see what you mean: it
| is described by step (b) of 7.5.2.  I suggest calling it Scale()
| because "Scalar" gives a very confusing impression.  Step (b)
| would then mention Scale(v) explicitly (just as step (c) mentions
| the Rescale() function).
|
| The term "t" in table 7.37 is not defined, but again I see what the
| mistake is.  "t^-k" should be "v * base^-k", and two rows later "t"
| should simply be "v".
|
| (Also replace Scalar() with Scale() on page 69, 7.5.3 and 7.5.4)
|
| Michel.
Sent: 2006-07-20 14:13:05 UTC