commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math] Static Utils and Methods
Date Wed, 11 Jun 2003 00:28:38 GMT

O'brien, Tim wrote:
> [+0], Mark, if I follow the discussion correctly, the concept isn't
> trying to ascertain if a given number is greater than or equal to zero. 
> I believe that the discussion revolved around the mathematical concept
> of "Positive".  Is a given number "positive" is a different question
> from is a given number greater than or equal to zero - depending on your
> specific definition and needs.

And in such a case, are you going to force/promote some particular 
definition of positiveness on the user by writing a bunch of static 
methods that enforce that viewpoint? IMHO, determining if a number is (x 
 >= 0.0) or if its (x > 0.0) is not something anyone should need a 
separate static method in Utils to discover.

> An application that needs to test for a Non-negative numbers, would
> benefit from a isNonNegative method.  Even though, the function simply
> contains d >= 0.  MathUtils.isNonNegative( 3 ) is conceptually different
> from 3 >= 0.  Personally, I would choose, "3 >= 0", but if a programmer
> wished to invoke that operation via MathUtils.isNonNegative to attain a
> sort of conceptual "purity", I don't think this is our decision to make.

I disagree, (1) by adding such functionality, we are promoting the usage 
of such functionality, (2) I will always enforce a viewpoint which 
reduces the amount of "hidden" functionality behind an interface or 
methodology. MathUtils.isNonNegative( x ), creates conceptual ambiguity. 
One has to wonder what does this function mean? How is it implemented? I 
don't think we should condone/promote such usage because it creates 
added work for us to define something that can be clearly captured by 
the user in less than one line of their own java code.

>>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'm not sure why that function would not return a boolean primitive,
> anyone have any good reasons not to?

I applied Al's patch on the basis that it contained returns of specific 
"types" that he was using in his code. I believed Al's code used the 
sign information within his calculations. It benefited him to have it in 
a separate method (I assume he was calling it often). I also believe he 
thought it might be a useful method for others to be able to use. Either 
way it appears to have open up some interesting debate...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message