Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Martin Berger <martinb@dcs.qmul.ac.uk>
To: Hendrik Tews <tews@tcs.inf.tu-dresden.de>, caml-list@inria.fr
Subject: Re: [Caml-list] Formal Methods
Date: Fri, 01 Oct 2004 10:18:36 +0100	[thread overview]
Message-ID: <415D20EC.8080704@dcs.qmul.ac.uk> (raw)
In-Reply-To: <rlzn36zvqi.fsf@ithif59.inf.tu-dresden.de>

>    "Similarly, proving correctness of software using formal methods is
>    hopeless. 
> 
> This is just nonsense. You can prove the correctness of any piece
> of software (provided it is correct). Its only some orders of
> magnitute more expensive than developing the same software,
> therefore proving correctness is seldom attempted in practice. 

it is a bit more complicated than that. it seems to be the case, and
maybe that's what chaitin is getting at, that the more complicated
the program under verification and the more complicated the property
to be established, the more that verification is like writing a program.
but then the question "is the specification correct?" becomes as hard
as, or identical with "has the program that property?". so in the limit
there seems to be a real problem in that we can trust  verification
only in as much as we can trust programming.

BUT, and that's a very big "but", for many properties that happen to be
of human interest, such as the absence of buffer-overflow errors, or
the fact that a given program terminates, verification is often fairly
easy to do and specification of the relevant property
is easy. so easy in fact sometimes that it can be automatised. Sriram
Rajamani for example, http://research.microsoft.com/~sriram/ has
recently come up with some surprisingly powerful automatic verification
tools.

in summary, it seems that chaitin is right, but for properties and
programs as simple as those humans care about, formal verification
tends to be possible.

martin

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2004-10-01  9:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-30 15:51 David McClain
2004-09-30 17:35 ` Jacques Carette
2004-09-30 18:42   ` Jon Harrop
2004-10-01  8:24   ` Thomas Fischbacher
2004-10-01  9:01     ` Achim Blumensath
2004-09-30 17:54 ` [Off-topic] " David MENTRE
2004-10-01  7:36 ` Jean-Christophe Filliatre
2004-10-01  7:51   ` Tom
2004-10-01  9:04   ` Martin Berger
2004-10-01  8:30 ` Hendrik Tews
2004-10-01  9:18   ` Martin Berger [this message]
2004-09-30 17:19 Harrison, John R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=415D20EC.8080704@dcs.qmul.ac.uk \
    --to=martinb@dcs.qmul.ac.uk \
    --cc=caml-list@inria.fr \
    --cc=tews@tcs.inf.tu-dresden.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox