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 [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)
Date Tue, 10 Jun 2003 21:26:19 GMT


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.

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

-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