tulip-control
save abstractions
An abstraction can take a long, to a very long time. There might exist simple bugs later in the code. Or the partition might need different parameters. Or changes might be needed to the continuous propositions to make the problem realizable.
Studying the resulting abstraction is needed to trace each problem's root cause. Currently this requires either re-running the file, or working in a python console (e.g., ipython). Re-running is certainly undesired, whereas ipython is not so friendly to reloading code.
A better setup is to save the abstraction and run a script that loads it and continues from there.
If the purpose is to save the results of some intermediate costly computations while developing new code, I just use pickle.
Pickles are useful for work that only needs to stay on one computer. Once you move a pickle to another directory, the pickle stops working. I believe what Ioannis had in mind was being able to export a data structure so that multiple people with multiple computers could examine it.
I remember exchanging pickled files with people using different platforms without any problem. With a quick search, this seems mostly fine. But a more human-readable format might have other advantages or uses.
A more apropos reference: http://docs.python.org/2.7/library/pickle.html#data-stream-format
@stsuei: did sharing pickles across platforms fail for you when working with tulip? If so, how?
It's been a couple years since I've used pickle. But thinking back, I think that my problems may have involved moving pickle files generated from a script importing python modules that were not "installed" from directory to directory on the same computer - so my problems with pickles were probably irrelevant. I apologize for any confusion I might have caused.
At this point, the only reason I see for having some sort of exporter outside of pickle is to allow non-Python programs to read abstractions as well.
The original statement of this issue is ambiguous as to whether
- a non-pickle format is required, and
- software besides TuLiP should be able to read the saved abstractions
before this issue would be closed. @johnyf , can you comment on intent for this particular issue (#59)?
If the answer is "no" to the above two items, then it may be possible to close this issue after the following steps.
- Write load and dump methods for
PropPreservingPartitionandAbstractSysDyn, including version numbers and regression tests; - Create an example demonstrating their usage. This could take the form of at least one of the following:
- Fork from one of the scripts under
examples/robot_planning/that has a section usingloadanddump, and has other parts trimmed away that are not crucial for the demo; - Write a page in the User's Guide describing how to use them, e.g., demonstrated by snippets from a Python interactive session.
My original intent was mainly to export/import from python, and did not reject pickle, but was not sure whether it is the appropriate solution. Later discussions about more general export functionality needed to provide executable controllers to other software outside tulip indicated that an xml format could solve both problems at once. Exporting abstractions in xml separately from controller machines also provides a means of separating the discrete from the continuous layer, in case someone wants to reuse an abstraction for their own purposes (e.g., use another game solver and write code in their favorite language - not that I am interested or support working in non-python, but for completeness).
I think that a dependable load/dump mechanism as described above can close this issue, with respect to the original intent at the time it was opened.
For completeness: I didn't use pickle in the past, one concern being that not everything is pickleable. Trying out with some data containing AbstractPwa and MealyMachine, I get:
pickle.PicklingError: Can't pickle <function <lambda> at 0x15a9bde8>: it's not found as tulip.interfaces.gr1c.<lambda>
I haven't yet debugged the above, but it seems we either have to make sure everything is pickleable, or dump in some other format. Note that the other format will be needed anyway for external tools. However pickle seems to be quite convenient.
Fixed by d0b9e9a26372f1872527ec0b5f94e38ef4ce62f9 (there was a single lambda in all of interfaces.gr1 - wasn't hard to spot).
Based on the changeset d0b9e9a26372f1872527ec0b5f94e38ef4ce62f9, I suspect that the previous comment should have been "...single lambda in all of interfaces.gr1c...".
A demonstration of using pickle for saving and loading abstractions is given, as of 01ffa4f96dc46a13024e9c5a3d9d7d25548d0bd9, in lines 205-208 of double_tank.py.
While it may suffice for interactive computation as described in the OP, pickling as demonstrated in double_tank.py may fail in other important use-cases, e.g., trying to use the pickled data across different versions of TuLiP, or accessing the data without TuLiP or Python. Thus I recommend that the issue remains open until the broader question of file formats is addressed, which will in particular provide an answer about saving abstractions (this issue).
We already have issue #69, which is about loading and saving in XML. We may want to create a separate design proposal based on JSON.