# HG changeset patch # User Olivier Delalleau # Date 1285599540 14400 # Node ID 93e1c7c9172b200fd5ca920ef9c1a29c89e34773 # Parent a565c20a39d73b2f124e1c66f3b0cc76dffe5e8a Added a comment on architecture discussion diff -r a565c20a39d7 -r 93e1c7c9172b doc/v2_planning/architecture_discussion.txt --- a/doc/v2_planning/architecture_discussion.txt Sun Sep 26 14:10:33 2010 -0400 +++ b/doc/v2_planning/architecture_discussion.txt Mon Sep 27 10:59:00 2010 -0400 @@ -95,3 +95,18 @@ problem, by having a special function that could alter the pipeline in some way (for example by introducing new components). +OD comments: It seemed to me that one major issue we are trying to solve with +these approaches is that of being able to interrupt an experiment, then +restart it later without starting again from scratch. OB and JB's proposals +handle this more or less automatically (compared to PL's that would require +more manual engineering of the save/load process). However it is not obvious +to me that they would necessarily make things much easier, because: + - One needs to use the same "framework" in all pieces of code (the + + syntax for OB, or a single program for JB), otherwise some manual + engineering will also be required. Can we reasonably expect the whole + code to adhere to this? (maybe...) + - If you want to be smart about what you (or rather do not) want to save, + it may add yet another layer of complexity (I'm not sure though how hard + it would be, so it'd be nice to have an example, e.g. if you are doing + K-Fold CV with the training set stored in memory, but you don't want to + save it on disk when serializing your experiment).