Mercurial > pylearn
comparison doc/v2_planning/main_plan.txt @ 1019:91916536a304
merge
| author | gdesjardins |
|---|---|
| date | Fri, 03 Sep 2010 15:01:23 -0400 |
| parents | 2e515be92a0e |
| children | bc246542d6ff |
comparison
equal
deleted
inserted
replaced
| 1018:790376d986a3 | 1019:91916536a304 |
|---|---|
| 1 | 1 |
| 2 Motivation | 2 Motivation |
| 3 ========== | 3 ========== |
| 4 | |
| 5 Yoshua (points discussed Thursday Sept 2, 2010 at LISA tea-talk) | |
| 6 ------ | |
| 7 | |
| 8 ****** Why we need to get better organized in our code-writing ****** | |
| 9 | |
| 10 - current state of affairs on top of Theano is anarchic and does not lend itself to easy code re-use | |
| 11 - the lab is growing and will continue to grow significantly, and more people outside the lab are using Theano | |
| 12 - we have new industrial partners and funding sources that demand deliverables, and more/better collectively organized efforts | |
| 13 | |
| 14 *** Who can take advantage of this *** | |
| 15 | |
| 16 - us, directly, taking advantage of the different advances made by different researchers in the lab to yield better models | |
| 17 - us, easier to compare different models and different datasets with different metrics on different computing platforms available to us | |
| 18 - future us, new students, able to quickly move into 'production' mode without having to reinvent the wheel | |
| 19 - students in the two ML classes, able to play with the library to explore new ML variants | |
| 20 - other ML researchers in academia, able to play with our algorithms, try new variants, cite our papers | |
| 21 - non-ML users in or out of academia, and our user-partners | |
| 22 | |
| 23 | |
| 24 *** Move with care *** | |
| 25 | |
| 26 - Write down use-cases, examples for each type of module, do not try to be TOO general | |
| 27 - Want to keep ease of exploring and flexibility, not create a prison | |
| 28 - Too many constraints can lead to paralysis, especially in C++ object-oriented model | |
| 29 - Too few guidelines lead to code components that are not interchangeable | |
| 30 - Poor code practice leads to buggy, spaguetti code | |
| 31 | |
| 32 *** What *** | |
| 33 | |
| 34 - define standards | |
| 35 - write-up a few instances of each basic type (dataset, learner, optimizer, hyper-parameter exploration boilerplate, etc.) enough to implement some of the basic algorithms we use often (e.g. like those in the tutorials) | |
| 36 - let the library grow according to our needs | |
| 37 - keep tight reins on it to control quality | |
| 38 | |
| 39 *** Content and Form *** | |
| 40 | |
| 41 We need to establish guidelines and conventions for | |
| 42 | |
| 43 * Content: what are the re-usable components? define conventions or API for each, make sure they fit with each other | |
| 44 * Form: social engineering, coding practices and conventions, code review, incentives | |
| 4 | 45 |
| 5 Yoshua: | 46 Yoshua: |
| 6 ------- | 47 ------- |
| 7 | 48 |
| 8 We are missing a *Theano Machine Learning library*. | 49 We are missing a *Theano Machine Learning library*. |