-
Notifications
You must be signed in to change notification settings - Fork 9
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
pyparsing dependency #23
Comments
I just noticed that we need to remove it, because pyparsing is not available for Python 3. |
The pypy hosted package for pyparsing does have the Python 3+ tags on it. It did work at some point, not sure what may have changed that would've broke the regular tasks. 100% the correct answer is to replace it with the new parsing scheme so we can bring all the functionality back together in one place. Doing so is going to require extension to the logical/ classes. E.g. add an output flag to the base Logical then implement logic in the repr() methods of the classes which change how the string representation gets created. Right now everything is plain old infix FOL. This would take care of the majority of the work needed to get valid .tptp and .p9 files. |
I found the pypy package for Python 3.5 (not 3.6 yet). I will give it a try with that. As for the long-term plan: don't we need multiple representations? I'm rather thinking of having functions .toTptp() and .toLadr() for each kind of class in the object structure (Logical, Axiom, etc.). |
While responding to this I ended up writing a complete I agree with adding the shortcut methods .to_tptp() and .to_ladr(), I'm thinking more in the backend on how to power those methods with minimal code.
Since every Logical (e.g. Quantifier, Connective, Negation, Predicate, and Function) all subclass Logical we could implement this by adding
We could then put the convenience methods
The different output formats should be very short, basically one-liners taking advantage of string interpolation. For example here is the
By using the I've vacillated quite a bit and can't decide between embedding the translators in the object structure or providing single utility functions for each desired output format. This would look something like...
... so that works and looks better than expected. How about we just go with that as a class method
|
I like the to_tptp in one place, that makes it easier to maintain. |
Ok, that's not too bad to fix, we can add a class visible singleton to serve as the appointed "variable numberer". Are there any other gotchas about the provers that you can think of so we can get them documented here in the issues? |
Great, that is very helpful. All variables must be upper case for TPTP. The first axiom in the example above has a "~ ~ (". It seems like it is missing a parenthesis between the negation symbols (i.e. whatever you negate needs to be put in parentheses. Btw, does the double negation jsut arise from a direct translation from CLIF without any simplification? I hope the CNF parser doesn't spit that out! |
I remember wondering about the negation and thought it was weird that it wasn't wrapped. That's an even easier fix! You are correct that the double negation is just the result of the parsing with no simplification applied. The ff-pcnf translated axioms don't contain nested negations. A negation simplified version of the sentence (not completely ff-pcnf translated) is also obtainable via the |
In ClifModule, we have two calls to get_translated_file: one for the TPTP translation (in the method get_tptp_file_name) and one for the LADR translation. What does it take to replace the translation to TPTP to the new method and using the new parser? I'd like to try it out here first, before using it in other places as well. |
Updated and added a '-t' or '--tptp' flag on the parser.py script in the bin/ directory. Sample:
@thahmann it's going to need some external verification to make sure that the translation is correct. In particular I'm not sure if there are any extraneous parenthesis that might make the provers unhappy. If there was a spec somewhere which explained the tptp format that would be useful. Variables have an integer appended to them that corresponds to that axiom's |
in macleod/Clif.py, there is one remaining dependency on pyparsing (lines 307 and 308), which causes an error unless the pyparsing module is installed. I thought we wanted to remove that dependency.
Can we replace these lines with new parsing functionality?
The text was updated successfully, but these errors were encountered: