End User

An end user is a person wishing to execute some application but is not assumed to know or care about the architecture, topology, or any machine-specific details. Hence, the end user should only have to specify the task in terms of goals. Perhaps more importantly, the end user should not be allowed to specify anything but the goals. The primary goal of the end user is to obtain ``accurate answers'' in ``a reasonable time'' and at ``a reasonable cost''. In practice, we observe two disturbing trends away from this common goal: a naive disregard for accuracy issues and focus on extraneous machine-dependent details instead of on time and cost.

Typically, when an end user executes a numerical application, end user assumes that the output accuracy is sufficient to meet his needs. On the few occasions when he feels uncomfortable with the answer, the common response is to switch from single precision representation to double precision. In fact, most end users of applications have no idea how accurate their output really is. Even in the cases where an output error estimate is supplied by an application, the output error is calculated under the assumption that the input is exact and error-free.

We propose that the end user focus on accuracy, elapsed time, cost, and reliability (tolerance for machine/software failure rates) by passing a set of demands and concessions to the application program. For example, the end user can say, ``I need three digits of accuracy in my answer.'' However, the end user should not be allowed to say, ``I want you to use the `double precision' data type because on this computer I think it will be good enough. I do not trust single precision.''

Demands that an end user can specify include placing upper limits on:

• how long the job may run in wall clock time
• error in the output
• cost (preferably in real money)
• acceptable failure rates

• a worst-case estimate of error in the input data
• a willingness to tolerate faults in hardware or system software
• a willingness to pay for a run
• a willingness to wait for a run
• a list of lower priority goals that may be sacrificed (if necessary) in order to meet other more important goals

Of the demands and concessions listed above, the three most important may be specifying a maximum of wall clock time and output error while admitting the amount of input error. Yet our generation of end users is accustomed to having little control over these issues. Scientific simulations are typically done with inputs assumed to be exact, very unscientific confidence in the numerical validity of the answers, and execution times determined by trial-and-error for each system with no guarantees of repeatability.

It seems possible to create a first-stage contract between the end user and the application program that demands a minimum performance for execution time and answer quality, yet frees the application programmer to achieve these things by any method that works. Note that the acknowledgment of possible error in the input is a concession made by the end user that helps the application programmer. This subcontract makes up the first stage of the three-stage contract.