On Thu, Jan 27, 2011 at 9:42 AM, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > On Thu, Jan 27, 2011 at 08:13:32AM -0500, Phil Steitz wrote: >> On Thu, Jan 27, 2011 at 5:48 AM, Gilles Sadowski >> <gil...@harfang.homelinux.org> wrote: >> >> What functions are you talking about? >> > >> > http://en.wikipedia.org/wiki/Generalised_logistic_function >> > http://en.wikipedia.org/wiki/Step_function >> > http://en.wikipedia.org/wiki/Gaussian_function >> > ... >> > >> OK. The third one may be pretty much already available via Erf in the >> special package, but I am OK adding it explicitly. >> >> What might make sense is to define a new top-level package, "function" >> or "functions" and make "special" a subpackage of that and either >> classify the new ones in some way or put them in a subpackage called >> something like "common". I don't think the ones you have above belong >> in special; but like those in special today, they may end up having >> wide use across other packages, hence the placement in a top-level >> functions package. > > I think that it would be a bit unnatural that the "function" package is > at the top-level because it contains classes that implement > "UnivariateRealFunction" or "BivariateRealFunction", and those are defined > in "analysis". Or maybe you want to move the interface definitions to the > "function" package?
I see your point. Could be it makes sense to move the interfaces, but your observation below on special functions makes me think that may not be best. > Although the functions in "special" are also functions, the implementations > have nothing in common, e.g. those in "special" do not refer to the > interfaces defined in "analysis". Another good point. I am not sure it is best to force fit in this case, though, because there are parameters and variants (regularlized gamma, etc) to consider and I think that code using the current special implementations is clearer than it would be if we force fit an abstract interface on top. > Of course, if you mean that we should refactor the classes in package > "special"... It would imply to have one function object for each of the > static functions currently defined in the classes of the package "special". > Yeah, seems unnecessary to me. > I could open an issue so that we further discuss the options after 2.2 > is released. Please do open an issue describing the new functions, why we need them, etc. and we can talk about where to put them. I am also open to talking about refactoring the special functions, but find them pretty convenient and straightforward to use as they are now. Phil > > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
