Re: This month's agenda & my rant on reductions...

[r754@xxxxxxxxxxxxxx]

> Date: Fri, 12 Aug 2005 19:38:05 -0700
> From: Ivan Godard <igodard@xxxxxxxxxxx>
> To: r754@xxxxxxxxxxxxxx
> Cc: stds-754@xxxxxxxx
> Subject: Re: This month's agenda & my rant on reductions...
>
> > From your description of the bio problem, it sounds like nearly all the
> primitive operations would trap nearly all the time. Is that so? If so,
> I don't see why the reductions proposals would improve matters. Our
> Mill hardware supports reductions directly, but that wouldn't help on
> this one. We too would promptly get a NaN/inf and that's all she wrote,
> despite the special performance hardware. <br>
> <br>
> Of course, if you are presuming that a reduction delivers its result <i>with
> only one rounding for the whole thing</i> then the bio problem is
> solved. But the rejected proposal did not call for that, and you would
> be burnt at the stake if you proposed it :-)<br>
> <br>
> Ivan<br>

        David just pointed out to me that I made a mistake.  The
        functions I mentioned are in the scaledproduct proposal not the
        reductions proposal.  I thought they were.

        But discussions about trapping & rounding miss the point.  It is
        not that they might trap on every operation (they don't).  Or
        that they need to be rounded correctly (they don't).  It is that
        they need to be calculated with the best practices available to
        the implementer taking both speed & accuracy into account &
        returning results scaled to be contained to the available range
        together with an integer that encompasses the scaling.

        Such scaled reductions would permit someone to write such code
        in a robust way without further complications involving the huge
        dynamic range required for the problem.

        If the flexibility necessary to permit implementers the ability
        to use those best practices are 'vague' enough to also permit
        arbitrarily bad implementations to fit the description, then I
        would like to hear suggestions about how to specify things so
        as to eliminate the latter without hamstringing the former.

        I think that's a better way to spend our time than eliminating
        the functions altogether.

        I'm sure opinions vary...

                                        Dan