Re: [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)

["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

["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

[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

["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)

[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)

[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