Skip to main content

Subsection 7.5.4 Taming Vagueness in Formal Applications

We can’t typically tolerate vagueness in formal applications, including:

  • Mathematics

  • Software and hardware specifications

  • Critical databases

So, while philosophers and linguists have, over the centuries, devoted substantial attention to the problem of vagueness, there are many practical situations in which we effectively define it away.

Unacceptable specification for a factory control system:

The line must shut down if the machine gets hot.

Acceptable specification for a factory control system:

The line must shut down if the internal temperature of the compressor exceeds 150 F.

Unacceptable specification for a Human Resources database application:

An employee who has worked here a long time can retire.

Acceptable specification for a Human Resources database application:

An employee E can retire if and only if:
AgeInYears(E) + NumYearsEmployeed(E) ≥ 80

Exercises Exercises

Exercise Group.

Consider this vague rule about who may invest in our new, risky hedge fund:

Only rich people may invest in the Gotcha Fund.

Assume that these predicates mean what they appear to mean. Indicate, for each of the following clear statements, whether or not it could be what was intended:

1.

x ((Networth(x) > $10M) ≡ MayInvest(x, GF))

  1. Could be correct.

  2. Not at all likely to be correct.

Answer.

Correct answer is A.

2.

x ((AnnualIncome(x) > $1M) ≡ MayInvest(x, GF))

  1. Could be correct.

  2. Not at all likely to be correct.

Answer.

Correct answer is A

3.

x ((Networth(x) > $100M) ≡ MayInvest(x, GF))

  1. Could be correct.

  2. Not at all likely to be correct.

Answer.

Correct answer is A

4.

x ((NumberOfHousesOwned (x) >3) → MayInvest(x, GF))

Answer.

Correct answer is A

Solution.

Explanation: Any of these could correspond to someone’s definition of a “rich person”. So we see why the vague statement is inadequate.