You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2003/06/10 23:26:19 UTC
[math] Static Utils and Methods (was: Re: [math] proposed ordering
for task list, scope of initial release)
Al Chou wrote:
> --- Phil Steitz <ph...@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
Re: [math] Static Utils and Methods
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] Static Utils and Methods
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: Mark R. Diggory [mailto:mdiggory@latte.harvard.edu]
>
> Brent Worden wrote:
> > On the discussion of MathUtils, StatUtils and the placement of the
> > average(double, double) method, if the method name was changed
> to midpoint,
> > would people prefer it be place in MathUtils, StatUtils, or up
> my keester.
> > Please, limit your replies to two emails.
> >
> > :-)
> >
> > Brent Worden
> > http://www.brent.worden.org
>
> I would say, "up your keester"! ;-)
>
> Brent, this is all grounds for establishing the organization of the
> packages and the overall design process of the project, its all a very
> excellent discussion. :-) thanks...
>
> I think "midpoint" is somewhat vague too. Ok, maybe we can get a little
> deeper into this using your case as an example.
>
> (1) What are your requirements/needs for an "average(double, double)"
> style static method?
This is more of "looking to the future" need than anything else. If we want
to incorporate non-parametric inference to the library, the average of two
numbers is needed a lot.
>
> (2) What are your (or others) needs for this to be present outside your
> class (or even static)? Are there others who need this method too?
I think only bisection would use it as of now.
>
> [my thought]: If its strictly just for (d1 + d2) / 2.0, I doubt you
> would want the cost of instantiating an entire Univariate implementation
> behind it. Especially when its called from within an iteration of some
> recursive convergence algorithm. Which brings us to the following.
I envisioned it solely as a simple, one-line, utility method.
>
> (3) We have a couple cases tangled together here.
>
> (a) the case of providing static functionality to (non-static)
> implementations of our algorithms.
>
> (b) the case of providing static utilities to commonly used simple math
> functions (factorial, sign, etc).
(b) is what I see XXXUtils being.
>
> Simply put, just because we wrote a powerful descriptive stats class,
> doesn't make it the most appropriate solution to put behind a static
> interface for something as simplified as (d1 + d2) / 2.0. Its like
> shooting a rabbit with a cannon, cannons are more expensive, take up
> more space and harder to move around than shotguns.
>
> I think it would be wise to separate the static methods using above two
> concepts when placing methods/functionality into the static interfaces.
> I think it would also be wise if we had some "protocol" for the election
> of a method into the MathUtils interface. Warranted, this may be a bit
> anal, but wouldn't it be wise to outline the appropriate requirements
> for when an method is added to MathUtils? This way it doesn't turn into
> "thrift store" of methods, some of which shouldn't have been there, some
> which never get used more than once.
Fine by me. This makes sense to me.
Brent Worden
http://www.brent.worden.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Static Utils and Methods
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Brent Worden wrote:
> On the discussion of MathUtils, StatUtils and the placement of the
> average(double, double) method, if the method name was changed to midpoint,
> would people prefer it be place in MathUtils, StatUtils, or up my keester.
> Please, limit your replies to two emails.
>
> :-)
>
> Brent Worden
> http://www.brent.worden.org
I would say, "up your keester"! ;-)
Brent, this is all grounds for establishing the organization of the
packages and the overall design process of the project, its all a very
excellent discussion. :-) thanks...
I think "midpoint" is somewhat vague too. Ok, maybe we can get a little
deeper into this using your case as an example.
(1) What are your requirements/needs for an "average(double, double)"
style static method?
(2) What are your (or others) needs for this to be present outside your
class (or even static)? Are there others who need this method too?
[my thought]: If its strictly just for (d1 + d2) / 2.0, I doubt you
would want the cost of instantiating an entire Univariate implementation
behind it. Especially when its called from within an iteration of some
recursive convergence algorithm. Which brings us to the following.
(3) We have a couple cases tangled together here.
(a) the case of providing static functionality to (non-static)
implementations of our algorithms.
(b) the case of providing static utilities to commonly used simple math
functions (factorial, sign, etc).
Simply put, just because we wrote a powerful descriptive stats class,
doesn't make it the most appropriate solution to put behind a static
interface for something as simplified as (d1 + d2) / 2.0. Its like
shooting a rabbit with a cannon, cannons are more expensive, take up
more space and harder to move around than shotguns.
I think it would be wise to separate the static methods using above two
concepts when placing methods/functionality into the static interfaces.
I think it would also be wise if we had some "protocol" for the election
of a method into the MathUtils interface. Warranted, this may be a bit
anal, but wouldn't it be wise to outline the appropriate requirements
for when an method is added to MathUtils? This way it doesn't turn into
"thrift store" of methods, some of which shouldn't have been there, some
which never get used more than once.
All, very interesting discussion.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)
Posted by Brent Worden <br...@worden.org>.
> > Again, I can see someone wanting these functions if one wants to be
> > absolutely sure that they are complying with strict conceptual
> > definitions in a very large system. I don't personally have a need for
> > isPositive, but that isn't to say that Al hasn't found a good reason to
> > use them in the past.
> >
> > Al? what was the motivation here?
>
> Wasn't my idea in the first place, I think it was Brent's.
Yes, it was my idea and considering all the flak it has taken, it's
apparently a poor one. My intent was to provide a means to make boolean
expression less symbolic and more verbose to the end of making them more
humanly readable. If people don't see the need for it, so be it. Let's
move on.
On the discussion of MathUtils, StatUtils and the placement of the
average(double, double) method, if the method name was changed to midpoint,
would people prefer it be place in MathUtils, StatUtils, or up my keester.
Please, limit your replies to two emails.
:-)
Brent Worden
http://www.brent.worden.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)
Posted by Al Chou <ho...@yahoo.com>.
--- "O'brien, Tim" <to...@transolutions.net> wrote:
> On Tue, 2003-06-10 at 16:26, Mark R. Diggory wrote:
> > [-1]
> >
> > Um, I'm not too clear on this one, how is calling
> > MathUtils.isPositive(d) clearer than (d >= 0)?
>
> [+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.
>
> 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 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 needed a function that returned a number so I could multiply by it.
> > 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.
>
> Again, I can see someone wanting these functions if one wants to be
> absolutely sure that they are complying with strict conceptual
> definitions in a very large system. I don't personally have a need for
> isPositive, but that isn't to say that Al hasn't found a good reason to
> use them in the past.
>
> Al? what was the motivation here?
Wasn't my idea in the first place, I think it was Brent's.
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Static Utils and Methods (was: Re: [math] proposed
ordering for task list, scope of initial release)
Posted by "O'brien, Tim" <to...@transolutions.net>.
On Tue, 2003-06-10 at 16:26, Mark R. Diggory wrote:
> [-1]
>
> Um, I'm not too clear on this one, how is calling
> MathUtils.isPositive(d) clearer than (d >= 0)?
[+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.
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 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?
> 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.
Again, I can see someone wanting these functions if one wants to be
absolutely sure that they are complying with strict conceptual
definitions in a very large system. I don't personally have a need for
isPositive, but that isn't to say that Al hasn't found a good reason to
use them in the past.
Al? what was the motivation here?
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)
Posted by Al Chou <ho...@yahoo.com>.
--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> 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 also want to point out that it's syntactically a little nicer to write
a * sign(b) * c
than
a * ( b > 0 ? 1.0 : -1.0 ) * c
> 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.
That's an interesting point. I wasn't super-keen on isPositive/isNegative, and
I confess I was tempted by the opportunity to reuse sign(). I'll hold off
further development for now.
> >> 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.
Interesting point as well. Not having encountered Java code that does this
kind of double-exposure of functionality, I'm not sure how I feel about it. In
Ruby it doesn't seem to be a problem, but then I haven't worked on large
projects in that language, so again I may not have the experience to back up
any opinions. I have seen this kind of dual interface in Perl modules (e.g.,
in CGI.pm), and there it seems to serve a useful purpose in providing syntactic
flexibility, although admittedly the performance of the static/procedural vs.
OO interfaces is disclaimed not to be identical.
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)
Posted by Phil Steitz <ph...@steitz.com>.
Mark R. Diggory wrote:
>
>
> Phil Steitz wrote:
>
>> --- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
>>
>>
>> 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).
We need it now, to improve the computations in UnivariateImpl for the
finite window case. I guess I am going to have to do this, since no one
else seems interested.
>
> 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.
>
MathUtils (or StatUtils) provides a low overhead, natural place to
encapsulate the core computation, similar to java.Math. To have the
UnivariateImpls delegate like this is not a good design, IMHO. Think
about what that would require in terms of instantiation, dependencies,
etc. It is a *much better* idea to encapsulate the common (very basic,
btw) functionality, especially given that it is generically useful. We
will run in to *lots* of scenarios where we want to sum an array or find
the min of an array. It is silly to force all of these things to depend
on and force instantiation of Univariates.
>>
>>
>>> 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.
>
That is backwards an inefficient, IMHO. That would defeat the main
purpose, which is to provide lighteweight, efficient, cleanly
encapsulated computational methods that the stat (and other) objects can
use.
>> 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).
The point is to provide the users with a choice. For some things, a
Univariate is natural, for simple computations on arrays, it is overkill
, IMHO. For some situations, the BeanListUnivariate is natural. There
is no reason to limit things artifically or to resort to unnatural and
inefficient implementation strategies when it is easy to expose the
functionality. Suppose that Math did not support sqrt(). Would we add
this to some Univariate implementation and build spaghetti dependencies
on that? I don't think so. This kind of thing fits naturally in a
MathUtils class. Similarly, the simple computational function sum:
double[] |-> double belongs naturally in a StatUtils class. Have a look
at the *Utils classes in lang. These are among the most useful things in
the package.
Phil
>
> Cheers,
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Static Utils and Methods (was: Re: [math] proposed ordering
for task list, scope of initial release)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Phil Steitz wrote:
> --- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
>
>>
>>Al Chou wrote:
>>
>>>--- Phil Steitz <ph...@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.
>
>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)
Posted by Phil Steitz <st...@yahoo.com>.
--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
>
>
> Al Chou wrote:
> > --- Phil Steitz <ph...@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.
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.
>
> >> 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.
> 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.
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.
>
> -Mark
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org