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