Idiomatic Proof by Contradiction in Isabelle? - proof

So far I wrote proofs by contradiction in the following style in Isabelle (using a pattern by Jeremy Siek):
lemma "<expression>"
proof -
{
assume "¬ <expression>"
then have False sorry
}
then show ?thesis by blast
qed
Is there a way that works without the nested raw proof block { ... }?

There is the rule ccontr for classical proofs by contradiction:
have "<expression>"
proof (rule ccontr)
assume "¬ <expression>"
then show False sorry
qed
It may sometimes help to use by contradiction to prove the last step.
There is also the rule classical (which looks less intuitive):
have "<expression>"
proof (rule classical)
assume "¬ <expression>"
then show "<expression>" sorry
qed
For further examples using classical, see $ISABELLE_HOME/src/HOL/Isar_Examples/Drinker.thy

For better understanding of rule classical it can be printed in structured Isar style like this:
print_statement classical
Output:
theorem classical:
obtains "¬ thesis"
Thus the pure evil to intuitionists appears a bit more intuitive: in order to prove some arbitrary thesis, we may assume that its negation holds.
The corresponding canonical proof pattern is this:
notepad
begin
have A
proof (rule classical)
assume "¬ ?thesis"
then show ?thesis sorry
qed
end
Here ?thesis is the concrete thesis of the above claim of A, which may be an arbitrarily complex statement. This quasi abstraction via the abbreviation ?thesis is typical for idiomatic Isar, to emphasize the structure of reasoning.

Related

can someone help me how grouping works in regex in my case if group1 success then group2 should be applicable

As I have added image for my problem it selecting the end tag though the first condition is not true. It should only select when the first condition is true.
link
(<a\s\b(href|title)\b.*\">)?|(<[\/]a>)
for the below use cases
www.ags.ny.gov
<a title=\"ba.com/redeem\" href=\"http://ba.com/rertem\" target=\"_blank\" rel=\"nkiops noreferrer\">ba.com/rertem</a>.
www.ags.ay.gov, for free information
Thanks for including the picture. That helped me understand what you're driving at.
The bad boy is the pipe (logical OR) operator, 10th character from the end of your Regular Expression. That says, "Even if there is no match for the first part, if I have that closing anchor tag, then it's a match."
That's what you said you don't want, but the "|" operator says give you a match for </a> no matter what happens before.
I think this is the answer you're looking for. Clarity in your question helps people who want to answer. Your original ask was kind of hazy, but then you added clarification, so I upvoted your question. I hope this answer helps you and encourages you to solicit feedback.
Follow up to your comment:
I knew the logical operator | giving a match at the end though
the first group is not match. However I need to know how can I update
my regex for the second condition should only applicable when the
first condition is true.
Okay, let's think about this a little differently. Your requirement is for the truth values at both ends to be TRUE. That's the same as simply saying the whole thing needs to be one long match. The logical operator | signifies logical disjunction, but your requirement is conjunction. Don't split them up at all. Just make one match expression for the whole string you want.
Where you have |, code instead .+. When I tried that, at first it didn't work because of the ? quantifier, signifying optionality. In that case, my match picked every character even if the first part wasn't there! Well, don't make the first part optional. Get rid of the ?.
My environment will look a little different from yours because I work in R, and it changes the escaping a little bit. You'll get the idea, though. My demonstration did what you appear to be describing you want.
library(stringr)
str1 <- 'www.dfs.ny.gov, for free'
str2 <- '<a title = \\\"http"://www.blah/\\\">www.blah</a>'
str3 <- '<a ID=stuff></a>, for free'
re <- '(<a\\s\\b(href|title)\\b.*\">).+(<[/]a>)'
str_extract(str1, re)
str_extract(str2, re)
str_extract(str3, re)
My results for matching those three strings in my demo were as follows. My change to your RegEx matched the first two and did not match the third (indicated by NA in my output, which means Not Available, as in no match), which are your expected results.
> str_extract(str1, re)
[1] "www.dfs.ny.gov"
> str_extract(str2, re)
[1] "<a title = \\\"http\"://www.blah/\\\">www.blah</a>"
> str_extract(str3, re)
[1] NA

how to determine past perfect tense from POS tags

The past perfect form of 'I love.' is 'I had loved.' I am trying to identify such past perfects from POS tags (using NLTK, spacy, Stanford CoreNLP). What POS tag should I be looking for? Instead .. should I be looking for past form of the word have .. will that be exhaustive?
I PRP PRON
had VBD VERB
loved VBN VERB
. . PUNCT
The complete POS tag list used by CoreNLP (and I believe all the other libraries trained on the same data) is available at https://www.ling.upenn.edu/courses/Fall_2003/ling001/penn_treebank_pos.html
I think your best best is to let the library annotate a list of sentences where you want to identify a specific verbal form and manually derive a series of rules (e.g., sequences of POS tags) that match what you need. For example you could be looking for VBD ("I loved"), VBD VBN ("I had loved"), VBD VBG ("I was loving somebody"), etc...

Skip a subgoal while proving in Isabelle

I am trying to prove a theorem but got stuck at a subgoal (that I prefer to skip and prove later). How can I skip this and prove the others ?
First, I tried oops and sorry but they both abort the entire proof (instead of the only subgoal). I also tried to put the subgoal into a dummy lemma (assuming proven with sorry) then using it (apply (rule [my dummy lemma])) but it applies the dummy lemma to every other subgoals (not only the first one).
It mostly depends on whether you are using the archaic (sorry for that ;)) apply-style or proper structured Isar for proving. I will give a small example to cover both styles. Assume you wanted to prove
lemma "A & B"
Where A and B just serve as placeholders for potentially huge formulas.
As structured proof you would do something like:
proof
show "A" sorry
next
show "B" sorry
qed
I.e., in this style you can use sorry to omit proofs for subgoals.
In apply-style you could do
apply (rule conjI)
defer -- "moves the first subgoal to the last position"
apply (*proof for subgoal "B"*)
apply (*proof for subgoal "A"*)
There is also the apply-style command prefer n which moves subgoal n to the front.

