Ioannis Filippidis

I am fine with either. Thanks for spotting this inconsistency. Also, at some point it would be interesting to vary the examples a little, possibly by also changing the "story"....

It is not very difficult to adjust `dd.cudd`, it can be done by changing `CUDD_PATH`, which is defined [in `download.py`](https://github.com/johnyf/dd/blob/bfe36d4b68dc0a878772b287b1c38e4bbec303b0/download.py#L39). One possibility is to add an optional command line argument...

Building or fetching a binary (perhaps as is done for `gr1c`) for CUDD needs to happen first, because the default solver (e.g., `omega`) is installed before optional dependencies are tested...

`dd == 0.4.3` has been released. It uses CUDD v3.0.0 and supports passing a path to the CUDD installation, so in principle it should now be possible to build CUDD...

Running the image with `docker` lands me within `~/tulip-control`, i.e., ```sh docker run -i -t tulip:latest source PYt/bin/activate python -c 'import tulip; print(tulip.__version__)' ``` where `tulip-control` has been removed compared...

I created an image from the `Dockerfile` and run it from an pre-existing Docker installation, with no effort dedicated to this PR. This witnesses the simplicity of the proposed approach....

I intend to study my notes [above](https://github.com/tulip-control/tulip-control/pull/187#issuecomment-334350308), because I think it may be possible to simplify them. For example, placing an image in an external service could introduce a dependency...

Looking back at ca5a80d8b91e79345c27de0629d683f95cfeb455 and the commits in #168 before rebase, I think that the `'message'` is an error introduced by me here: https://github.com/tulip-control/tulip-control/commit/4d1cac37fc39846e9d7986536e6a496c7dbc37f4#diff-db73a44c4631fa5fc7c04bff0f7d729aR449 during the rebase. I am fine...

This observation involves deeper design issues about `PPP` and the use of an `OpenFTS` in `AbstractSysDyn` as of e2680bd53002d87110fd3eaa19f1a8483ddd1264: AP labels are duplicated in sets [`Region.props`](https://github.com/tulip-control/tulip-control/blob/e2680bd53002d87110fd3eaa19f1a8483ddd1264/tulip/polytope/polytope.py#L411) annotating [`PPP.regions`](https://github.com/tulip-control/tulip-control/blob/e2680bd53002d87110fd3eaa19f1a8483ddd1264/tulip/abstract/prop2partition.py#L417) and in...

I agree that the overall abstraction need not be a partition, with overlaps allowed. But I think that overlaps within the same partition should not be allowed. Overlaps between elements...