On 11/5/11 7:22 AM, Sébastien Brisard wrote: >> So the user would first configure the solver and then provide it fully >> configured to the abstract distribution ? >> >> If this is what you propose, then I agree. >> >> Luc >> > Yes, that's exactly what I had in mind.
We are talking about two different things here - 0) configuring the solver and 1) reading its properties (in the present case, as part of internal implementation). Regarding configuration, the current setup where distribution constructors have optional inverse cum absolute accuracy arguments is good and should not be changed, IMO. Users may have no idea what solver to use, but a good idea how accurate they want their inverse cum results to be, so we should keep that config option. Allowing a fully configured solver to be passed in may be overkill, but if we want to add a protected constructor in the abstract base class and add implementations to all of the distributions to support it, I am OK with that. Just don't drop the current simple constructors that either just accept defaults fully or allow the absolute accuracy to be passed in as a double. Regarding read access to the properties of the solver, another option is to just add a protected getSolver and be done with it. Alternatively, getFunctionValueAbsoluteAccuracy could be exposed either protected or public. The getter for absolute accuracy in the distribution context really mirrors the optional constructor argument above. I guess my recommendation is to solve the problem we actually have with the simplest change, which is probably just a protected accessor for the solver. Phil > > Sébastien > > > --------------------------------------------------------------------- > 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
