Al Chou wrote:
--- Phil Steitz <[EMAIL PROTECTED]> 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 haveI 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.
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
