Talk:Predicate transformer semantics: Difference between revisions

Revision as of 22:41, 9 April 2015

Latest revision as of 17:55, 25 January 2024

(6 intermediate revisions by 4 users not shown)

Line 1:

{{WikiProject Computerbanner Scienceshell|class=C|importance=mid}}

{{WikiProject Computing|software=yes|class=CComputer science|importance=mid}}

{{WikiProject Computing|software=yes|importance=mid}}

}}

A more in-depth discussion of '''if''' and '''do''' is required, as well as nondeterminism. Also, an example of how to use ''predicate transformers'' to derive a non-trivial algorithm might be good, as long as it doesn't conflict with policy. Also, the references section could use some filling out, specifically to the Gries' and Backhous' newer books on the subject. The relationship to [[First-order_logic|predicate calculus]] could also be filled out.

--[[User:Jdinolt|jayinbmore]] 23:58, 31 Jan 2005 (UTC)

Line 50 ⟶ 51:

while x < 2 do x := x+1 done

The state <code>{x = 0}</code> should satisfy the wlp <math>I \wedge (E \Rightarrow I[x \leftarrow x+1]) \wedge (\dotsneg E \Rightarrow R)</math>, for any tautology R, so the first and second clauses are true, and the last one is actually true independently of the value of R; so we can replace it with an unsatisfiable postcondition <math>(x = 42)</math>, and our wlp would still hold; even though it should never do, as the loop always terminates. A universal quantification like in the total correctness subsection seems necessary here as well. [[SpecialUser:Contributions/82.225.200.38Syrak|82.225.200.38Syrak]] ([[User talk:82.225.200.38Syrak|talk]]) 22:41, 9 April 2015 (UTC)

== Stongest postconditions are missing a motivation ==

Line 59 ⟶ 60:

[[User:Houseofwealth|Houseofwealth]] ([[User talk:Houseofwealth|talk]]) 01:12, 5 March 2015 (UTC)

== Strictness of wp depends on allowed statements ==

<p>If we allow an assume statement, the wp operator is not strict:<br>

The weakest precondition of False before the statement <code>assume !A</code> is exactly the formula that satisfies A.</p>

Assume statements are common in the field of software verification<ref name="ZeeKuncak2009">{{cite journal|last1=Zee|first1=Karen|last2=Kuncak|first2=Viktor|last3=Rinard|first3=Martin C.|title=An integrated proof language for imperative programs|journal=ACM SIGPLAN Notices|volume=44|issue=6|year=2009|pages=338|issn=03621340|doi=10.1145/1543135.1542514}}</ref>

In model checking, often a program is represented as a control flow graph.<ref name="ArltRümmer2013">{{cite journal|last1=Arlt|first1=Stephan|last2=Rümmer|first2=Philipp|last3=Schäf|first3=Martin|title=A Theory for Control-Flow Graph Exploration|volume=8172|year=2013|pages=506–515|issn=0302-9743|doi=10.1007/978-3-319-02444-8_44}}</ref>

<ref name="CytronFerrante1991">{{cite journal|last1=Cytron|first1=Ron|last2=Ferrante|first2=Jeanne|last3=Rosen|first3=Barry K.|last4=Wegman|first4=Mark N.|last5=Zadeck|first5=F. Kenneth|title=Efficiently computing static single assignment form and the control dependence graph|journal=ACM Transactions on Programming Languages and Systems|volume=13|issue=4|year=1991|pages=451–490|issn=01640925|doi=10.1145/115372.115320}}</ref>

For example a statement <pre> if A then C1 else C2 </pre>

is typically translated to a start ___location with two outgoing edges

to nodes that represent the entry to the representation of the subprograms C1 and C2.

The edge entering C1 is labeled <code>assume A</code> and the edge entering C2 <code>assume !A</code> respectively.

{{reflist-talk}}