# HG changeset patch # User Olivier Delalleau # Date 1284404620 14400 # Node ID e7c52923f122b394e70ce73bc690eb2f40aac243 # Parent b422cbaddc52470a83da184e820c9f42ef7df01c api_optimization: Couple replies diff -r b422cbaddc52 -r e7c52923f122 doc/v2_planning/api_optimization.txt --- a/doc/v2_planning/api_optimization.txt Mon Sep 13 13:42:26 2010 -0400 +++ b/doc/v2_planning/api_optimization.txt Mon Sep 13 15:03:40 2010 -0400 @@ -114,6 +114,17 @@ JB replies: Yes, but that's not the interface used by other minimize() routines (e.g. in scipy). Maybe another list-based interface is required? +OD replies: I think most people would prefer to use a list-based interface, so + they don't have to manually pack / unpack multiple arrrays of parameters. So I + would vote in favor or having both (where the main reason to also provide a + non-list interface would be to allow one to easily switch e.g. to scipy's + minimize). + I would guess the reason scipy's interface is like this is because it makes + it easier for the optimization algorithm, and the packing / unpacking is + typically done only once for non-iterative algorithms. However, the first + point does not matter if we are just wrapping a theano-based algorithm that + already has to handle multiple parameters (and the second may not hold if + we allow iterative algorithms). OD asks: Why make a difference between iterative and one-shot versions? A one-shot algorithm can be seen as an iterative one that stops after its first @@ -127,7 +138,7 @@ There is room for an iterative numpy interface, but I didn't make it yet. Would that answer your question? - +OD replies and asks: Partly. Do we really need a non-iterative interface? Examples --------