Mercurial > pylearn
comparison doc/v2_planning/arch_src/plugin_JB_comments_RP.txt @ 1221:699ed5f5f188
answer to James comment
| author | Razvan Pascanu <r.pascanu@gmail.com> |
|---|---|
| date | Wed, 22 Sep 2010 14:02:37 -0400 |
| parents | 35fb6e9713d2 |
| children |
comparison
equal
deleted
inserted
replaced
| 1220:35fb6e9713d2 | 1221:699ed5f5f188 |
|---|---|
| 101 | 101 |
| 102 I don't think it's necessary to combine theano with this control-flow | 102 I don't think it's necessary to combine theano with this control-flow |
| 103 proposal, and I don't know how to do it. Yes, it seems like it would be hard | 103 proposal, and I don't know how to do it. Yes, it seems like it would be hard |
| 104 and/or awkward, and I don't even really see the advantage of even trying to do | 104 and/or awkward, and I don't even really see the advantage of even trying to do |
| 105 it. | 105 it. |
| 106 | |
| 107 RP: | |
| 108 | |
| 109 I think you misunderstood me. I did not propose to mix Theano with the | |
| 110 library. I agree that would be awkward. What I had in mind ( which might be | |
| 111 just something different from what you are doing) is to use some concepts | |
| 112 from how Theano deals with things. | |
| 113 | |
| 114 For example right now you added registers. Writing something like: | |
| 115 | |
| 116 CALL( fn, arg1, arg2, arg3, _set= reg('x') ) | |
| 117 | |
| 118 means actually reg('x') = fn (arg1,arg2,arg3) | |
| 119 | |
| 120 You get most of what you want because this control flow elements don't | |
| 121 actually get executed until you run the program. That means that you | |
| 122 have a fixed simple graph ( you can't play around with it) that tells | |
| 123 how to execute your commands. You can save that graph, and the point in | |
| 124 the graph where you stop so that you can resume latter. You can also | |
| 125 save all registers at that point. | |
| 126 | |
| 127 | |
| 128 Why not have that fn instead of being a python function, be some class | |
| 129 that implements a method run which does what your call would do. | |
| 130 The init/ or __call__ of that class would do what CALL does in your case. | |
| 131 Do you think that would be impossible to implement? Any such function | |
| 132 could either return a set of registers or not. | |
| 133 | |
| 134 Your other control flow things will be just special such functions. | |
| 135 The only thing that would might look a bit strange would be the sequence | |
| 136 in case you need to return things. Maybe I could use the same trick, | |
| 137 namely a _set arguemnt to __call__. | |
| 138 | |
| 139 I'm not against your approach, I just think it can be written a bit | |
| 140 differently, which in my opinion is easier to read, understand and so | |
| 141 on. I will have nothing against if we decide to write it exactly how you | |
| 142 propose and I'm sure that I will get the hang of it pretty fast. | |
| 143 | |
| 144 | |
| 145 Bottom line (in my view): | |
| 146 - I don't say we should mix Theano with anything | |
| 147 - I think writing things such that it looks like applying functions to | |
| 148 object is a more natural way, easy to understand for noobs | |
| 149 - Writing a new functions by inheriting a class and implementing a method | |
| 150 is also natural | |
| 151 - I do not propose to do optimizations or play with the graph ! I do | |
| 152 though think that you should be able to : | |
| 153 * replace parts of a subgraph with a different | |
| 154 * automatically collect hyper-parameters or parameters if you ever want | |
| 155 to | |
| 156 * change the value of these somehow |