0
$\begingroup$

While writing formal specifications for an algorithm, e.g. an algorithm f that searches a list A for a value x, I want to express that now assumption should be made about the order of elements in A (for it is ordered a more efficient implementation may be available).

How could this be formulated?

If we guarantee that the algorithm will be called with an ordered list we could write pre(f.call,A) is ordered or if we guarantee that it is unordered pre(f.call,A) is unordered.

Although it is possible to just omit any statement regarding the orderliness of A in the specification, because then writing an algorithm using the ordered nature of A and then proving its correctness is impossible.

Or should we require a meta-statement about the specification S itself, stating that $\neg (S\implies \texttt{pre(f.call,A) is ordered})\wedge \neg (S\implies \texttt{pre(f.call,A) is unordered})$ which has to be proven?

  • 0
    I don't understand what you are trying to ask. Either the specification specifies that the input is ordered or it doesn't. If you want to write one algorithm given the assumption the input is ordered and another when it's not necessarily ordered, then those are simply two distinct (but related) specifications. – 2017-02-04
  • 0
    not specifying if the input is ordered or not, and specifying that the input may be ordered or not are different things – 2017-02-04
  • 0
    Not really. A specification $S$ and a specification $S\land(P\lor\neg P)$ are equivalent. – 2017-02-04
  • 0
    logically yes, syntactically no, as the creator of the algorithm, when reading the specification one of the first things I would ask is "Can I assume the list to be ordered?" if nothing is said about the list I have to answer this question myself, if the answer is somehow (how is the question) expressed in the specification, the writer of the specification bears the burden of proof – 2017-02-04

3 Answers 3

0

Your first idea is the right one: a correct algorithm must achieve its post-condition for any input that satisfied its pre-condition. If you make no assertion about the order of the list you are searching in your pre-condition, then a correct algorithm cannot depend on the order.

The point is that the pre-condition is the statement of the allowable assumptions on the input. If you say the pre-condition is $\mathsf{true}$, then the algorithm can make no assumptions.

0

Maybe you can write formally that $A$ is ordered. $A[i] \leq A[j]$ for $1\leq i\leq j\leq n$.

0

The issue you are running into is that specifications are assertions, and, in particular, preconditions correspond assumptions. The problem is nothing stops you from specifying unsatisfiable preconditions.

What it sounds like you want to say is that some (preconditions of some) specification $S$ is consistent with some property $P$. In symbols, that $S\land P\nvdash\bot$ which reads as "assuming $S$ and $P$ a contradiction cannot be derived". You could then say the truth of $P$ is independent of $S$ via $(S\land P\nvdash\bot)\land(S\land\neg P\nvdash\bot)$ to cover your "may or may not be ordered" case. (This assumes that $S$ is consistent, i.e. satisfiable, itself.) There's nothing you can put into $S$ to get this effect since it is a statement about $S$. So the two consistency statements for independence are the "meta-logical" statements you'd need to prove to show that $S$ neither implies nor refutes $P$. If you were using $\implies$ like I'm using $\vdash$, then this is equivalent to what you stated, i.e. it's equivalent to $(S\nvdash P)\land(S\nvdash\neg P)$ or even $(\nvdash S \to P)\land(\nvdash S \to \neg P)$.