--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/v2_planning/arch_src/plugin_JB_comments_RP.txt	Wed Sep 22 10:39:39 2010 -0400
@@ -0,0 +1,60 @@
+I agree with Ian, maybe using caps is not the best idea. It reminds be of BASIC which I used to do long time ago :). It also makes the code look a bit scary.
+
+I like the approach and I think it goes close to my earliest proposition and to what I am proposing for the layer committeee ( though we did not have a meeting yet). 
+I would though write it in a more Theano like ( Ian has a example of how that would look). I would also drop the CALL and FLIT constructs, and actually have a 
+decorator ( or something ) that wraps around a function to transform it into a call or flit. I hope that this is only syntactic sugar ( does this change anything
+in the actual implementation ?? ) that makes things more natural. What I want to reach is something that looks very much as Theano, just that now you are creating
+the graph of execution steps. Refractoring what you wrote this will look like
+
+x = buffer_repeat( 1000, dataset.next())
+train_pca = pca.analyze(x)
+
+train_pca.run()
+
+If you allow a FLIT to also get multiple inputs ( so not just the one) which comes natural in this way of writing you can get to describe a DAG that not only 
+describes the order of execution but also deals with what takes data from what. I'm sorry for not being there yesturday, from what I remember I have the 
+feeling that for you that is done under the hood and not taken care by this flow control structures. 
+
+To be a bit more explicit, in the way of writing the code above you can see that :
+  a) dataset_next() has to run before pca_analyze
+  b) pca_analyze needs the result (data) object of buffer_repeat( dataset.next()) 
+
+I've actually elaborated on this idea here and there, and figured out what the result from such a control flow thing is, and how to make everything explicit 
+in the graph. Parts of this is in my plugin_RP.py ( Step 1) though it is a bit of a moving target. I also have a sligtly different way of writing REPEAT 
+and BUFFER_REPEAT .. though I think is mostly the same. I actually did not know how to deal with distributed things until I saw how you deal with that in your code.
+Copy-pasted a version of a SDAA with my way of writing : 
+
+    ## Layer 1:
+
+    data_x,data_y = GPU_transform(load_mnist())
+    noisy_data_x  = gaussian_noise(data_x, amount = 0.1)
+    hidden1       = tanh(dotW_b(data_x, n_units = 200))
+    reconstruct1  = reconstruct(hidden1.replace(data_x, noisy_data_x),
+                            noisy_data_x)
+    err1          = cross_entropy(reconstruct1, data_x)
+    learner1      = SGD(err1)
+
+    # Layer 2 :
+    noisy_hidden1 = gaussian_noise(hidden1, amount = 0.1)
+    hidden2       = tanh(dotW_b(hidden1, n_units = 200))
+    reconstruct2  = reconstruct(hidden2.replace(hidden1,noisy_hidden1),
+                            noisy_hidden1)
+    err2          = cross_entropy(reconstruct2, hidden)
+    learner2      = SGD(err2)
+
+    # Top layer:
+
+    output  = sigmoid(dotW_b(hidden2, n_units = 10))
+    err     = cross_entropy(output, data_y)
+    learner = SGD(err)
+
+
+GPU_transform,gaussian_noise and so on are functions that have been decorated ( or classes if you want) 
+that you would write using FLIT.  Reconstruct for me is a different CONTROL FLOW element. 
+In this case I don't use REPEAT or BUFFER_REPEAT or the other very cool control flow elements, but you
+can easily imagine writing something like
+
+pretrained_in_parallel = weave( learner1, learner2)
+results = spawn(repeat(5000,learner1),repeat(500,learner2))
+
+