Re: Motion P1788/M007.01_NaI: Discussion period begins
> Date: Mon, 10 Aug 2009 11:14:01 +0200
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: Motion P1788/M007.01_NaI: Discussion period begins
>
> On 2009-08-09 20:58:48 -0700, Dan Zuras Intervals wrote:
> > For 1788, even more than for 754, behaving different
> > from one platform to another would be a disaster.
>
> This will be unavoidable, because first, most languages allow compilers
> to generate code that behaves differently on different platforms (and
> even on a single platform, the results can depend on optimization
> options, and in general users prefer that than getting slow code).
> And in particular, if IEEE754 is supported, you may get different
> results.
You go directly to the point: These unavoidable things
MUST be defined in such a way as to be avoided.
We must clearly define a standard behavior within supported
languages to be independent of supported platforms &
permitted optimizations.
When we make these choices we must keep speed in mind
but correctness is always to be preferred over speed.
Therefore, those variations that 754 permits should NOT
be permitted to cause needless variation in 1788.
>
> BTW, concerning IEEE 754, Java tended to require a same behavior on
> the various platforms, meaning that on some platforms, the code would
> not be as efficient as it could be. Java has been much criticized for
> this choice, and now Java is allowed to be less strict on the
> reproducibility.
Well, I think the Jave folks had different motivations
than you ascribe to them but you are quite correct that
such variations were eventually permitted.
That they made that choice is no excuse for us to follow
them. Our goals are quite different than theirs.
The lesson to be learned is to make a reasonably EFFICIENT
choice as our standard behavior NOT to permit needless
variation for having chosen badly.
>
> > It destroys the central theme of assuring the customer that
> > the results are correct.
>
> Getting different results doesn't mean that some are incorrect.
> And conversely, getting a single result across various platforms
> doesn't mean that the result is correct.
Again, you get directly to the point: The same answer
across platforms is not guarenteed to be the correct one.
It is our job to make sure that the answer we specify as
standard *IS* the correct one. Or, to acknowledge another
part of your point, ONE of the correct answers.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
But we have two goals for the public here.
The first is to use our expertise to create a standard
within which correct answers can & do happen.
The second is to teach the public that it is true. That
is, we must make them BELIEVE it.
They will not have all the knowledge we have and needless
variation from machine to machine only creates (reasonable)
doubt in the mind of the user that 1788 is correct.
The vast majority of our customers will not be able to
distinguish between harmless variations & bugs. We must
not require them to doubt correct answers. When customers
DO see variations from one platform to the next, they
SHOULD suspect that something is wrong & go looking for
a bug.
Their search for that bug should be confined to their area
of expertise not ours.
If, in order to accomplish this, we must make difficult
choices then we must make them.
If we do not the customer won't have the expertise to
make them & 1788 is useless. Or worse than useless if
the customers stop believing in it.
IMHO, of course.
As is always the case, your mileage may vary... :-)
Dan