# HG changeset patch # User James Bergstra # Date 1285171950 14400 # Node ID 5a8930e089ed3a946a08300a7a5b9c632b82db0a # Parent 4754661ad6ab3d4ce55894a061905bde4125a81a replied in plugin_JB_comments_RP diff -r 4754661ad6ab -r 5a8930e089ed doc/v2_planning/arch_src/plugin_JB_comments_RP.txt --- a/doc/v2_planning/arch_src/plugin_JB_comments_RP.txt Wed Sep 22 11:58:04 2010 -0400 +++ b/doc/v2_planning/arch_src/plugin_JB_comments_RP.txt Wed Sep 22 12:12:30 2010 -0400 @@ -1,8 +1,11 @@ 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. +JB replies: personally i think it makes the code look more AWESOME but I could +go either way. See reply to Ian in plugin_JB_comments_IG.txt + 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 +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 FILT constructs, and actually have a +decorator ( or something ) that wraps around a function to transform it into a call or filt. 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 @@ -11,7 +14,7 @@ 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 +If you allow a FILT 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. @@ -50,7 +53,7 @@ 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. +that you would write using FILT. 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 @@ -58,3 +61,30 @@ results = spawn(repeat(5000,learner1),repeat(500,learner2)) +JB replies: + + This reply makes it clearer to me that I was not sensitive enough to the + difference between *expressions* and *control-flow statements*. What you have + above is a graph of declarative expressions (if I understand correctly) with + certain properties: + + - they have no side effects + - they can be re-ordered within dependency constraints + + Contrast this with the CALL statements in my proposal: + + - they work primarily by side effect + - they cannot be re-ordered at all + + So the fact that CALL currently works by side effect means that there is + almost no graph-manipulation that can be guaranteed not to change the program. + This is a reason to make CALL statements *encapsulate* programs constructed + using declarative constructs (i.e. Theano functions) + + In other words, in this short term, this feels to me like the reason to *not* + mix Theano graph building with this control-flow business. + + Consequently, I think I will remove the BUFFER_REPEAT construct since that is + really an expression masquerading as a control flow statement, and I will + remove FILT too. +