Phil Steitz wrote:
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
