Mercurial > pylearn
comparison doc/v2_planning/optimization.txt @ 1149:7c5dc11c850a
cleaning up api_optimization
author | James Bergstra <bergstrj@iro.umontreal.ca> |
---|---|
date | Thu, 16 Sep 2010 16:26:21 -0400 |
parents | 2cf3ad953bf9 |
children | f2105a06201c |
comparison
equal
deleted
inserted
replaced
1148:2da593b0f29d | 1149:7c5dc11c850a |
---|---|
49 Proposal for API | 49 Proposal for API |
50 ================ | 50 ================ |
51 | 51 |
52 See api_optimization.txt. | 52 See api_optimization.txt. |
53 | 53 |
54 OD: Do we really need a different file? If yes, maybe create a subdirectory to | 54 OD asks: Do we really need a different file? If yes, maybe create a subdirectory |
55 be able to easily find all files related to optimization? | 55 to be able to easily find all files related to optimization? |
56 | |
57 JB replies: Yoshua's orders. | |
58 | |
59 | |
60 | |
61 OD asks: Could it be more convenient for x0 to be a list? | |
62 | |
63 JB replies: Yes, but that's not the interface used by other minimize() | |
64 routines (e.g. in scipy). Maybe another list-based interface is required? | |
65 | |
66 OD replies: I think most people would prefer to use a list-based interface, so | |
67 they don't have to manually pack / unpack multiple arrrays of parameters. So I | |
68 would vote in favor or having both (where the main reason to also provide a | |
69 non-list interface would be to allow one to easily switch e.g. to scipy's | |
70 minimize). | |
71 I would guess the reason scipy's interface is like this is because it makes | |
72 it easier for the optimization algorithm. However, this does not really | |
73 matter if we are just wrapping a theano-based algorithm (that already has | |
74 to handle multiple parameters), and avoiding useless data copies on each call | |
75 to f / df can only help speed-wise. | |
76 JB replies: Done, I added possibility that x0 is list of ndarrays to the api | |
77 doc. | |
78 | |
79 | |
80 | |
81 OD asks: Why make a difference between iterative and one-shot versions? A one-shot | |
82 algorithm can be seen as an iterative one that stops after its first | |
83 iteration. The difference I see between the two interfaces proposed here | |
84 is mostly that one relies on Theano while the other one does not, but | |
85 hopefully a non-Theano one can be created by simply wrapping around the | |
86 Theano one. | |
87 | |
88 JB replies: Right, it would make more sense to distinguish them by the fact that | |
89 one works on Theano objects, and the other on general Python callable functions. | |
90 There is room for an iterative numpy interface, but I didn't make it yet. Would | |
91 that answer your question? | |
92 | |
93 OD replies and asks: Partly. Do we really need a non-iterative interface? | |
94 |