--- "Mark R. Diggory" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
