# aima-python: Structure of the Project
Python code for the book *Artificial Intelligence: A Modern Approach.*
When complete, this project will cover all the major topics in the book, for each topic, such as `logic`, we will have the following [Python 3.5](https://www.python.org/downloads/release/python-350/) files:
- `logic.py`: Implementations of all the pseudocode algorithms in the book.
- `logic_test.py`: A lightweight test suite, using `assert` statements, designed for use with `py.test`.
- `logic.ipynb`: A Jupyter notebook, with examples of usage. Does a `from logic import *` to get the code.
# Style Guide
There are a few style rules that are unique to this project:
- The first rule is that the code should correspond directly to the pseudocode in the book. When possible this will be almost one-to-one, just allowing for the syntactic differences between Python and pseudocode, and for different library functions.
- Don't make a function more complicated than the pseudocode in the book, even if the complication would add a nice feature, or give an efficiency gain. Instead, remain faithful to the pseudocode, and if you must, add a new function (not in the book) with the added feature.
- I use functional programming (functions with no side effects) in many cases, but not exclusively (sometimes classes and/or functions with side effects are used). Let the book's pseudocode be the guide.
Beyond the above rules, we use [Pep 8](https://www.python.org/dev/peps/pep-0008), with a few minor exceptions:
- I'm not too worried about an occasional line longer than 79 characters.
- You don't need two spaces after a sentence-ending period.
- Strunk and White is [not a good guide for English](http://chronicle.com/article/50-Years-of-Stupid-Grammar/25497).
- I prefer more concise docstrings; I don't follow [Pep 257](https://www.python.org/dev/peps/pep-0257/).
- Not all constants have to be UPPERCASE.
- [Pep 484](https://www.python.org/dev/peps/pep-0484/) type annotations are allowed but not required. If your
parameter name is already suggestive of the name of a type, such as `url` below, then i don't think the type annotation is useful.
Return type annotations, such as `-> None` below, can be very useful.
def retry(url: Url) -> None:
# Language Choice
Are we right to concentrate on Java and Python versions of the code? I think so; both languages are popular; Java is
fast enough for our purposes, and has reasonable type declarations (but can be verbose); Python is popular and has a very direct mapping to the pseudocode in the book (ut lacks type declarations and can be solw). The [TIOBE Index](http://www.tiobe.com/tiobe_index) says the top five most popular languages are:
Java, C, C++, C#, Python
So it might be reasonable to also support C++/C# at some point in the future. It might also be reasonable to support a language that combines the terse readability of Python with the type safety and speed of Java; perhaps Go or Julia. And finally, Javascript is the language of the browser; it would be nice to have code that runs in the browser, in Javascript or a variant such as Typescript.
What languages are instructors recommending for their AI class?
To get an approximate idea, I gave the query norvig russell "Modern Approach" along with
the names of various languages and looked at the estimated counts of results on
various dates. However, I don't have much confidence in these figures...
| Language | 2004 | 2005 | 2007 | 2010 | 2016
|
|---|
| none | 8,080 | 20,100 | 75,200 | 150,000 | 132,000
|
| java | 1,990 | 4,930 | 44,200 | 37,000 | 50,000
|
| c++ | 875 | 1,820 | 35,300 | 105,000 | 35,000
|
| lisp | 844 | 974 | 30,100 | 19,000 | 14,000
|
| prolog | 789 | 2,010 | 23,200 | 17,000 | 16,000
|
| python | 785 | 1,240 | 18,400 | 11,000 | 12,000
|