> -----Original Message----- > From: Mark R. Diggory [mailto:[EMAIL PROTECTED] > > 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?
This is more of "looking to the future" need than anything else. If we want to incorporate non-parametric inference to the library, the average of two numbers is needed a lot. > > (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? I think only bisection would use it as of now. > > [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. I envisioned it solely as a simple, one-line, utility method. > > (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). (b) is what I see XXXUtils being. > > 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. Fine by me. This makes sense to me. Brent Worden http://www.brent.worden.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
