Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

custom block fails unexpectedly #111

Open
rogpeppe opened this issue Apr 5, 2019 · 1 comment
Open

custom block fails unexpectedly #111

rogpeppe opened this issue Apr 5, 2019 · 1 comment

Comments

@rogpeppe
Copy link
Contributor

rogpeppe commented Apr 5, 2019

I am almost certainly getting something wrong here, but ISTM that if one abstracts out a custom block from a correct proof, then builds the same proof with that custom block, that it should work.
But that doesn't appear to be the case for me.

Here's an example. We start with a correct proof for (!x.P(x)->Q(x))->False => ?x.P(x)->False, with the blocks selected that we want to abstract out into a custom block (I am trying to see if it's possible to make a custom block encapsulating a particular instance of proof by contradiction). The "crown" block is a double-negative custom block.

image

Then with all the highlighted blocks removed and the custom block used instead (I've included an unwired-up instance of the custom block to show its generic connection types):

image

I'd expect this to work. What's wrong here?

@rogpeppe rogpeppe changed the title custom block gives unexpected behaviour custom block fails unexpectedly Apr 5, 2019
@nomeata
Copy link
Owner

nomeata commented Apr 8, 2019

Custom blocks have certain restrictions, in particular in an higher-order context, that are sometimes hard to understand. It might also be a bug, of course…

I am a bit confused by the P₇ predicate of the custom block. It seems to come out of nowhere, and I wonder how that should be quantified (I built the Proof Machine a while ago, so I don’t remember all the details…)

Can you use the annotation block to create a custom block that has ⊥ instead of P₇? Does that fix the problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants