Introduction.  When we developed our functions for computing some expectations of distributions we did almost nothing to ensure that the person who uses the functions uses them correctly.  While it is not possible to anticipate all the different ways a function can be misused, it is always worthwhile to expend effort towards decreasing the chances for misuse.  This is one manifestation of the issue of input validation and we will talk about several other manifestations during the course of the semester.  You can also describe these efforts as trying to bullet proof an application.

At one point in the past I worked with a marketing guy to develop a simulation to help pharmaceutical sales reps learn to make use of their new laptops and software.  The focus of the simulation was to help them make better sales call planning and tour routing decisions when developing their schedules.  This was an old DOS based program written in C and it required use of menus.  Windows was not very prevalent at this time.  At one point in the program the user is required to input a number of a potential sales call location between 1 and 7.  When the program was put into use by students at universities we quickly discovered that if someone  put in anything other than a number at that point in the program, the program would lock up.  It wasn't a very big deal to modify the program so that it accepted all inputs and then gave back a message if it was done incorrectly.  This had been done elsewhere in the program, I just missed a place.  But you can guess how convenient this proved to be for students who really wanted to avoid using the program.

This is a very typical example of input validation.  There are a number of ways to deal with such situations.  In the Visual Basic development environment there are a pretty good variety of built in objects to help you in doing these sorts of input validations.  Unfortunately, these objects are never all that you need.

Some other situations that should make use of input validation.

• Inputting things like social security numbers, zip codes or telephone numbers, for example.  All of these inputs have very typical structures and make use of numbers.  Thus if someone tries to input some letters or punctuation marks the program shouldn't allow it. 

• In other situations it might happen that someone is inputting state abbreviations.  A well designed program should have some sort of combo box so that the user must input something that is in the list.  You may even set it up so that it has defaults to a typical value such as CT.

• You may have a situation where someone is using a credit card and you only accept Visa, MasterCard or Discover so you have a control that limits selections to these three.

There are all kinds of other situations where a developer should build in input validation.  We will talk about other situations later in the course.  For now we will return to our situation of validating the inputs for our user defined expectations for distributions functions.

Input Validation for Computing Distribution Expectations. We will now describe three major things about the inputs that should be validated when using these new user defined functions.

• It is implicit in the proper functioning of the user defined functions we have just developed that both input arrays have the same number of entries. 

• It is also important that these input arrays are filled with numbers. 

• It should also probably always be the case that these input arrays are one-dimensional.

It is likely that you can come up with some of your own validation issues.

We will focus on the MeanDist function in order to implement our validations.  The input validations can be easily copied into the StdDevDist and CVDist functions.  At this point all we will do is ensure the inputs are numeric.

For example, in order to make certain that inputs are numeric as desired we will make use of the IsNumeric function in VisualBasic.