Nice work, but there are quite a lot of issues here, I'm afraid.

• Spacing issues. You have inconsistent spacing in the text. For example, you write "precondition(positive and negative)" and "same way as before :". In the first case you need a space before the parenthesis, while in the second case you need to remove the space before the colon.

• Capitalization issues. When starting a new sentence, you should be using capital letters even if before that you had a code example. It still is a sentence + you break capitalization consistency.

• Wording issues. Sometimes you miss the word 'the'. For example, "It consists of following". There should be a 'the' before the word 'following'.

• Awkward wording. Some other sentences are awkwardly written and are jarring to read. For example, "The PDDL (Planning Domain Definition Language) allows us to express all actions with one action schema, it consists of following four functions". This sentence is awkwardly written. The "it consists..." part does not look nice. Either it should be a separate sentence, or you should have replaced 'it' by 'which' (if by 'it' you refer to the schema). Right now it is confusing to read.

• Confusing wording. This ties in with the above, but a lot of the text is hard to follow. You are using a lot of self-reference words (like 'it', 'the other', etc.) but the link to that reference is lost. For example, "Actions consists of a precondition(positive and negative) and effect(positive and negative). It consists of following". Here, Actions is a class. You write that it consists of a "precondition" and an "effect" and then you write in the next sentence that "it consists of the following". It took me a second to realize you were still talking about the class Actions, since you already told us what it consists of. At first I thought you were referring to "effects", or maybe "precondition". You could have written something like "it also consists of..." which makes it clear you are still talking about the class.

• Image issues. In planning, you have added an image. While that is a great idea to help get the concepts across, the image has issues itself. The text is over the diagram, making it harder to read. Also, it would have been better if you had dropped a couple of lines before the image explaining what the reader is seeing. Granted, this can be added in the future, but still.

• unknown type. This pops up from time to time in the logic Notebook, for some reason. Not sure why that happens but needs to be fixed.

• Formatting/Styling. Most of the Notebooks utilize formatting to help ease the reader in. Italics, bold, etc. help a lot and look nice. A lot of the time I was not sure if what I was reading was an actual word or a function/class name. This can be easily fixed by styling function/variable/etc names as code. You can do that by wrapping the name in left-leaning quotations (the quotation usually found under the 'tilde' key -> ``). It produces more or less the following effect: code. You can use italics and bold font in similar instances too.

These are the technical issues I noticed in your PR. If you fix them, this will be fine. I want to mention another thing too though.

Here you are not explaining what is happening. Sure, you are showing how to use the code, but you are not telling the reader what is happening. I will give just one example, but that is evident in pretty much everywhere.

The following code defines the initial state for the problem

def air_cargo():
    init = [expr('At(C1, SFO)'),     
            expr('At(C2, JFK)'),
            expr('At(P1, SFO)'),
            ...
            ...
            ...

This shows how to define the air cargo problem, but it does not help the reader. You should write why does it define the problem. Explain why is init initialized that way. Why use expr('At(C1, SFO)')?

The only way for the reader to understand what this means is to go read the book instead and try figure things on their own, which kind of defeats the purpose of explanatory examples. While this project is complementary to the book, the examples should have some substance of their own. Otherwise people would just take a look at the code and the tests to get a feel of how to get this to work.

In the above case, you are only showing how to define one single problem. What your example should do is show the reader how to define any problem.

Of course, this is up to @norvig, but personally I feel this should not be merged as is.

While I do agree with with @MrDupin , I think this PR can be merged as it serves as a starting point which can be improved upon. The only major problems which I see in this PR are that some of the definitions(Air Cargo, Spare Tire) have only code but no explanation, and that it has too many unrelated commits and changes.
I recommend splitting this into two seperate PRs. One which adds examples to the notebook, and one which modifies the fol_fc_ask function. The current PR has too many commits which have too vague a description and no indication what changes they bring. It would be better if the commits represent unit changes, like 'Added example for Air Cargo' or 'Updated fol_fc_ask()'.

Just to clarify, I'm not saying the changes shouldn't be merged. They are helpful and they can definitely be merged, but not before the technical issues are dealt with (at least in my opinion).

I agree with @Chipe1 about splitting the PR. I would suggest you fix the issues first (maybe even posting them here for review) and then make the new PRs. That way the new PRs will not get bloated with patches.

@MrDupin Thank you for going through and letting me know how to improve upon. I have done some improvements and am working on more.

@Chipe1 The PR comes up with too many commits which have been already merged before and I have been trying to get rid of this.

@sofmonk: This is better. I only had time to skim over it, but I noticed some small issues I will quickly point out:

• At the start you wrote "The PDDL class include". It is 'includes'.

• In the list below that, I would suggest you make the points bold (eg. "goal_test(self):" should be bold) and write the references to functions inside these points using the code style. (eg. "initialises goal_test with kb." should be "initialises goal_test with kb.")

• In the "Air-Cargo Problem" opening paragraph, you wrote "we have to define a initial" but it is 'an' instead of 'a'.

I would like to see though short introduction to the problems. For the air-cargo problem, drop a couple of lines on explaining the problem at hand.

@sofmonk One way to fix it is to diff your current branch with master, create a fresh branch which is up to date with master and apply the diff to the newly created branch.
To prevent cluttering of PRs, use one branch per PR and delete it once the PR is merged. You need not update the PR branch to the aimacode/aima-python:master unless you wish to fix any merge conflicts. There probably won't be any conflicts if the PR makes small, local changes.
Also try not to reuse commit comments within a PR as it makes changes confusing. Make it more descriptive like 'Added missing newline characters' instead of 'Update logic.ipynb'.

@MrDupin @Chipe1 Thank you for all the improvements (more to come) PR #427