Determinism is hard & not the only thing on our plate...
> Date: 04 Aug 2011 10:23:04 +0100
> From: "N.M. Maclaren" <nmm1@xxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Cc: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: (Basenote drift) Determinism
>
> I have changed the subject line again, as I was using complex
> numbers purely as a trivial example.
As have I. :-)
>
>
> On Aug 4 2011, Dan Zuras Intervals wrote:
> >>
> >> . . .
> >
>
> > That was the "blind expression" thing you had trouble with,
> > remember?
>
> That is the assembler-based design again. In all mainstream languages,
> expressions are the primary concept and low-level operations scarcely
> figure. As a trivial example of where the models conflict, consider:
>
> A = P*Q*R*S
> B = R*P*S*T
You make a better case using add. The cost of changing
the associations in multiply is no more than a ULP or 2.
The cost of re-associating with add can be the magnitude
of the entire answer. And it is the more common problem
anyway.
Nick, I don't want to go tit for tat with you in an open
forum in the hope that one of us will change our mind.
That does nobody any good & pisses off our readers.
Determinism is hard. You have to pay a price for it.
Things can be done to mediate the problem of parallelism
but it is true that performance is part of the cost.
This does not mean we should not offer our users the means
to compute deterministically. We should. We should also
offer them other things.
We should offer them standard approved optimizations.
We should offer them the ability to run their code in
parallel at the possible risk of getting a different
answer. We should offer them the option of specifying
any of a number of (algebraic, numeric, algorithmic)
optimizations which ALSO give different (if tighter)
answers.
If there be dragons for the Ship of Determinism when it
sails the Seas of Parallelism, we should warn the users
away & provide alternate, safer routes to their goal.
If there be magical optimizations that we know that users
do not & can not know that make results narrower than what
was written on the page, we should offer those as well.
Here too is a path on which the users may choose to give
up some portability in favor of a better if not faster
answer.
We should offer all that our collective expertise can
offer INCLUDING our knowledge of how to use this magic
safely.
Our situation is just like the case of floating-point
standards is this respect. Nearly all users of good
floating-point have no idea how to use it safely. It
will only be worse for interval users.
To the extent that we can make intervals both safe &
useful, we must do all that we can. To the extent that
risk remains in this new tool, we must educate our users
as best we can.
We must provide a handle for the scissors we make, hand
it to them BY that handle, & teach them not to run with
them or poke their eyes out.
Because if, after all that, they still choose to risk
danger, it is their informed choice. And literally out
of our hands.
What else can we do?
Dan