[math] Limits on StatUtil content was( Re: [math] design patterns .... )

["Mark R. Diggory" <md...@latte.harvard.edu>]

Phil Steitz wrote:

>> I keep reminding myself, we are the developers, there is always room 
>> for refactoring in the future. If there becomes a clear hindrance 
>> with the use of static methods, then we can refactor them into a 
>> class that needs to be instantiated. This is not too difficult to 
>> accomplish.
>>
> Not for us, maybe, but it could be a real pain for the users who have 
> written code using the static methods directly. We also need to keep 
> reminding ourselves that what we are developing is a library for 
> others to use.  Refactoring public interfaces post release is a slow 
> and painful process. Given that MathUtils and StatUtils are going to 
> be public, we need to be committed to supporting the static methods 
> that they will expose.  

Now thats a very strong point,

A cautious side note: Its very difficult to design a product for a 
"hypothetical future user", I've been trying to do this for the last 3 
years, its very very difficult, and I'm constantly "pulling in the 
reigns", to stop overdevelopment that is based on "bad assumptions" 
about what this hypothetical user-base is going to want. The user is, 
infact, part of the Open Source development process. This is where 
philosphies like, "Release early, Release often" become benificial. The 
user input is really needed to help drive the development direction 
properly.

> I am personally OK with this, as long as we limit the scope to 
> relatively trivial computational methods.
>
> Phil


As well another excellent point, Where do we draw the line on the 
content of StatUtils? and what is a non-trivial computational method? If 
as an algorithm can be easily broken down into separate methods, it 
first seems a benefit to have those utility methods easily accessable 
for other alogrithms that may need them. We see this with mean, sum, 
sumq, etc in the statistics lib. However, optimized algorithms often 
combine the calculation of such utility methods to improve performance, 
sum and sumsq can be easily calcuated in one pass (or easily updated in 
a storageless case). In such cases is it a bad decision to promote the 
static usage of such methods, we see it happening in java.lang.Math? It 
is nice to have them as simple generic building blocks, but manyl 
optimal implementions could not directly benefit by using them. Math.pow 
is a standardized IEEE implementation, it is a generic and very stable 
solution but it is not the optimal performance solution in every case. 
Our StatUtils will probibly endup have the same such characteristics. 
Again, this doesn't suggest Static methods are bad, the same situation 
would arise if it were a regular abstract/base class. Its just the case 
that the methods that go into Utils have an appropriate definition of 
applicability that needs to be clearly defined.

-Mark

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] Limits on StatUtil content (was Re: [math] design patterns ...)

[Al Chou <ho...@yahoo.com>]

--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> Phil Steitz wrote:
> >> I keep reminding myself, we are the developers, there is always room 
> >> for refactoring in the future. If there becomes a clear hindrance 
> >> with the use of static methods, then we can refactor them into a 
> >> class that needs to be instantiated. This is not too difficult to 
> >> accomplish.
> >>
> > Not for us, maybe, but it could be a real pain for the users who have 
> > written code using the static methods directly. We also need to keep 
> > reminding ourselves that what we are developing is a library for 
> > others to use.  Refactoring public interfaces post release is a slow 
> > and painful process. Given that MathUtils and StatUtils are going to 
> > be public, we need to be committed to supporting the static methods 
> > that they will expose.  
> 
> Now thats a very strong point,
> 
> A cautious side note: Its very difficult to design a product for a 
> "hypothetical future user", I've been trying to do this for the last 3 
> years, its very very difficult, and I'm constantly "pulling in the 
> reigns", to stop overdevelopment that is based on "bad assumptions" 
> about what this hypothetical user-base is going to want. The user is, 
> infact, part of the Open Source development process. This is where 
> philosphies like, "Release early, Release often" become benificial. The 
> user input is really needed to help drive the development direction 
> properly.

I agree we need real user input to help guide the design, just so long as we
don't let ourselves be completely constrained by what the initial small user
base wants/likes (the way Unix make did when it had 10 users).  I think if we
warn alpha/beta users that public interfaces are subject to change, we may be
OK.


Al

=====
Albert Davidson Chou

    Get answers to Mac questions at http://www.Mac-Mgrs.org/ .

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org