add successor, predecessor, and equality tasks

This commit adds three new task types:

- successor -> learn to add one to a set
- predecessor -> learn to remove one from a set
- equality -> learn to judge if two sets are the same size

This commit also switches to a list-based "bag", where the operations
for bags are defined over lists. Doing so avoids adding any complexity
to the E.C. type system.
add more and less tasks

The number simulation now contains 5 types of tasks:

- predecessor to
- successor to
- equal to
- greater than
- less than

Also, I fixed a bug in the library. Previously, the basic-level object
(in this case, the integer 1) was listed in the wrong library and wasn't
available for number learning. Now, it's been moved to the number
learning library and is available.

Also, I decreased the learning threshold in the test script in an
attempt to increase the number of productions that are available for the
grammar to recombine.

Finally, I changed the "bag" functions in the library to make use of the
built-in set functions defined over lists.
increase p(<>), increase iterations, binary LL

- I've increased the probability of application to 0.375, which seems to
  generate sufficiently long functions to learn the tasks we need. If
  anything, it might now be slightly too high to encourage optimally
  compressed learning.
- I've increased the number of iterations from 10 to 20. I don't know
  that I need it, but I want to give the model every chance to learn.
- I changed the log likelihood in each task to be binary rather than
  graded. As we move toward each task having only a single answer in the
  first place, this sort of evaluation makes sense. I don't have any
  proof, but it seems intuitive to me to suppose that binary log
  likelihoods provide greater impetus for experimenting to find optimal
  forms.

Successful learning on 20140515 took place with a frontier of 3000, but
I might be able to learn with a smaller frontier.
Multi-task version compiles - need to rewrite

I have a multi-task version of the number learning code which compiles
and runs. I'm saving it here, after a conversation with Eyal Dechter
pointed out a key design flaw. As single tasks, all my problems can be
easily solved by ignoring the arguments and returning True or False.
single number task compiles -- need to rewrite

Just as with the previous commit, I have compiling code, but I think the
basic representation is incorrect. I'd like something which is more
focused on a general world and general query. We can then grow more
complex from there. So, rather than solving a specific interesting task
from a highly specific world, I'm going to start with a generic world
and solve the most basic tasks I can imagine.
(Det, Noun, world) -> world, 1 task, no learning

I've changed the task architecture to be from an ad-hoc triple to a set
(the world) to be from a Determiner, Noun, and World triple to a world.
I've still been using a single task, though, which I now think is a
mistake. Primarily, I think the drive to compress should come from E.C.,
not the task structure. We still encounter tasks as ad-hoc, and we don't
necessarily know how to respond coherently to them. Compression should
teach us to do that and generalize appropriately. So, I'm recording this
for posterity and moving to re-introduce multiple tasks. I think that,
as long as we forego the ability to ignore arguments (no K combinator),
this approach has a decent shot at working.
test goal program, push for Eyal's review

I've tested a goal program to represent knowledge of "one", "two",
"all", "X", "O", and "thing". The program is long, but it is
representable and fairly compositional.

I'm pushing all this to GitHub for Eyal's review.
Merge branch 'generic_world' into single_number_task
Merge branch 'single_number_task' into number_learning