Mercurial > pylearn
annotate doc/v2_planning/architecture.txt @ 1169:3a1225034751
merge
author | Pascal Lamblin <lamblinp@iro.umontreal.ca> |
---|---|
date | Fri, 17 Sep 2010 14:29:49 -0400 |
parents | ae5ba6206fd3 |
children | f111f8c2a280 |
rev | line source |
---|---|
1098
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
1 ==================== |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
2 Pylearn Architecture |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
3 ==================== |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
4 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
5 |
1115
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
6 SE + VM Approach |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
7 ================= |
1098
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
8 |
1115
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
9 One avenue for the basic design of the library is to follow the Symbolic |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
10 Expression (SE) structure + virtual machine (VM) pattern that worked for Theano. |
1098
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
11 |
1115
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
12 The main things for the library to provide would be: |
1098
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
13 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
14 - a few VMs, some of which can run programs in parallel across processors, |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
15 hosts, and networks [R6,R8]; |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
16 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
17 - MLA components as either individual Expressions (similar to Ops) or as |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
18 subgraphs of SEs [R5,R7,R10,R11] |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
19 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
20 - machine learning algorithms including their training and testing in the form |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
21 of python functions that build SE graphs.[R1,R8]. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
22 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
23 This design addresses R2 (modularity) because swapping components is literally implemented by |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
24 swapping subgraphs. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
25 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
26 The design addresses R9 (algorithmic efficiency) because we can write |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
27 Theano-style graph transformations to recognize special cases of component |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
28 combinations. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
29 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
30 The design addresses R3 if we make the additional decision that the VMs (at |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
31 least sometimes) cache the return value of program function calls. This cache |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
32 serves as a database of experimental results, indexed by the functions that |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
33 originally computed them. I think this is a very natural scheme for organizing |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
34 experiment results, and ensuring experiment reproducibility [R1]. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
35 At the same time, this is a clean and simple API behind which experiments can be |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
36 saved using a number of database technologies. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
37 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
38 APIs vs. lambda |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
39 ---------------- |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
40 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
41 Modularity in general is achieved when pieces can be substituted one for the |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
42 other. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
43 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
44 In an object-oriented design, modularity is achieved by agreeing on interface |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
45 APIs, but in a functional design there is another possibility: the lambda. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
46 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
47 In an SE these pieces are expression [applications] and the subgraphs they form. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
48 A subgraph is characterized syntactically within the program by its arguments |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
49 and its return values. A lambda function allows the User to create new |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
50 Expression types from arbitrary subgraphs with very few keystrokes. When a |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
51 lambda is available and easy to use, there is much less pressure on the |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
52 expression library to follow calling and return conventions strictly. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
53 |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
54 Of course, the closer are two subgraphs in terms of their inputs, outputs, and |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
55 semantics, the easier it is to substitute one for the other. As library |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
56 designers, we should still aim for compatibility of similar algorithms. It's |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
57 just not essential to choose an API that will guarantee a match, or indeed to |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
58 choose any explicit API at all. |
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
59 |
1125
5387666d49b4
YB: comment on lambdas vs API for architecture.txt
Yoshua Bengio <bengioy@iro.umontreal.ca>
parents:
1115
diff
changeset
|
60 YB: I agree that lambdas are more flexible, but from the user's point of |
5387666d49b4
YB: comment on lambdas vs API for architecture.txt
Yoshua Bengio <bengioy@iro.umontreal.ca>
parents:
1115
diff
changeset
|
61 view it is really important to know what can swap with what, so that they |
5387666d49b4
YB: comment on lambdas vs API for architecture.txt
Yoshua Bengio <bengioy@iro.umontreal.ca>
parents:
1115
diff
changeset
|
62 can easily plug-and-play. So even if informal, something in the spirit |
5387666d49b4
YB: comment on lambdas vs API for architecture.txt
Yoshua Bengio <bengioy@iro.umontreal.ca>
parents:
1115
diff
changeset
|
63 of an API must be described somewhere, and components should declare |
1126
7ba1854f03e7
YB: comment on lambdas vs API for architecture.txt
Yoshua Bengio <bengioy@iro.umontreal.ca>
parents:
1125
diff
changeset
|
64 either formally or through comments what functionality 'type' |
7ba1854f03e7
YB: comment on lambdas vs API for architecture.txt
Yoshua Bengio <bengioy@iro.umontreal.ca>
parents:
1125
diff
changeset
|
65 they can take on. |
1125
5387666d49b4
YB: comment on lambdas vs API for architecture.txt
Yoshua Bengio <bengioy@iro.umontreal.ca>
parents:
1115
diff
changeset
|
66 |
1107
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
67 Encapsulation vs. linearity |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
68 --------------------------- |
1098
4eda3f52ebef
v2planning - revs to requirements, added architecture
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
diff
changeset
|
69 |
1107
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
70 A while ago, the Apstat crew went to fight "encapsulation" to propose instead |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
71 a more "linearized" approach to experiment design. I must admit I didn't |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
72 really understand the deep motivations behind this, and after practicing both |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
73 styles (encapsulation for PLearn / Theano, linearity @ ARL / Ubisoft), I still |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
74 don't. I do find, however, some not-so-deep-but-still-significant advantages |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
75 to the linear version, which hopefully can be made clear (along with a |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
76 clarification of what the h*** am I talking about) in the following example: |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
77 |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
78 * Linear version: |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
79 my_experiment = pipeline([ |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
80 data, |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
81 filter_samples, |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
82 PCA, |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
83 k_fold_split, |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
84 neural_net, |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
85 evaluation, |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
86 ]) |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
87 |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
88 * Encapsulated version: |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
89 my_experiment = evaluation( |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
90 data=PCA(filter_samples(data)), |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
91 split=k_fold_split, |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
92 model=neural_net) |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
93 |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
94 What I like in the linear version is it is much more easily human-readable |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
95 (once you know what it means): you just follow the flow of the experiment by |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
96 reading through a single list. |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
97 On the other hand, the encapsulated version requires some deeper analysis to |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
98 understand what is going on and in which order. |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
99 Also, commenting out parts of the processing is simpler in the first case (it |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
100 takes a single # in front of an element). |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
101 However, linearity tends to break when the experiment is actually not linear, |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
102 i.e. the graph of object dependencies is more complex (*). |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
103 |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
104 I'm just bringing this up because it may be nice to be able to provide the |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
105 user with the most intuitive way to design experiments. I actually don't think |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
106 those approaches are mutually exclusive, and it could be possible for the |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
107 underlying system to use the more flexible / powerful encapsulated |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
108 representation, while having the option to write simple scripts in a form that |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
109 is easier to understand and manipulate. |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
110 |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
111 It could also be worth discussing this issue with Xavier / Christian / |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
112 Nicolas. |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
113 |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
114 (*) Note that I cheated a bit in my example above: the graph from the |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
115 encapsulated version is not a simple chain, so it is not obvious how to |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
116 convert it into the pipeline given in the linear version. It's still possible |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
117 though, but this is probably not the place to get into the details. |
e5306f5626d4
architecture: Yet another rant, this time about encapsulation vs. linearization
Olivier Delalleau <delallea@iro>
parents:
1098
diff
changeset
|
118 |
1153
ae5ba6206fd3
a first draft of pseudo-code for logreg .. using version B (?) approach
Razvan Pascanu <r.pascanu@gmail.com>
parents:
1129
diff
changeset
|
119 RP comment : The way I see it, you could always have everything using the |
ae5ba6206fd3
a first draft of pseudo-code for logreg .. using version B (?) approach
Razvan Pascanu <r.pascanu@gmail.com>
parents:
1129
diff
changeset
|
120 encapsulation paradigm ( which as you pointed out is a bit more powerful) and |
ae5ba6206fd3
a first draft of pseudo-code for logreg .. using version B (?) approach
Razvan Pascanu <r.pascanu@gmail.com>
parents:
1129
diff
changeset
|
121 then have linear shortcuts ( functions that take a list of functions and some |
ae5ba6206fd3
a first draft of pseudo-code for logreg .. using version B (?) approach
Razvan Pascanu <r.pascanu@gmail.com>
parents:
1129
diff
changeset
|
122 inputs and apply them in some order). You will not be able to have a one case |
ae5ba6206fd3
a first draft of pseudo-code for logreg .. using version B (?) approach
Razvan Pascanu <r.pascanu@gmail.com>
parents:
1129
diff
changeset
|
123 cover all pipeline function, but I think it is sufficient to offer such |
ae5ba6206fd3
a first draft of pseudo-code for logreg .. using version B (?) approach
Razvan Pascanu <r.pascanu@gmail.com>
parents:
1129
diff
changeset
|
124 options (linear functions) for a few widely used cases .. |
1115
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
125 |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
126 |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
127 Jobman Compatibility Approach |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
128 ============================= |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
129 |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
130 One basic approach for the library is to provide a set of components that are |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
131 compatible with remote execution. The emphasis could be not so much on |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
132 standardizing the roles and APIs of components, so much as ensuring that they |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
133 can be glued together and supports parallel execution on one or more CPUs or |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
134 clusters. |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
135 |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
136 In this approach we would provide a proxy for asynchronous execution |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
137 (e.g. "pylearn.call(fn, args, kwargs, backend=default_backend)"), which would |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
138 come with constraints on what fn, args, and kwargs can be. Specifically, they |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
139 must be picklable, and there are benefits (e.g. automatic function call caching) |
1129
40c1461ce9ef
architecture: Minor typo fix
Olivier Delalleau <delallea@iro>
parents:
1126
diff
changeset
|
140 associated with them being hashable as well. |
1115
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
141 |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
142 |
967975f9c574
added Jobman compatibility to architecture.txt
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1107
diff
changeset
|
143 |