From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8bc4790fae14ac33 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 X-Received: by 10.180.10.230 with SMTP id l6mr16156762wib.3.1366617037428; Mon, 22 Apr 2013 00:50:37 -0700 (PDT) X-Received: by 10.180.212.51 with SMTP id nh19mr802636wic.21.1366617037411; Mon, 22 Apr 2013 00:50:37 -0700 (PDT) Path: hg5ni10415wib.1!nntp.google.com!15no3079371wij.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 22 Apr 2013 00:50:37 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=195.182.34.201; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 195.182.34.201 References: <957ef6e4-23d8-499f-ba19-20d32e82a7df@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1207e7ed-e279-4e31-93fc-350f5dcef671@googlegroups.com> Subject: Re: SPARK - divide algorithm issue From: Maciej Sobczak Injection-Date: Mon, 22 Apr 2013 07:50:37 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: 2013-04-22T00:50:37-07:00 List-Id: W dniu sobota, 20 kwietnia 2013 11:02:18 UTC+2 u=C5=BCytkownik Phil Thornle= y napisa=C5=82: > This can be proved by contradiction: if q >=3D 2147483647 then there is a= =20 > contradiction with H1, H4 and H6 (remembering that n is integer).=20 >=20 > Victor/Alt-Ergo does prove this VC: >=20 > ,divide,procedure,,,5,,true,0.016,,, Thank you for directions! > No matter how good the proof tools are, there will probably always be=20 > some proveable VCs that they fail to prove in practicable time Yes, but the notion of "practicability" is a bit sensitive. :-) In this cas= e the tool gives up after just few milliseconds and then the programmer has= to spend orders of magnitude longer with the interactive prover. It would = be practical for the tool to invest more effort (that is, more time and mem= ory), as the potential savings are huge. Would one second be enough for the= tool to exhaustively try various combinations of available hypotheses (the= re are only 9 of them here) and contradict them? Certainly, I would be happ= y to wait that much. Or maybe 10 seconds would be fine, too? Or maybe the actual meaning of "practicable" should be a config parameter? In any case, what is most intriguing is the fact that this example is claim= ed to verify OK in the book. Is it a regression in the toolchain? > If you are using worked examples to help with understanding SPARK proof,= =20 >=20 > you may find the proof tutorials at: >=20 > http://www.sparksure.com >=20 > helpful. Yes, I'm aware of this site and I appreciate your efforts in this area. :-) Thank you again, --=20 Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com