--- "Mark R. Diggory" <mdiggory@latte.harvard.edu> wrote:
> 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
> ...

I also want to point out that it's syntactically a little nicer to write

a * sign(b) * c

than

a * ( b > 0 ? 1.0 : -1.0 ) * c


> 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.

That's an interesting point.  I wasn't super-keen on isPositive/isNegative, and
I confess I was tempted by the opportunity to reuse sign().  I'll hold off
further development for now.


> >> 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 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. 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.

Interesting point as well.  Not having encountered Java code that does this
kind of double-exposure of functionality, I'm not sure how I feel about it.  In
Ruby it doesn't seem to be a problem, but then I haven't worked on large
projects in that language, so again I may not have the experience to back up
any opinions.  I have seen this kind of dual interface in Perl modules (e.g.,
in CGI.pm), and there it seems to serve a useful purpose in providing syntactic
flexibility, although admittedly the performance of the static/procedural vs.
OO interfaces is disclaimed not to be identical.



Al

=====
Albert Davidson Chou

    Get answers to Mac questions at http://www.Mac-Mgrs.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