REUSABLE WORKSHEETS
Programming
The expression, 'Reusable Worksheets', is used to describe a concept as opposed to a method or procedure. In our context, a reusable worksheet is one that can be used repeatedly for the particular class of problem or type of analysis for which it was designed. This means the creation of such a worksheet requires, but is not necessarily limited to, the following features:


Although the development of such worksheets can be time consuming, it often makes sense to do so if the problem being solved is typical of the type of work you do. The time required for initial development is often recouped through the time saved each time the worksheet is used to perform a calculation.

Also realize it is not necessary, during initial development of a given worksheet, to immediately take into consideration all possibilities that may occur or to provide a full suite of features in an attempt to automate the process. Quite often, worksheets are iniitally developed in a rather simplistic fashion requiring significant user interaction. Upon continued use, the original author will add features to make the worksheet more friendly and more productive. Such continued development is evident in all professional and consumer software. Just consider the current version of your favorite piece of software vs. the version upon which you learned. Quite a difference in features and performance, isn't there? The development of your worksheets will follow the same process.
Problem 6.8 was a homework assignment allowing for the practice of writing a MathCAD program. This problem focused on the use of conditional statements.
A possible solution is shown below. The use of this program requires first establishing a matrix of data representing the width of a part. However, within this program, there are four items not handled.

  1. The number of parts is a constant in the program. If we have multiple sets of data with variable data points, the program has to be modified each time it is used.
  2. The program does not account for variation in the environmental variable ORIGIN. Although such a change would result in the program 'crashing, one can argue it is unnessary to do so. A change in the ORIGIN variable must be accomplished purposefully by the user, so s/he would quickly realize this change is the cause for the crash. None the less, we will account for such a change.
  3. Upper and Lower limits of part width are constant in the program. These limits should be variable.
  4. Matrix is entered by hand. If the number of data points is large, this is not acceptable. We should setup the program to read the data from a file hopefully generated by an automation system.
<= Set the ORIGIN to a positive integer and observe the results.
Why does this happen?
A more versatile way to handle this problem is shown below. All four issues describes above are addressed. The program can be tested using files parts1.txt, parts2.txt and parts3.txt. Each file contains a differing number of data points as well as a differing number of 'bad' parts.
<= Data read from file generated
by automation system
<= Establish limits of part width outside the program making it easy for a user to change without modifying the program. Program can now be hidden and protected inside a locked area.
length() determines number <= of data points
<= Compensate for a change in
ORIGIN variable
<= Variables y and z represent
lower and upper limits
respectively
<= invoke function and assign to variable. This can also be hidden in a protected area
<= display