How To (Semantically) Mark Up A (Theatre) Script / Play in HTML5

How To (Semantically) Mark Up A (Theatre) Script / Play in HTML5?
For obvious reasons, it's hard to search for "play" and "script" without a search engine thinking you mean “play a sound" and “JavaScript".
How can I mark up a script (as in the document one would give to actors in a play) such that it is semantically correct, and easy to style?
For example, let's take the start of Hamlet
Hamlet
ACT I
SCENE I Elsinore. A platform before the castle.
[FRANCISCO at his post. Enter to him BERNARDO]
BERNARDO Who's there?
FRANCISCO Nay, answer me: stand, and unfold yourself.
Fairly obviously, I think, one should start with
<h1 id="title">Hamlet</h1>
<h2 id="act-1">Act 1</h2>
<h3 id="scene-1">Scene 1</h3>
But, then I get stuck.
I've tried looking at MicroData, but Schema.org's CreativeWork[0] really doesn't contain much that would be useful in the case of a work of fiction.
Is it enough just to say
<p class="stage-direction">FRANCISCO at his post. Enter to him BERNARDO</p>
<p id="1"><span class="character bernardo">BERNARDO</span>Who's there?</p>
<p id="2"><span class="character francisco">FRANCISCO</span>Nay, answer me: stand, and unfold yourself.</p>
Or is there a better / more sensible way of doing things?
[0]http://schema.org/CreativeWork
It seems that the idea of precisely specifying markup for dialogue has been abandoned, and the W3C now simply offers some guidelines which pretty much equate to your idea of using paragraphs and spans.
Note that the dl element, which older sources - including the spec - had formerly recommended, should now definitely not be used: "The dl element is inappropriate for marking up dialogue".
But of course all this might change next week, or month, or year…
Does this provide any inspiration? caesar in xml

Language support for recursive comments

Most languages I've worked with don't have support for recursive comments.
Is there any reason why language designers would choose not to implement this?
Is it deceptively complex?
Would it have undesired results?
Example of a recursive comment:
/*
for (int j = 0; j <= SourceTexture.Height; j += SampleSize)
{
...
}
// Comment within comment below:
/*for (int i = 0; i < TextureColour.Length; i++)
{
...
}*/
sourceTexture.SetData<Color>(TextureColour);
*/
EDIT: I understand the argument of the answers so far (problems occur when you have comment tokens in strings). However, the reason for my confusion is that you have that problem now.
For example, i know the code below wouldn't give the expected result.
/*
char *str = "/* string";
// Are we now 1 level inside a comment or 2 levels?
*/
printf("Hello world");
/*
char *str2 = "string */";
*/
But in my mind that's no different to an unexpected result in the case below:
/*
CODE "*/";
*/
Which would also yield an unexpected/undesired result.
So, while it could be a problem for recursive comments, my argument as to why that's not a reason not to do it, is that it is already a problem for non-recursive comments. As a programmer i know the compiler behaves like this and i work around it. I don't think it's much more effort to work around the same problem with recursive comments.
Is there any reason why language designers would choose not to
implement this?
It makes the lexical analysis more difficult to implement.
Is it deceptively complex?
IMHO, no, but this is subjective.
Would it have undesired results?
Hard to tell. You have already discovered that even normal block comments can make problems:
/* print ("*/"); */
I know 2 languages that have nesting block comments: Haskell and Frege.
I will make an example and perhaps it will be clearer:
/*
char *str = "/* string";
// Are we now 1 level inside a comment or 2 levels?
*/
printf("Hello world. Will this be printed? Or is it a comment?");
/*
char *str2 = "string */";
*/
You couldn't parse comments inside a comment without interpreting what is inside the comment. But you can't interpret what is inside a comment because it's a comment, so by definition "human text" and not "language".
Although C's multi-line comments can't be nested, the effect of recursive comments can more-or-less be achieved in C using #if 0 ... #endif (and I strongly recommend you use that when you want to disable a block of code, for exactly that reason).
Even the C preprocessor, designed to be as dumb as a post, would be perfectly capable of handling nested comments, just as it has to be capable of handling nested #if directives with false conditions. So it's not really to do with anything being difficult to define or parse, since although it makes comments more complex, they'd still be no more complex than other things done in preprocessing.
But, using #if 0 ... #endif requires of course that there not be any unmatched #endif in the code you're trying to exclude.
Fundamentally comments cannot be both (a) completely unstructured and (b) recursive. Either by happenstance or deliberate choice, C has gone with (a) -- commented text doesn't have to obey any syntax constraints other than not containing the comment-terminator sequence (or trigraph equivalent such as *??/<newline>/).
I believe it is just never considered to begin with and it becomes a "non-important" feature addition as things develop. Also, it requires a lot more validation.
Example scenario...
MyLang version 1: Objective
Provide Multi-line commenting
Developer: hmmm.. I know, every time I find a /* I will comment everything until the next */ - easy!
MyLang version 1 release
1 day later...
User: erm... I cant do recursive comments, help me.
Support: Please hold.
30 mins later...
Support Manager -> Developer: User cannot do recursive comments.
Developer: (What's a recursive...) hang on...
30 mins later
Developer: yeah, we dont support recursive commenting.