Brent Worden wrote:
On the discussion of MathUtils, StatUtils and the placement of the average(double, double) method, if the method name was changed to midpoint, would people prefer it be place in MathUtils, StatUtils, or up my keester. Please, limit your replies to two emails.
:-)
Brent Worden http://www.brent.worden.org
I would say, "up your keester"! ;-)
Brent, this is all grounds for establishing the organization of the packages and the overall design process of the project, its all a very excellent discussion. :-) thanks...
I think "midpoint" is somewhat vague too. Ok, maybe we can get a little deeper into this using your case as an example.
(1) What are your requirements/needs for an "average(double, double)" style static method?
(2) What are your (or others) needs for this to be present outside your class (or even static)? Are there others who need this method too?
[my thought]: If its strictly just for (d1 + d2) / 2.0, I doubt you would want the cost of instantiating an entire Univariate implementation behind it. Especially when its called from within an iteration of some recursive convergence algorithm. Which brings us to the following.
(3) We have a couple cases tangled together here.
(a) the case of providing static functionality to (non-static) implementations of our algorithms.
(b) the case of providing static utilities to commonly used simple math functions (factorial, sign, etc).
Simply put, just because we wrote a powerful descriptive stats class, doesn't make it the most appropriate solution to put behind a static interface for something as simplified as (d1 + d2) / 2.0. Its like shooting a rabbit with a cannon, cannons are more expensive, take up more space and harder to move around than shotguns.
I think it would be wise to separate the static methods using above two concepts when placing methods/functionality into the static interfaces. I think it would also be wise if we had some "protocol" for the election of a method into the MathUtils interface. Warranted, this may be a bit anal, but wouldn't it be wise to outline the appropriate requirements for when an method is added to MathUtils? This way it doesn't turn into "thrift store" of methods, some of which shouldn't have been there, some which never get used more than once.
All, very interesting discussion. Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
