On Sat, Dec 01, 2012 at 05:09:00PM -0500, Konstantin Berlin wrote: > >> > >> My opinion is that the package should be organized by what it does rather, > >> than how it does it. > > > > My proposal is based on what the user wants to do and on what input is > > required in order to use the tools in the given package, where all > > algorithms will share the same interface. > > > > I humbly disagree with your claim. The user does not want a vector nor a > Jcobian. The user has a problem, and they want to see their options for a > solution. That is why they will go into, for example, least-squares. They > will see that there are different kinds, so they will go into linear, for > example. There they will see all their options and what they need to make it > work.
There are probably various way to look at a "problem". For example, I have a leastsquares "problem" but evaluating the derivatives is expensive (finite differences), so I nevertheless use the classes in "direct" (no derivatives). [We had another discussion (raised by someone who detected what could be assimilated to bugs) about the "Complex" class (cf. MATH-667). But since nobody actually uses this class (in ways that trigger the issues), there is no push to implement another "view". Not sure that illustrates a point somehow... :-)] > I also have a problem with how you targeting the package to naive people who > want to play around with packages. You want the package to be easily > accessible to people who require optimizations. I would imagine most users > have a good idea what kind of problem that they have are looking for the > optimizer that will solve their problem. By structuring the packages in the > way I describe, they first go through the general problem that they have, and > then go down into more specific detail with every level. That seems to me the > most natural. I just gave an counter-example (i.e. this is not me as a user whom you described). Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
