commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)
Date Wed, 11 Jun 2003 00:57:53 GMT


Phil Steitz wrote:
> --- "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.
> 
> 

I have a strong opinion that introducing package specific alternatives 
to the way something is already easily doable in java creates 
complication and confusion for the common java developer. I'm not 
speaking here about your sign function, I'm speaking more specifically 
about isPositive/isNegative. They have to go and learn what these 
functions do, they already know what ">" or ">=" means...

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

If there is a strong motivation for it, then it should go in before 
release. But, I'd really rather have the static functions be static 
delegates for the Implementations, not the other way around. (this 
thought is defended later in this message).

In terms of duplicate code in Univar and StorUnivar, its not obvious to 
me what the static interface of MathUtils or StatUtils has to do with 
this? My feelings are that UnivariateImpl should delegate to 
StoredUnivariateImpl in situations where storage is required.

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

[defense] I agree, and I think in the case of Univariate's (and other 
applications) that it would be best to supply methods for working with 
arrays, you should be able to hand Univar a double[] without having to 
iterate over it and add each value using addValue(...). There should be 
a method or constructor that uses such a double array directly for the 
calculation. Again, this means that MathUtil's is just a static 
delegation point for such methods across different classes, those 
classes have to implement the methods that would get called to support 
such functionality.

I am suggesting "to have" such methods in MathUtil's, but keep the 
implementations in the classes themselves.

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

If I were writing a class that used other implementations in [math], I 
would use the implementations directly as much as possible and avoid 
usage via the static interface. I'd do this simply to support optimized 
object usage over constantly reintantiating the objects that may get 
recreated ever time such a static method is called. (Some others may 
disagree, I'm sure theres lots of room for opinion here).

Cheers,
Mark



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