Mercurial > pylearn
comparison doc/v2_planning/arch_src/plugin_JB_comments_YB.txt @ 1238:067b2f9ba122
comments by YB on JB's arch_sr/plugin_JB.py
| author | Yoshua Bengio <bengioy@iro.umontreal.ca> |
|---|---|
| date | Thu, 23 Sep 2010 11:49:19 -0400 |
| parents | |
| children | 316410a38f6f |
comparison
equal
deleted
inserted
replaced
| 1233:91c285e30364 | 1238:067b2f9ba122 |
|---|---|
| 1 | |
| 2 YB. I am very worried about this proposal. It looks again like we would be | |
| 3 creating another language to replace one we already have, namely python, | |
| 4 mainly so that we could have introspection and programmable changes | |
| 5 into an existing control flow structure (e.g. the standard DBN code). | |
| 6 | |
| 7 I feel that the negatives outweigh the advantages. | |
| 8 | |
| 9 Please correct me: | |
| 10 | |
| 11 Disadvantages: | |
| 12 | |
| 13 * much more difficult to read | |
| 14 * much more difficult to debug | |
| 15 | |
| 16 Advantages: | |
| 17 | |
| 18 * easier to serialize (can't we serialize an ordinary Python class created by a normal user?) | |
| 19 * possible but not easier to programmatically modify existing learning algorithms | |
| 20 (why not the usual constructor parameters and hooks, | |
| 21 when possible, and just create another code for a new DBN variant when it can't fit?) | |
| 22 * am I missing something? | |
| 23 | |
| 24 I am not convinced that any of the stated advantages can't be achieved in more traditional ways. | |
| 25 | |
| 26 |