Re: fwd from Jim Demmel: More on repeatability
On Aug 17 2011, Vincent Lefevre wrote:
>IMHO, this should be done only by specifying the full behavior, possibly
>depending on well-identified platform-dependent parameters. Otherwise it
>may be tricky to define "repeatable mode" and "same machine" (e.g. what
>if the machine is upgraded[*], some environment variables are changed,
>and so on?)
Once you do that for any non-trivial operation, you are forbidding any
improvements in the future. State of the art today may be one result,
but someone may develop an improvement.
With forbidden contraction and in tightest mode, there would be
no possible improvements.
Precisely. As has been pointed out, it is computationally infeasible
to specify mathematically optimal bounds for most non-trivial operations,
so such a specification has to be for the best achievable bounds with
the technology at the time the specification is developed. Then someone
develops a better algorithm, and the standard forbids an implementor
to adopt it ....
The most extreme example I know of is the specification of the shift
operators in most programming languages, which is an artifact of the
restrictions of discrete-logic hardware (remember it?), and is STILL
around!
But without specification, the behavior can depend on the compiler
version, the optimization level and so on.
We have lived with that since the beginning of portable programming,
and known how to handle it since the early 1970s. Not just in theory,
but in practice.
I am not claiming that it's easy, helpful for debugging, or politically
acceptable to the innumerate bureaucrats - but the alternative is not
known to be feasible and known not to be under some circumstances.
Java Grande sank under its own fundamental contradictions and, if you
think that 1788 should take up where it left off, you know my prediction
of its chances of success ....
Regards,
Nick Maclaren.