Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <3EE71C35.9040708@latte.harvard.edu>
Date: Wed, 11 Jun 2003 08:10:29 -0400
From: "Mark R. Diggory" <mdiggory@latte.harvard.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [math] Static Utils and Methods
References: <PPEMJFOCJCBOOEPAJELCMEAFCBAA.brent@worden.org>
In-Reply-To: <PPEMJFOCJCBOOEPAJELCMEAFCBAA.brent@worden.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org