commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <stei...@yahoo.com>
Subject Re: [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)
Date Tue, 10 Jun 2003 22:06:18 GMT

--- "Mark R. Diggory" <mdiggory@latte.harvard.edu> wrote:
> 
> 
> Al Chou wrote:
> > --- Phil Steitz <phil@steitz.com> wrote:
> > 
> >>>>>>
> 
> >Simple methods like isPositive, isNegative, etc. can be used to make
> >boolean expressions more human readable. I'm willing to build those two 
> >on top of sign (I'm so generous with my
> >coding time, eh? <g>).  Are those two sufficient?  sign treats 0 as
> positive,
> >which may not be desirable.
> 
> >>>>+1 (especially the part about your time :-)
> >>>
> >>>
> >>>OK, I'll TDD those up, hopefully resolving the question of what to do
> about the sign of 0 in the process.
> >>
> >>
> >>Forgot to weigh in on this.  I would say that 0 is neither positive nor 
> >>negative.  If that is not a happy state, I would prefer to call 
> >>isPositive, "isNonNegative".  I know that is ugly, I have a hard time 
> >>calling 0 a positive number.  So, my first should would be isPositive 
> >>and isNegative both fail for zero, second would be to rename as above.
> > 
> > 
> > I tend to agree with you, except for the usage that I wrote sign() for in
> the
> > first place.  Granted, that may be an unusual usage, so I'll keep your
> remarks
> > in mind while I TDD.  Also, I just realized that I won't be submitting the
> > Ridders' method code for the initial release anyway (at least as far as I
> > know), so maybe sign() needs to change, given that it has no users that
> require
> > the current behavior.
> > 
> > 
> > Al
> 
> 
> [-1]
> 
> Um, I'm not too clear on this one, how is calling 
> MathUtils.isPositive(d) clearer than (d >= 0)?
> 
> I think the argument over implementation above is a clear enough reason 
> as to why something like this shouldn't be created. There is a standard 
> logic to evaluations in java that is elegant and mathematical in nature. 
> I'd fear we would just be reinventing the wheel here.
> 
> I included Al's functions because they were a little more complex than 
> that, they provided different return type when dealing with different 
> evaluations. Of course these could be captured inline quite easily as 
> well with examples like:
> 
> d >= 0 ? 1d : -1d
> d > 0 ? 1d : -1d
> ...
> 
> So again, I'm not sure how strong a benefit they provide in the long 
> run. I personally would probably exclude them on the basis that they are 
> overly simplified in comparison to what is already in MathUtils 
> (factorial and binomialCoefficient). It seems we should stick to 
> functionality that "extends" Math capabilities and not create a the new 
> wheel of alternative math functionality already present in java, the 
> sign() methods borderline this case of functionality and
> 
> boolean isPositive(double d)
> 
> definitely reinvents the wheel in a very big way. I think in general its 
> best to keep static functions in MathUtil's that simplify complex 
> calculations like factorials.

Simple things are also good.  I like sign or sgn.  This is basic and missing
from java.  You have a good point, however re isPositive(), isNegative().  It's
really a matter of taste, what makes more readable code.

> 
> >> Would it be considered poor form to provide these methods in MathUtils 
> >> but have
> >> them delegate to the stat subtree of the class hierarchy.  That way 
> >> all the
> >> actual code would be in one place, but we wouldn't force users to know 
> >> that
> >> they're doing a statistical calculation when they just want average(x, 
> >> y).
> >>
> >>
> > I actually was thinking the other way around.  If you feel strongly 
> > about keeping these things in stat, we can create StatUtils.  The point 
> > is to encapsulate these basic functions so that a) users can get them 
> > immediately without thinking about our stat abstractions and b) we can 
> > get the storage-based computations of the basic quantities in one place. 
> >  When the UnivariateImpl window is finite, it should use the same 
> > computations that AbstractStoreUnivariate does -- this is why we need to 
> > encapsulate.
> 
> I feel the need to wave a caution flag here. Using MathUtils as a ground 
> for exposing quick access to "default" functions is an interesting idea. 
>   But I think it creates an Interface situation that over-complicates 
> the library, having multiple ways to do something tends to create 
> confusion. I would recommend we focus more for solidifying the 
> implementations and then consider simple static access to certain 
> functionality in the future after we have solid implementations in 
> place. And, I also suggest we base this on user response/need and not on 
> our initial expectations, if users like it and want it, we can add it.
> 

I disagree. We need it ourselves, unless we want to duplicate code between
UnivariateImpl and AbstractStoreUnivariate.  Also, I personally and I am sure
many other users would like simple array-based functions for means, sums, etc.
If I have an array of doubles and I all I want to is compute its mean, I would
like to be able to do that directly, rather than having to instantiate a stat
object.


> I say this because I believe other developers will become confused as to 
> whether to use the static or OO (Object Oriented) way to use the 
> functionality when developing. 

I disagree.  We should provide the flexibility to choose.  Computationally
intensive applications may want to work directly with arrays (as we should
internally), while others will more naturally work with stat objects, or beans.

If we have two different strategies for 
> accessing functionality, then we need to have design rules on how where 
> to use each case in our own development.

I agree.  This is why I proposed adding the static double[] -> double
computational methods -- so the many places where we will need them can all use
common, optimized implementations.


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


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

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


Mime
View raw message