You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <st...@yahoo.com> on 2003/06/06 19:21:12 UTC
[math] proposed ordering for task list, scope of initial release
Here is a *proposed* ordering for the task list, with a little commentary
added.
One thing that I want to make *very* clear up front, is that I *never* intended
the task list or the items listed in the scope section of the proposal to be
definitive. All that is definitive are the guiding principles, which just try
to keep us focused on stuff that people will find both useful and easy to use.
I expected that the actual contents of the first release would include some
things not on the list and would exclude some of the things there. At this
stage, as Jouzas pointed out, it is more important for us to build community
than to rush a release out the door. So if there are things that fit the
guidelines that others would like to contribute, but which are not on the list,
*please* suggest them. Also, for those who may not have dug into the code, but
who may be interested in contributing, please rest assured that deep
mathematical knowledge is not required to help. We can review implementations
and deal with mathematical problems as they arise, using our small but growing
community as a resource. The same is obviously true on the the Java/OS tools
side -- no need to be an expert to contribute.
OK, long-winded disclaimer aside, here is how I see the task list ordered:
* The RealMatrixImpl class is missing some key method implementations. The
critical thing is solution of linear systems. We need to implement a
numerically sound solution algorithm. This will enable inverse() and also
support general linear regression. -- I think that Brent is working on this.
* Improve numerical accuracy of Univariate and BivariateRegression statistical
computations. Encapsulate basic double[] |-> double mean, variance, min, max
computations using improved formulas and add these to MathUtils. (probably
should add float[], int[], long[] versions as well.) Then refactor all
univariate implementations that use stored values (including UnivariateImpl
with finite window) to use the improved versions. -- Mark? I am chasing down
the TAS reference to document the source of the _NR_ formula, which I will add
to the docs if someone else does the implementation.
* Define full package structure and develop user's guide following the package
structure. I have started work on the user's guide, but found this impossible
without the package structure defined. I will post a separate message
summarizing what has been proposed up to now and making a recommendation.
* t-test statistic needs to be added and we should probably add the capability
of actually performing t- and chi-square tests at fixed significance levels
(.1, .05, .01, .001). -- This is virtually done, just need to define a nice,
convenient interface for doing one- and two-tailed tests. Thanks to Brent, we
can actually support user-supplied significance levels (next item)
* numerical approximation of the t- and chi-square distributions to enable
user-supplied significance levels. See above. Someone just needs to put a
fork in this. Tim? Brent?
* *new* add support for F distribution and F test, so that we can report
signinficance level of correlation coefficient in bivariate regression /
signinficance of model. I will do this if no one else wants to.
* Framework and implementation strategie(s) for finding roots or real-valued
functions of one (real) variable. Here again -- largely done. I would prefer
to wait until J gets back and let him submit his framework and R. Brent's
algorithm. Then "our" Brent's implementation and usage can be integrated
(actually not much to do, from the looks of the current code) and I will add my
"bean equations" stuff (in progress).
* Extend distribution framework to support discrete distributions and implement
binomial and hypergeometric distributions. I will do this if no one else wants
to. If someone else does it, you should make sure to use the log binomials in
computations.
* Exponential growth and decay (set up for financial applications) I think this
is just going to be a matter of finding the right formulas to add to MathUtils.
I don't want to get carried away with financial computations, but some simple,
commonly used formulas would be a nice addition to the package. We should also
be thinking about other things to add to MathUtils -- religiously adhering to
th guiding principles, of course. Al's sign() is an excellent example of the
kind of thing that we should be adding, IMHO.
* Polynomial Interpolation -- let Al tell us what to do here. Even better, let
Al do it (he he).
* Javadoc generation currently throws 35 warnings. Bring the Javadoc into
compliance (i.e. reach zero warnings). A community effort :-)
* Clover tests show lots of gaps in test path coverage. Get all tests to 100%
coverage
* CheckStyle with modified properties still shows many errors. Clean these up.
* ComplexNumber implementation, supporting C9x Annex G spec. I would prefer to
wait on this, but I could be persuaded to finish my implementation (or better,
include someone else's fully compliant implementation) if others feel strongly.
* Addition of a Arithmetic Geometric Mean. I would wait in this as well.
---------------------------------------------
My proposal for the first release is that we
1) complete the tasks above, other than the last two
2) step back and take a critical look at the design decisions that we have made
up to now and consider refactoring some things (Univariate world, RealMatrix,
and TestStatistic, esp.) Also obviously finalize package structure. This task
obviously needs to run concurrently with the ones above.
3) develop the user's guide and validate all algorithms and documentation.
4) do some performance testing and as much numerical stability validation as we
can.
5) follow the Jakarta sandbox process for alpha release
Phil
__________________________________
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: Update: [math] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <st...@yahoo.com>.
--- Al Chou <ho...@yahoo.com> wrote:
> --- Phil Steitz <ph...@steitz.com> wrote:
> > Here is an updated version. I will try to submit a patch to the
> > task.xml reflecting this before I leave this AM, but I am running out of
> > time...
>
> > > * Improve numerical accuracy of Univariate and BivariateRegression
> > statistical
> > > computations. Encapsulate basic double[] |-> double mean, variance, min,
> > max
> > > computations using improved formulas and add these to MathUtils.
> (probably
> > > should add float[], int[], long[] versions as well.) Then refactor all
> > > univariate implementations that use stored values (including
> UnivariateImpl
> > > with finite window) to use the improved versions. -- Mark? I am chasing
> > down
> > > the TAS reference to document the source of the _NR_ formula (done),
> which
> > I will add
> > > to the docs if someone else does the implementation
> >
> > Al submitted a patch covering part of this last night.
>
> Note that I didn't do anything in the finite-window part of
> UnivariateImpl.insertValue(), because I didn't know how. I just realized we
> may just be able to use the "weight = -1" case described in Hanson and Chan &
> Lewis. I'll read them more carefully to see if that's correct.
>
> Also, the corrected two-pass algorithm still needs to be put into
> StoreUnivariateImpl, right?
>
Yes, if we think it will make a difference. Chan's paper suggests that the
standard two-pass algorithm, which we have in the AbstractStoreUnivariate now,
is just about as good. There is no need to mess with the insertvalue stuff, we
just need to make sure that when the actual statistics are reported in the
finite window case, the best "stored" computations are performed directly on
the stored vector. This is one reason that I wanted to encapsulate these
vector computations into StatUtils.
>
> > > * Framework and implementation strategie(s) for finding roots or
> > real-valued
> > > functions of one (real) variable. Here again -- largely done. I would
> > prefer
> > > to wait until J gets back and let him submit his framework and R. Brent's
> > > algorithm. Then "our" Brent's implementation and usage can be integrated
> > > (actually not much to do, from the looks of the current code)
> >
> > Need to make a decision here. I suggest that Brent makes the
> > improvements that he has in mind to J's framework, puts into the new
> > package (earlier post) and refactors existing stuff.
>
> Sounds reasonable (or do I say "+1"?). I think we need _something_ submitted
> in the way of root finding framework so we can give feedback.
>
>
> > > * Polynomial Interpolation -- let Al tell us what to do here. Even
> better,
> > let
> > > Al do it (he he).
> > Use rational functions, per Al's suggestions. Maybe implement natural
> > spline instead. Al? Anyone?
>
> I need to find a non-NR reference to the Stoer and Bulirsch algorithm for
> rational function interpolation (I don't own a copy of their book), otherwise
> I'll just be relying on NR's description.
>
> I don't have an objection to providing cubic splines, though we should be
> aware
> that they open the door to providing a tridiagonal linear system solver.
I was just thinking of them as an alternative approximation solution.
>
>
>
> Al
>
> =====
> Albert Davidson Chou
>
> Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Update: [math] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> Here is an updated version. I will try to submit a patch to the
> task.xml reflecting this before I leave this AM, but I am running out of
> time...
> > * Improve numerical accuracy of Univariate and BivariateRegression
> statistical
> > computations. Encapsulate basic double[] |-> double mean, variance, min,
> max
> > computations using improved formulas and add these to MathUtils. (probably
> > should add float[], int[], long[] versions as well.) Then refactor all
> > univariate implementations that use stored values (including UnivariateImpl
> > with finite window) to use the improved versions. -- Mark? I am chasing
> down
> > the TAS reference to document the source of the _NR_ formula (done), which
> I will add
> > to the docs if someone else does the implementation
>
> Al submitted a patch covering part of this last night.
Note that I didn't do anything in the finite-window part of
UnivariateImpl.insertValue(), because I didn't know how. I just realized we
may just be able to use the "weight = -1" case described in Hanson and Chan &
Lewis. I'll read them more carefully to see if that's correct.
Also, the corrected two-pass algorithm still needs to be put into
StoreUnivariateImpl, right?
> > * Framework and implementation strategie(s) for finding roots or
> real-valued
> > functions of one (real) variable. Here again -- largely done. I would
> prefer
> > to wait until J gets back and let him submit his framework and R. Brent's
> > algorithm. Then "our" Brent's implementation and usage can be integrated
> > (actually not much to do, from the looks of the current code)
>
> Need to make a decision here. I suggest that Brent makes the
> improvements that he has in mind to J's framework, puts into the new
> package (earlier post) and refactors existing stuff.
Sounds reasonable (or do I say "+1"?). I think we need _something_ submitted
in the way of root finding framework so we can give feedback.
> > * Polynomial Interpolation -- let Al tell us what to do here. Even better,
> let
> > Al do it (he he).
> Use rational functions, per Al's suggestions. Maybe implement natural
> spline instead. Al? Anyone?
I need to find a non-NR reference to the Stoer and Bulirsch algorithm for
rational function interpolation (I don't own a copy of their book), otherwise
I'll just be relying on NR's description.
I don't have an objection to providing cubic splines, though we should be aware
that they open the door to providing a tridiagonal linear system solver.
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Update: [math] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Here is an updated version. I will try to submit a patch to the
task.xml reflecting this before I leave this AM, but I am running out of
time...
>
> * The RealMatrixImpl class is missing some key method implementations. The
> critical thing is solution of linear systems. We need to implement a
> numerically sound solution algorithm. This will enable inverse() and also
> support general linear regression.
Patch submitted last night
>
> * Improve numerical accuracy of Univariate and BivariateRegression statistical
> computations. Encapsulate basic double[] |-> double mean, variance, min, max
> computations using improved formulas and add these to MathUtils. (probably
> should add float[], int[], long[] versions as well.) Then refactor all
> univariate implementations that use stored values (including UnivariateImpl
> with finite window) to use the improved versions. -- Mark? I am chasing down
> the TAS reference to document the source of the _NR_ formula (done), which I will add
> to the docs if someone else does the implementation
Al submitted a patch covering part of this last night.
>
> * Define full package structure and develop user's guide following the package
> structure. I have started work on the user's guide, but found this impossible
> without the package structure defined. I will post a separate message
> summarizing what has been proposed up to now and making a recommendation.
See previous post this AM.
>
> * t-test statistic needs to be added and we should probably add the capability
> of actually performing t- and chi-square tests at fixed significance levels
> (.1, .05, .01, .001). -- This is virtually done, just need to define a nice,
> convenient interface for doing one- and two-tailed tests. Thanks to Brent, we
> can actually support user-supplied significance levels (next item)
>
> * numerical approximation of the t- and chi-square distributions to enable
> user-supplied significance levels. See above. Someone just needs to put a
> fork in this. Tim? Brent?
I posted a simple suggestion for this. Still needs to be done.
>
> * *new* add support for F distribution and F test, so that we can report
> signinficance level of correlation coefficient in bivariate regression /
> signinficance of model. I will do this if no one else wants to.
Done. Thanks, Brent.
>
> * Framework and implementation strategie(s) for finding roots or real-valued
> functions of one (real) variable. Here again -- largely done. I would prefer
> to wait until J gets back and let him submit his framework and R. Brent's
> algorithm. Then "our" Brent's implementation and usage can be integrated
> (actually not much to do, from the looks of the current code)
Need to make a decision here. I suggest that Brent makes the
improvements that he has in mind to J's framework, puts into the new
package (earlier post) and refactors existing stuff.
I will add my
> "bean equations" stuff (in progress). <-- still working on this, could drop
from initial release if not complete "soon"
>
> * Extend distribution framework to support discrete distributions and implement
> binomial and hypergeometric distributions. I will do this if no one else wants
> to. If someone else does it, you should make sure to use the log binomials in
> computations.
I am working on this now.
>
> * Exponential growth and decay (set up for financial applications) I think this
> is just going to be a matter of finding the right formulas to add to MathUtils.
> I don't want to get carried away with financial computations, but some simple,
> commonly used formulas would be a nice addition to the package.
Descoped for initial release. Could add as a separate dist per Tim's
suggestions.
We should also
> be thinking about other things to add to MathUtils -- religiously adhering to
> th guiding principles, of course. Al's sign() is an excellent example of the
> kind of thing that we should be adding, IMHO.
>
> * Polynomial Interpolation -- let Al tell us what to do here. Even better, let
> Al do it (he he).
Use rational functions, per Al's suggestions. Maybe implement natural
spline instead. Al? Anyone?
>
> * Javadoc generation currently throws 35 warnings. Bring the Javadoc into
> compliance (i.e. reach zero warnings). A community effort :-)
>
> * Clover tests show lots of gaps in test path coverage. Get all tests to 100%
> coverage
>
> * CheckStyle with modified properties still shows many errors. Clean these up.
>
> * ComplexNumber implementation, supporting C9x Annex G spec. I would prefer to
> wait on this, but I could be persuaded to finish my implementation (or better,
> include someone else's fully compliant implementation) if others feel strongly.
Descoped for initial release.
>
> * Addition of a Arithmetic Geometric Mean.
Descoped for initial release.
> ---------------------------------------------
>
> My proposal for the first release is that we
>
> 1) complete the tasks above, other than the last two
>
> 2) step back and take a critical look at the design decisions that we have made
> up to now and consider refactoring some things (Univariate world, RealMatrix,
> and TestStatistic, esp.) Also obviously finalize package structure. This task
> obviously needs to run concurrently with the ones above.
>
> 3) develop the user's guide and validate all algorithms and documentation.
>
> 4) do some performance testing and as much numerical stability validation as we
> can.
4.5) carefully review implementations for stability and correctness
>
> 5) follow the Jakarta sandbox process for alpha release
I think that we are getting close. As long as others are comfortable
with the initial release scope, there is not that much left to
implement. The one significant missing piece is interpolation. Most of
the remaining work is review and documentation.
I have started on the user's guide and am waiting for concurrence on
package structure to start submitting this.
>
> Phil
>
>
>
>
>
>
> __________________________________
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Phil Steitz wrote:
> That's where I started, but then Tim and others convinced me that it was
> actually better/more convenient for users for us to behave more like
> java.Math and java's own arithmetic functions -- which use NaN all over
> the place.
Uh, oh. That's probably because of IEEE 854 does so. Returning
NaNs as well as throwing RuntimeExceptions is appropriate if
checking for problems would unnecessarily clutter the whole
program code, in particular if the exceptional conditions can
potentially occure often in a small amount of source code while
in reality occuring rerely. I mean, You certainly don't want to
declare an ArrayOutOfBoundsException just because you want to
make an array access, in particular if the index has already
been checked elswhere for other reasons.
Keep also in mind that NaNs had been invended before high level
languages generally aquired reasonable mechanisms for handling
exceptions, and that this means the hardware is designed to deal
with NaNs rather than throwing exceptions. Java probably adopted
NaNs mainly because checking every FP operation for a NaN would
have been an utter performance killer.
The question is: can the user be expected to provide more often
valid input to commons-math methods than not? If so, will checking
for a math exception clutter the user's routines too much?
> Also, from a usage standpoint, if we use checked exceptions
> everywhere, this is a bit inconvenient for users. We need to find the
> right balance.
Exactly.
It is, however, common for libraries to use checked exceptions.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] NaN vs. Exception Revisited
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Tim O'Brien wrote:
>>I think your usage of Convergence Exception is appropriate in your case.
>>In your case your waiting for the method to return, if it fails to
>>converge, you need to know why, there may be different reasons, and its
>>an "exceptional case" which probibly terminates the whole process in the
>>long run.
>>
>>
>
>+1, a ConvergenceException makes sense.
>
>
>
>>try{
>> MathUtils.factorial( Math.floor( Math.log(
>> StatUtils.geomean(someobj.getArray()) )))
>>
>>}catch(InvalidInputValueException iive){
>> iive.printStackTrace(...);
>>}
>>
>>
>
>-1, not only is that a very bad idea in terms of usage constraints, it
>tends to buck a well established trend. Complex "algorithms" should
>through checked exception, something like finding an Average of a set of
>values should return NaN.
>
>
>
Just testing the conceptual waters, if we still feel as strongly about
it, very well...
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] NaN vs. Exception Revisited (was: Re: [math] proposed
ordering for task list, scope of initial release)
Posted by Tim O'Brien <to...@discursive.com>.
> I think your usage of Convergence Exception is appropriate in your case.
> In your case your waiting for the method to return, if it fails to
> converge, you need to know why, there may be different reasons, and its
> an "exceptional case" which probibly terminates the whole process in the
> long run.
+1, a ConvergenceException makes sense.
> try{
> MathUtils.factorial( Math.floor( Math.log(
> StatUtils.geomean(someobj.getArray()) )))
>
> }catch(InvalidInputValueException iive){
> iive.printStackTrace(...);
> }
-1, not only is that a very bad idea in terms of usage constraints, it
tends to buck a well established trend. Complex "algorithms" should
through checked exception, something like finding an Average of a set of
values should return NaN.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[math] NaN vs. Exception Revisited (was: Re: [math] proposed ordering
for task list, scope of initial release)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Brent Worden wrote:
>>-----Original Message-----
>>From: Phil Steitz [mailto:phil@steitz.com]
>>
>>>>There are several approaches to design a concept for exceptions,
>>>>all of which have pros and cons. I personally would suggest to
>>>>avoid returning NaNs and throwing RuntimeExceptions whereever
>>>>possible and use a package specific hierarchy of declared exceptions
>>>>instead.
>>>>
>>>>J.Pietschmann
>>>
>>>
>>>I would agree whole-heartedly.
>>>
>>
>>That's where I started, but then Tim and others convinced me that it was
>>actually better/more convenient for users for us to behave more like
>>java.Math and java's own arithmetic functions -- which use NaN all over
>>the place.
>
>
> Here's a saying I've used in the past when debating colleagues: "Just
> because someone else does something, that doesn't make it right." :)
>
> Also, from a usage standpoint, if we use checked exceptions
>
>>everywhere, this is a bit inconvenient for users. We need to find the
>>right balance.
>>
>>I am one the fence on this whole issue. I am interested in hearing more
>>about what others may have in mind.
>
>
> The big problem I have with returning NaN is the caller has little knowledge
> why NaN is being returned. If an exception is thrown, preferably a
> specialized exception like ConvergenceException, the caller knows precisely
> the reason for failure and can take appropriate recovery action.
I think your usage of Convergence Exception is appropriate in your case.
In your case your waiting for the method to return, if it fails to
converge, you need to know why, there may be different reasons, and its
an "exceptional case" which probibly terminates the whole process in the
long run.
But, I also supported the usage of NaN's when the result of a simple
calculation falls outside the domain of "proper results" for that
method. This means that log(0.0) would return a NaN, simple descriptive
stats would return NaN's when the inputs were of the wrong domain.
for example, if geomean() returned a NaN in the following eq. the whole
eq's return value is NaN.
MathUtils.factorial( Math.floor( Math.log(
StatUtils.geomean(someobj.getArray()) )))
BUT, even again, Now that we revisit this issue, we may be wrong (and
your viewpoint correct) in this respect when it comes to ease of use. If
we have a generic "InvalidInputValueException", then only one exception
need be caught in the process of evaluating numerious functions in a
process. If all throw "InvalidInputValueException", its easily
discernable where the problem arose in the calculation.
try{
MathUtils.factorial( Math.floor( Math.log(
StatUtils.geomean(someobj.getArray()) )))
}catch(InvalidInputValueException iive){
iive.printStackTrace(...);
}
Its a question of, is a function returning NaN an exceptional case or is
it an acceptable case? And, this had/has turned into a very debatable topic.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] proposed ordering for task list, scope of initial release
Posted by Tim O'Brien <to...@discursive.com>.
On Wed, 2003-06-11 at 00:15, Brent Worden wrote:
> Here's a saying I've used in the past when debating colleagues: "Just
> because someone else does something, that doesn't make it right." :)
Please see the previous discussions on the issue, use the Eyebrowse
archive to read the relevant IEEE standards, also in the commons math
developers guide see the two PS files conerning floating-point
arithmetic.
For more advanced algorithms a checked exception makes sense, for
something like Min(), Max() returning NaN makes good sense. Please read
the material in question and submit patches accrodingly.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] proposed ordering for task list, scope of initial release
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: Phil Steitz [mailto:phil@steitz.com]
> >>
> >>There are several approaches to design a concept for exceptions,
> >>all of which have pros and cons. I personally would suggest to
> >>avoid returning NaNs and throwing RuntimeExceptions whereever
> >>possible and use a package specific hierarchy of declared exceptions
> >>instead.
> >>
> >>J.Pietschmann
> >
> >
> > I would agree whole-heartedly.
> >
>
> That's where I started, but then Tim and others convinced me that it was
> actually better/more convenient for users for us to behave more like
> java.Math and java's own arithmetic functions -- which use NaN all over
> the place.
Here's a saying I've used in the past when debating colleagues: "Just
because someone else does something, that doesn't make it right." :)
Also, from a usage standpoint, if we use checked exceptions
> everywhere, this is a bit inconvenient for users. We need to find the
> right balance.
>
> I am one the fence on this whole issue. I am interested in hearing more
> about what others may have in mind.
The big problem I have with returning NaN is the caller has little knowledge
why NaN is being returned. If an exception is thrown, preferably a
specialized exception like ConvergenceException, the caller knows precisely
the reason for failure and can take appropriate recovery action.
>
> Phil
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] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Brent Worden wrote:
>
>>-----Original Message-----
>>From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
>>Sent: Tuesday, June 10, 2003 3:04 PM
>>To: Jakarta Commons Developers List
>>Subject: Re: [math] proposed ordering for task list, scope of initial
>>release
>>
>>
>>Phil Steitz wrote:
>>
>>>My philosophy on this is that whatever exceptions we define should be
>>>"close" to the components that throw them -- e.g. ConvergenceException.
>>> I do not like the idea of a generic "MathException." As much as
>>>possible, I think that we should rely on the built-ins (including the
>>>extensions recently added to lang). Regarding
>>
>>ConvergenceException, I am
>>
>>>on the fence for inclusion in the initial release, though I see
>>>something like this as eventually inevitable. Correct me if I
>>
>>am wrong,
>>
>>>but the only place that this is used now is in the dist package and we
>>>could either just throw a RuntimeException directly there or
>>
>>return NaN.
>>
>>> I do see the semantic value of ConvergenceException, however.
>>
>>There are several approaches to design a concept for exceptions,
>>all of which have pros and cons. I personally would suggest to
>>avoid returning NaNs and throwing RuntimeExceptions whereever
>>possible and use a package specific hierarchy of declared exceptions
>>instead.
>>
>>J.Pietschmann
>
>
> I would agree whole-heartedly.
>
That's where I started, but then Tim and others convinced me that it was
actually better/more convenient for users for us to behave more like
java.Math and java's own arithmetic functions -- which use NaN all over
the place. Also, from a usage standpoint, if we use checked exceptions
everywhere, this is a bit inconvenient for users. We need to find the
right balance.
I am one the fence on this whole issue. I am interested in hearing more
about what others may have in mind.
Phil
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] proposed ordering for task list, scope of initial release
Posted by Tim O'Brien <to...@discursive.com>.
On Tue, 2003-06-10 at 23:26, Brent Worden wrote:
> > There are several approaches to design a concept for exceptions,
> > all of which have pros and cons. I personally would suggest to
> > avoid returning NaNs and throwing RuntimeExceptions whereever
> > possible and use a package specific hierarchy of declared exceptions
> > instead.
> >
> > J.Pietschmann
>
> I would agree whole-heartedly.
Returning Double.NaN for situations where it makes sense is a settled
issue which has been addressed about three weeks ago please see previous
discussions on the issue through Eyebrowse.
Tim
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] proposed ordering for task list, scope of initial release
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: Tuesday, June 10, 2003 3:04 PM
> To: Jakarta Commons Developers List
> Subject: Re: [math] proposed ordering for task list, scope of initial
> release
>
>
> Phil Steitz wrote:
> > My philosophy on this is that whatever exceptions we define should be
> > "close" to the components that throw them -- e.g. ConvergenceException.
> > I do not like the idea of a generic "MathException." As much as
> > possible, I think that we should rely on the built-ins (including the
> > extensions recently added to lang). Regarding
> ConvergenceException, I am
> > on the fence for inclusion in the initial release, though I see
> > something like this as eventually inevitable. Correct me if I
> am wrong,
> > but the only place that this is used now is in the dist package and we
> > could either just throw a RuntimeException directly there or
> return NaN.
> > I do see the semantic value of ConvergenceException, however.
>
> There are several approaches to design a concept for exceptions,
> all of which have pros and cons. I personally would suggest to
> avoid returning NaNs and throwing RuntimeExceptions whereever
> possible and use a package specific hierarchy of declared exceptions
> instead.
>
> J.Pietschmann
I would agree whole-heartedly.
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] proposed ordering for task list, scope of initial release
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Phil Steitz wrote:
> My philosophy on this is that whatever exceptions we define should be
> "close" to the components that throw them -- e.g. ConvergenceException.
> I do not like the idea of a generic "MathException." As much as
> possible, I think that we should rely on the built-ins (including the
> extensions recently added to lang). Regarding ConvergenceException, I am
> on the fence for inclusion in the initial release, though I see
> something like this as eventually inevitable. Correct me if I am wrong,
> but the only place that this is used now is in the dist package and we
> could either just throw a RuntimeException directly there or return NaN.
> I do see the semantic value of ConvergenceException, however.
There are several approaches to design a concept for exceptions,
all of which have pros and cons. I personally would suggest to
avoid returning NaNs and throwing RuntimeExceptions whereever
possible and use a package specific hierarchy of declared exceptions
instead.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
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 14:23, Phil Steitz wrote:
> Al Chou wrote:
> 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.
+1
> When the UnivariateImpl window is finite, it should use the same
> computations that AbstractStoreUnivariate does -- this is why we need to
> encapsulate.
+1
I agree with both of these ideas. I think that putting everything in
MathUtil might become unwieldy - no problem with creating a StatUtil.
(If that hasn't already been done, I'm checking my email for the first
time in days)
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> Al Chou wrote:
> > --- Phil Steitz <ph...@steitz.com> wrote:
> >
> >>Brent Worden wrote:
> >>
> >>>>-----Original Message-----
> >>>>From: Phil Steitz [mailto:steitzp@yahoo.com]
> >>>>Sent: Friday, June 06, 2003 12:21 PM
> >>>>To: commons-dev@jakarta.apache.org
> >>>>Subject: [math] proposed ordering for task list, scope of initial
> >>>>release
> >>>
> > [deletia]
> >
> >>>Things that might be added:
> >>>Average of two numbers comes up a lot.
> >>
> >>Yes. Some (of us) might not like the organization of this; but I have a
> >>couple of times posted the suggestion that we add several
> >>double[]->double functions to MathUtils representing the core
> >>computations for univariate -- mean, min, max, variance, sum, sumsq.
> >>This would be convenient for users and us as well. I guess I would not
> >>be averse to moving these to stat.StatUtils, maybe just adding ave(x,y)
> >>to MathUtils.
> >>
> >>Given the post that I just saw regarding financial computations, I
> >>suggest that we let MathUtils grow a bit (including the double[]->double
> >>functions and then think about breaking it apart prior to release. As
> >>long as we stick to simple static methods, that will not be hard to do.
> >
> >
> > 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.
My organizational instincts say to put the implementation in stat and delegate
to it from MathUtils. Probably 99% of actual use will consist of code calling
MathUtils (because no one will bother to learn that the implementation is
really in stat), but until we see a performance problem I'm strongly for
categorizing things as what they are (what they are in my mind, of course <g>).
Avoiding premature optimization and YAGNI, and so on....
> >>>Some other constants besides E and PI: golden ratio, euler, sqrt(PI), etc.
> >>>I've used a default error constant several places.
> >>
> >> It would be nice to come
> >>
> >>>up with a central location for such values.
> >>
> >>I get the first 3, but what exactly do you mean by the default error
> >>constant?
> >
> >
> > I read that to mean the accuracy requested (aka allowable error) of a given
> > algorithm invocation.
> >
>
> But why would we ever want to define that as a constant?
I wouldn't, at least not as a global constant. That's why I suggested we
define an interface that can be implemented by the classes that need this
functionality. That way we'll have a consistent way to set the value for each
class that needs it. Currently, Brent's bisection method hardcodes it, whereas
Herr Pietschmann's framework provides a getter/setter pair in an interface. I
wonder if it's even possible to abstract further and pull the accuracy aspect
into a separate interface. Accuracy/error _seems_ like a general concept, but
it could be too fuzzy a concept to yield a concrete interface specification.
> >>>In addition to the above, has any thought gone into a set of application
> >>>exceptions that will be thrown. Are we going to rely on Java core
> >>>exceptions or are we going to create some application specific exceptions?
> >>>As I recall J uses a MathException in the solver routines and I added a
> >>>ConvergenceException. Should we expand that list or fold it into one
> >>>generic application exception or do away with application exceptions all
> >>>together?
> >>
> >>My philosophy on this is that whatever exceptions we define should be
> >>"close" to the components that throw them -- e.g. ConvergenceException.
> >> I do not like the idea of a generic "MathException." As much as
> >>possible, I think that we should rely on the built-ins (including the
> >>extensions recently added to lang). Regarding ConvergenceException, I am
> >>on the fence for inclusion in the initial release, though I see
> >>something like this as eventually inevitable. Correct me if I am wrong,
> >>but the only place that this is used now is in the dist package and we
> >>could either just throw a RuntimeException directly there or return NaN.
> >> I do see the semantic value of ConvergenceException, however. I guess
> >>I would vote for keeping it.
> >
> >
> > I agree that we should have exceptions be as specific as possible.
> > MathException could be an abstract parent for all of the commons-math
> exception
> > classes, maybe.
> >
>
> I do not see the need for an abstract hierarchy of math exceptions at
> this time. Of course, I could be convinced of this is someone explains
> why we can't just use or subclass things in java + lang.
I agree; I'm certainly willing to defer decisions about this area for now.
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] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Al Chou wrote:
> --- Phil Steitz <ph...@steitz.com> wrote:
>
>>Brent Worden wrote:
>>
>>>>-----Original Message-----
>>>>From: Phil Steitz [mailto:steitzp@yahoo.com]
>>>>Sent: Friday, June 06, 2003 12:21 PM
>>>>To: commons-dev@jakarta.apache.org
>>>>Subject: [math] proposed ordering for task list, scope of initial
>>>>release
>>>
> [deletia]
>
>>>Things that might be added:
>>>Average of two numbers comes up a lot.
>>
>>Yes. Some (of us) might not like the organization of this; but I have a
>>couple of times posted the suggestion that we add several
>>double[]->double functions to MathUtils representing the core
>>computations for univariate -- mean, min, max, variance, sum, sumsq.
>>This would be convenient for users and us as well. I guess I would not
>>be averse to moving these to stat.StatUtils, maybe just adding ave(x,y)
>>to MathUtils.
>>
>>Given the post that I just saw regarding financial computations, I
>>suggest that we let MathUtils grow a bit (including the double[]->double
>>functions and then think about breaking it apart prior to release. As
>>long as we stick to simple static methods, that will not be hard to do.
>
>
> 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.
>
>>>Some other constants besides E and PI: golden ratio, euler, sqrt(PI), etc.
>>>I've used a default error constant several places.
>>
>> It would be nice to come
>>
>>>up with a central location for such values.
>>
>>I get the first 3, but what exactly do you mean by the default error
>>constant?
>
>
> I read that to mean the accuracy requested (aka allowable error) of a given
> algorithm invocation.
>
But why would we ever want to define that as a constant?
>
>
>>>In addition to the above, has any thought gone into a set of application
>>>exceptions that will be thrown. Are we going to rely on Java core
>>>exceptions or are we going to create some application specific exceptions?
>>>As I recall J uses a MathException in the solver routines and I added a
>>>ConvergenceException. Should we expand that list or fold it into one
>>>generic application exception or do away with application exceptions all
>>>together?
>>
>>My philosophy on this is that whatever exceptions we define should be
>>"close" to the components that throw them -- e.g. ConvergenceException.
>> I do not like the idea of a generic "MathException." As much as
>>possible, I think that we should rely on the built-ins (including the
>>extensions recently added to lang). Regarding ConvergenceException, I am
>>on the fence for inclusion in the initial release, though I see
>>something like this as eventually inevitable. Correct me if I am wrong,
>>but the only place that this is used now is in the dist package and we
>>could either just throw a RuntimeException directly there or return NaN.
>> I do see the semantic value of ConvergenceException, however. I guess
>>I would vote for keeping it.
>
>
> I agree that we should have exceptions be as specific as possible.
> MathException could be an abstract parent for all of the commons-math exception
> classes, maybe.
>
I do not see the need for an abstract hierarchy of math exceptions at
this time. Of course, I could be convinced of this is someone explains
why we can't just use or subclass things in java + lang.
>
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Brent Worden wrote:
>>-----Original Message-----
>>From: Al Chou [mailto:hotfusionman@yahoo.com]
>>Sent: Tuesday, June 10, 2003 2:14 PM
>>To: Jakarta Commons Developers List
>>Subject: Re: [math] proposed ordering for task list, scope of initial
>>release
>>
>>
>>--- Phil Steitz <ph...@steitz.com> wrote:
>>
>>>Brent Worden wrote:
>>>
>>>>I've used a default error constant several places.
>>>
>>> It would be nice to come
>>>
>>>>up with a central location for such values.
>>>
>>>I get the first 3, but what exactly do you mean by the default error
>>>constant?
>>
>>I read that to mean the accuracy requested (aka allowable error)
>>of a given
>>algorithm invocation.
>>
>
>
> That's right. Certain routines perform their iterative computations until a
> desired accuracy is achieved. If the user doesn't explicitly state this
> accuracy, what should it be? A default error/accuracy constant would answer
> that and provide uniform level of accuracy throughout the library.
Now I get it. But I am not comfortable with the scope. I could see this
defined for RootFinding or Distributions, etc, but not in general. In
general, the constant would have no meaning (to me, at least). I would
prefer to let individual implementations define their own defaults
(specified in the javadoc of course) and allow users to override. A
single default "max iterations" for both rootfinding and, e.g. numerical
integration, makes no sense. Better to have the defaults scoped at the
algorithm/implementation level.
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] proposed ordering for task list, scope of initial release
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: Al Chou [mailto:hotfusionman@yahoo.com]
> Sent: Tuesday, June 10, 2003 2:14 PM
> To: Jakarta Commons Developers List
> Subject: Re: [math] proposed ordering for task list, scope of initial
> release
>
>
> --- Phil Steitz <ph...@steitz.com> wrote:
> > Brent Worden wrote:
> > > I've used a default error constant several places.
> > It would be nice to come
> > > up with a central location for such values.
> >
> > I get the first 3, but what exactly do you mean by the default error
> > constant?
>
> I read that to mean the accuracy requested (aka allowable error)
> of a given
> algorithm invocation.
>
That's right. Certain routines perform their iterative computations until a
desired accuracy is achieved. If the user doesn't explicitly state this
accuracy, what should it be? A default error/accuracy constant would answer
that and provide uniform level of accuracy throughout the library.
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] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> Brent Worden wrote:
> >>-----Original Message-----
> >>From: Phil Steitz [mailto:steitzp@yahoo.com]
> >>Sent: Friday, June 06, 2003 12:21 PM
> >>To: commons-dev@jakarta.apache.org
> >>Subject: [math] proposed ordering for task list, scope of initial
> >>release
[deletia]
> > Things that might be added:
> > Average of two numbers comes up a lot.
>
> Yes. Some (of us) might not like the organization of this; but I have a
> couple of times posted the suggestion that we add several
> double[]->double functions to MathUtils representing the core
> computations for univariate -- mean, min, max, variance, sum, sumsq.
> This would be convenient for users and us as well. I guess I would not
> be averse to moving these to stat.StatUtils, maybe just adding ave(x,y)
> to MathUtils.
>
> Given the post that I just saw regarding financial computations, I
> suggest that we let MathUtils grow a bit (including the double[]->double
> functions and then think about breaking it apart prior to release. As
> long as we stick to simple static methods, that will not be hard to do.
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).
> > Some other constants besides E and PI: golden ratio, euler, sqrt(PI), etc.
> > I've used a default error constant several places.
> It would be nice to come
> > up with a central location for such values.
>
> I get the first 3, but what exactly do you mean by the default error
> constant?
I read that to mean the accuracy requested (aka allowable error) of a given
algorithm invocation.
> > In addition to the above, has any thought gone into a set of application
> > exceptions that will be thrown. Are we going to rely on Java core
> > exceptions or are we going to create some application specific exceptions?
> > As I recall J uses a MathException in the solver routines and I added a
> > ConvergenceException. Should we expand that list or fold it into one
> > generic application exception or do away with application exceptions all
> > together?
>
> My philosophy on this is that whatever exceptions we define should be
> "close" to the components that throw them -- e.g. ConvergenceException.
> I do not like the idea of a generic "MathException." As much as
> possible, I think that we should rely on the built-ins (including the
> extensions recently added to lang). Regarding ConvergenceException, I am
> on the fence for inclusion in the initial release, though I see
> something like this as eventually inevitable. Correct me if I am wrong,
> but the only place that this is used now is in the dist package and we
> could either just throw a RuntimeException directly there or return NaN.
> I do see the semantic value of ConvergenceException, however. I guess
> I would vote for keeping it.
I agree that we should have exceptions be as specific as possible.
MathException could be an abstract parent for all of the commons-math exception
classes, maybe.
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] proposed ordering for task list, scope of initial release
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: Phil Steitz [mailto:phil@steitz.com]
> >>* The RealMatrixImpl class is missing some key method
> implementations. The
> >>critical thing is solution of linear systems. We need to implement a
> >>numerically sound solution algorithm. This will enable
> inverse() and also
> >>support general linear regression. -- I think that Brent is
> >>working on this.
> >
> >
> > The only thing I've done is the Cholesky decomposition. I haven't done
> > anything for the general linear system case.
> >
> Are you going to do this, or should I take it on?
Go ahead.
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] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Brent Worden wrote:
>>-----Original Message-----
>>From: Phil Steitz [mailto:steitzp@yahoo.com]
>>Sent: Friday, June 06, 2003 12:21 PM
>>To: commons-dev@jakarta.apache.org
>>Subject: [math] proposed ordering for task list, scope of initial
>>release
>>
>>
>>Here is a *proposed* ordering for the task list, with a little commentary
>>added.
>>
>>One thing that I want to make *very* clear up front, is that I
>>*never* intended
>>the task list or the items listed in the scope section of the
>>proposal to be
>>definitive. All that is definitive are the guiding principles,
>>which just try
>>to keep us focused on stuff that people will find both useful and
>>easy to use.
>>I expected that the actual contents of the first release would
>>include some
>>things not on the list and would exclude some of the things
>>there. At this
>>stage, as Jouzas pointed out, it is more important for us to
>>build community
>>than to rush a release out the door. So if there are things that fit the
>>guidelines that others would like to contribute, but which are
>>not on the list,
>>*please* suggest them. Also, for those who may not have dug into
>>the code, but
>>who may be interested in contributing, please rest assured that deep
>>mathematical knowledge is not required to help. We can review
>>implementations
>>and deal with mathematical problems as they arise, using our
>>small but growing
>>community as a resource. The same is obviously true on the the
>>Java/OS tools
>>side -- no need to be an expert to contribute.
>>
>>OK, long-winded disclaimer aside, here is how I see the task list ordered:
>>
>>* The RealMatrixImpl class is missing some key method implementations. The
>>critical thing is solution of linear systems. We need to implement a
>>numerically sound solution algorithm. This will enable inverse() and also
>>support general linear regression. -- I think that Brent is
>>working on this.
>
>
> The only thing I've done is the Cholesky decomposition. I haven't done
> anything for the general linear system case.
>
Are you going to do this, or should I take it on?
>
>>* t-test statistic needs to be added and we should probably add
>>the capability
>>of actually performing t- and chi-square tests at fixed
>>significance levels
>>(.1, .05, .01, .001). -- This is virtually done, just need to
>>define a nice,
>>convenient interface for doing one- and two-tailed tests. Thanks
>>to Brent, we
>>can actually support user-supplied significance levels (next item)
>
>
> Anyone have any thoughts on the interface? I was thinking of an Inference
> interface that supports the conducting of one- and two-tailed tests as well
> as constructing their complementary confidence intervals. Or, if we want to
> separate concerns create both a HypothesisTest and a ConfidenceInterval
> interface, one for each type of inference. Either way, I would use the
> tried-and-true abstract factory way of creating inference instances.
> Comments are welcome.
>
>
>>* numerical approximation of the t- and chi-square distributions to enable
>>user-supplied significance levels. See above. Someone just
>>needs to put a
>>fork in this. Tim? Brent?
>
>
> Done.
>
Including the testing interface? See below.
>
>>* *new* add support for F distribution and F test, so that we can report
>>signinficance level of correlation coefficient in bivariate regression /
>>signinficance of model. I will do this if no one else wants to.
>
>
> Done. I'll probably knock out a few more easy continuous distributions to
> get them out of the way.
>
>
>>* Framework and implementation strategie(s) for finding roots or
>>real-valued
>>functions of one (real) variable. Here again -- largely done. I
>>would prefer
>>to wait until J gets back and let him submit his framework and R. Brent's
>>algorithm. Then "our" Brent's implementation and usage can be integrated
>>(actually not much to do, from the looks of the current code) and
>>I will add my
>>"bean equations" stuff (in progress).
>
>
> Sounds good.
>
>
>>* Extend distribution framework to support discrete distributions
>>and implement
>>binomial and hypergeometric distributions. I will do this if no
>>one else wants
>>to. If someone else does it, you should make sure to use the log
>>binomials in
>>computations.
>
>
> Binomial can easily be obtained using the regularized beta function that is
> already defined. Hypergeometric will be a little more work as I don't think
> there's a compact formula to compute the cpf.
Using the log binomials, direct computation of the density might not be
too bad. I have not researched this, but that is what I was thinking.
One thing to note, since the
> discrete distributions do not have nice invertible mappings for critical
> values to probabilities like those found for continuous distributions, how
> should the inverseCummulativeProbability method work? For a given
> probability, p, should the method return one value, x, such that x is the
> largest value where P(X <= x) <= p? Or the smallest value, x, where P(X <=
> x) >= p. Or should the method return two values, x0 and x1, such that P(X
> <= x0) <= p <= P(X <= x1)?
I think in the discrete case, we should supply the density function (and
the cumulative probability function) and probably omit the
inverseCumulativeProbability method. If we were to add it, I would use
the second of your alternatives above.
>
>
>>* Exponential growth and decay (set up for financial
>>applications) I think this
>>is just going to be a matter of finding the right formulas to add
>>to MathUtils.
>> I don't want to get carried away with financial computations,
>>but some simple,
>>commonly used formulas would be a nice addition to the package.
>>We should also
>>be thinking about other things to add to MathUtils -- religiously
>>adhering to
>>th guiding principles, of course. Al's sign() is an excellent
>>example of the
>>kind of thing that we should be adding, IMHO.
>
>
> Things that might be added:
> Average of two numbers comes up a lot.
Yes. Some (of us) might not like the organization of this; but I have a
couple of times posted the suggestion that we add several
double[]->double functions to MathUtils representing the core
computations for univariate -- mean, min, max, variance, sum, sumsq.
This would be convenient for users and us as well. I guess I would not
be averse to moving these to stat.StatUtils, maybe just adding ave(x,y)
to MathUtils.
Given the post that I just saw regarding financial computations, I
suggest that we let MathUtils grow a bit (including the double[]->double
functions and then think about breaking it apart prior to release. As
long as we stick to simple static methods, that will not be hard to do.
> Something similar to JUnit's assertEquals(double expected, double actual,
> double epsilon).
Good idea
> Simple methods like isPositive, isNegative, etc. can be used to make boolean
> expressions more human readable.
I agree
> Some other constants besides E and PI: golden ratio, euler, sqrt(PI), etc.
> I've used a default error constant several places.
I get the first 3, but what exactly do you mean by the default error
constant?
It would be nice to come
> up with a central location for such values.
>
>
> In addition to the above, has any thought gone into a set of application
> exceptions that will be thrown. Are we going to rely on Java core
> exceptions or are we going to create some application specific exceptions?
> As I recall J uses a MathException in the solver routines and I added a
> ConvergenceException. Should we expand that list or fold it into one
> generic application exception or do away with application exceptions all
> together?
>
My philosophy on this is that whatever exceptions we define should be
"close" to the components that throw them -- e.g. ConvergenceException.
I do not like the idea of a generic "MathException." As much as
possible, I think that we should rely on the built-ins (including the
extensions recently added to lang). Regarding ConvergenceException, I am
on the fence for inclusion in the initial release, though I see
something like this as eventually inevitable. Correct me if I am wrong,
but the only place that this is used now is in the dist package and we
could either just throw a RuntimeException directly there or return NaN.
I do see the semantic value of ConvergenceException, however. I guess
I would vote for keeping it.
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Brent Worden wrote:
>>-----Original Message-----
>>* t-test statistic needs to be added and we should probably add
>>the capability
>>of actually performing t- and chi-square tests at fixed
>>significance levels
>>(.1, .05, .01, .001). -- This is virtually done, just need to
>>define a nice,
>>convenient interface for doing one- and two-tailed tests. Thanks
>>to Brent, we
>>can actually support user-supplied significance levels (next item)
>
>
> Anyone have any thoughts on the interface? I was thinking of an Inference
> interface that supports the conducting of one- and two-tailed tests as well
> as constructing their complementary confidence intervals. Or, if we want to
> separate concerns create both a HypothesisTest and a ConfidenceInterval
> interface, one for each type of inference. Either way, I would use the
> tried-and-true abstract factory way of creating inference instances.
> Comments are welcome.
I have been thinking about this. If I can stop sending emails for long
enought to pull the patch together, I am about to submit a patch to
BivariateRegression that adds the slope confidence interval computation
and significance level, based on the new t-distribution impl (thanks,
Brent!). I thought about a generic ConfidenceInterval interface, but
then thought that it would be more convenient for users to just return
the halfwidth in double getSlopeConfidenceInterval(). To support the
goal of testing model significance, I also added getSignificance().
I think the concrete stuff is easier to use and all we need at present.
Something like:
boolean twoTailedTTest(Univariate, Univariate,signif) or even
boolean twoTailedTTest(double[],double[],signif)
(obviously adding one-tailed tests and tests against constants as well
and tests that return doubles representing minimal p-values, possibly
called "significance")
boolean chiSquareTest(expected, observed, signif)
boolean chiSquareTest(Freq, Freq, signif)
To add the abstractions above meaningfully, we need to convince
ourselves that either a) multiple implementation strategies might exist
-- For parametric tests, this is not the case -- or b) the abstractions
will make development of inferential components easier/more manageable.
I am not sure about b). In fact, when I think about it I think that
there is not much left when you abstract things to a high enough level
to represent hypothesis testing and/or confidence intervals generically.
I remember math stat students having a hard time understanding the
abstract definitions of these concepts. I don't think that it is a good
idea to force our users to think about these things. Therefore, I would
recommend sticking with concrete implementations defined "close to" the
statistical applications.
Keep the user application use cases in mind. If I want to determine
whether the diffence in two means is significant, I should be able to do
that quickly and intuitively, with one method call either using
Univariates or double[]s.
>
>
>>* numerical approximation of the t- and chi-square distributions to enable
>>user-supplied significance levels. See above. Someone just
>>needs to put a
>>fork in this. Tim? Brent?
>
>
> Done.
>
---------------------------------------------------------------------
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
[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>.
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] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> Al Chou wrote:
> > --- Phil Steitz <ph...@steitz.com> wrote:
> >>Al Chou wrote:
> >>>--- Brent Worden <br...@worden.org> wrote:
> >>>>>-----Original Message-----
> >>>>>From: Phil Steitz [mailto:steitzp@yahoo.com]
> >>>>>Sent: Friday, June 06, 2003 12:21 PM
[deletia]
> >>>>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
=====
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] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Al Chou wrote:
> --- Phil Steitz <ph...@steitz.com> wrote:
>
>>Al Chou wrote:
>>
>>>--- Brent Worden <br...@worden.org> wrote:
>>>
>>>>>-----Original Message-----
>>>>>From: Phil Steitz [mailto:steitzp@yahoo.com]
>>>>>Sent: Friday, June 06, 2003 12:21 PM
>>>>
> [deletia]
>
>>>>Something similar to JUnit's assertEquals(double expected, double actual,
>>>>double epsilon).
>>>
>>This is a good idea.
>>
>>
>>>Is JUnit's license (http://www.opensource.org/licenses/ibmpl.php) Apache
>>>compatible?
>>>
>>
>>I think that Brent is talking about defining a new function called
>>something like approximatelyEquals() that returned a boolean. The
>>signature, semantics and implementation of this would be different from
>>JUnit.
>
>
> Ah, OK. That could be useful indeed.
>
>
>
>>>>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.
>
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> Al Chou wrote:
> > --- Brent Worden <br...@worden.org> wrote:
> >>>-----Original Message-----
> >>>From: Phil Steitz [mailto:steitzp@yahoo.com]
> >>>Sent: Friday, June 06, 2003 12:21 PM
[deletia]
> >>Something similar to JUnit's assertEquals(double expected, double actual,
> >>double epsilon).
> >
> This is a good idea.
>
> >
> > Is JUnit's license (http://www.opensource.org/licenses/ibmpl.php) Apache
> > compatible?
> >
>
> I think that Brent is talking about defining a new function called
> something like approximatelyEquals() that returned a boolean. The
> signature, semantics and implementation of this would be different from
> JUnit.
Ah, OK. That could be useful indeed.
> >>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.
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] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Al Chou wrote:
> --- Brent Worden <br...@worden.org> wrote:
>
>>>-----Original Message-----
>>>From: Phil Steitz [mailto:steitzp@yahoo.com]
>>>Sent: Friday, June 06, 2003 12:21 PM
>>
> [deletia]
>
>>>* Exponential growth and decay (set up for financial
>>>applications) I think this
>>>is just going to be a matter of finding the right formulas to add
>>>to MathUtils.
>>> I don't want to get carried away with financial computations,
>>>but some simple,
>>>commonly used formulas would be a nice addition to the package.
>>>We should also
>>>be thinking about other things to add to MathUtils -- religiously
>>>adhering to
>>>th guiding principles, of course. Al's sign() is an excellent
>>>example of the
>>>kind of thing that we should be adding, IMHO.
>>
>>Things that might be added:
>>Average of two numbers comes up a lot.
>
>
> Do we muddy the class hierarchy by putting such a thing into MathUtils rather
> than the stat subtree?
>
>
>
>>Something similar to JUnit's assertEquals(double expected, double actual,
>>double epsilon).
>
This is a good idea.
>
> Is JUnit's license (http://www.opensource.org/licenses/ibmpl.php) Apache
> compatible?
>
I think that Brent is talking about defining a new function called
something like approximatelyEquals() that returned a boolean. The
signature, semantics and implementation of this would be different from
JUnit.
>
>
>>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 :-)
>
>
>>Some other constants besides E and PI: golden ratio, euler, sqrt(PI), etc.
>
>
> That would be nice, though we should consider which ones are really needed
> generally. I personally love the lore of constants, of which there are more
> than you might imagine (see
> http://mathworld.wolfram.com/topics/Constants.html).
>
>
>
>>I've used a default error constant several places. It would be nice to come
>>up with a central location for such values.
>
>
> Or at least define a consistent interface that could be implemented by whatever
> needs that.
>
>
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- Brent Worden <br...@worden.org> wrote:
> > -----Original Message-----
> > From: Phil Steitz [mailto:steitzp@yahoo.com]
> > Sent: Friday, June 06, 2003 12:21 PM
[deletia]
> > * Exponential growth and decay (set up for financial
> > applications) I think this
> > is just going to be a matter of finding the right formulas to add
> > to MathUtils.
> > I don't want to get carried away with financial computations,
> > but some simple,
> > commonly used formulas would be a nice addition to the package.
> > We should also
> > be thinking about other things to add to MathUtils -- religiously
> > adhering to
> > th guiding principles, of course. Al's sign() is an excellent
> > example of the
> > kind of thing that we should be adding, IMHO.
>
> Things that might be added:
> Average of two numbers comes up a lot.
Do we muddy the class hierarchy by putting such a thing into MathUtils rather
than the stat subtree?
> Something similar to JUnit's assertEquals(double expected, double actual,
> double epsilon).
Is JUnit's license (http://www.opensource.org/licenses/ibmpl.php) Apache
compatible?
> 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.
> Some other constants besides E and PI: golden ratio, euler, sqrt(PI), etc.
That would be nice, though we should consider which ones are really needed
generally. I personally love the lore of constants, of which there are more
than you might imagine (see
http://mathworld.wolfram.com/topics/Constants.html).
> I've used a default error constant several places. It would be nice to come
> up with a central location for such values.
Or at least define a consistent interface that could be implemented by whatever
needs that.
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] proposed ordering for task list, scope of initial release
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: Phil Steitz [mailto:steitzp@yahoo.com]
> Sent: Friday, June 06, 2003 12:21 PM
> To: commons-dev@jakarta.apache.org
> Subject: [math] proposed ordering for task list, scope of initial
> release
>
>
> Here is a *proposed* ordering for the task list, with a little commentary
> added.
>
> One thing that I want to make *very* clear up front, is that I
> *never* intended
> the task list or the items listed in the scope section of the
> proposal to be
> definitive. All that is definitive are the guiding principles,
> which just try
> to keep us focused on stuff that people will find both useful and
> easy to use.
> I expected that the actual contents of the first release would
> include some
> things not on the list and would exclude some of the things
> there. At this
> stage, as Jouzas pointed out, it is more important for us to
> build community
> than to rush a release out the door. So if there are things that fit the
> guidelines that others would like to contribute, but which are
> not on the list,
> *please* suggest them. Also, for those who may not have dug into
> the code, but
> who may be interested in contributing, please rest assured that deep
> mathematical knowledge is not required to help. We can review
> implementations
> and deal with mathematical problems as they arise, using our
> small but growing
> community as a resource. The same is obviously true on the the
> Java/OS tools
> side -- no need to be an expert to contribute.
>
> OK, long-winded disclaimer aside, here is how I see the task list ordered:
>
> * The RealMatrixImpl class is missing some key method implementations. The
> critical thing is solution of linear systems. We need to implement a
> numerically sound solution algorithm. This will enable inverse() and also
> support general linear regression. -- I think that Brent is
> working on this.
The only thing I've done is the Cholesky decomposition. I haven't done
anything for the general linear system case.
> * t-test statistic needs to be added and we should probably add
> the capability
> of actually performing t- and chi-square tests at fixed
> significance levels
> (.1, .05, .01, .001). -- This is virtually done, just need to
> define a nice,
> convenient interface for doing one- and two-tailed tests. Thanks
> to Brent, we
> can actually support user-supplied significance levels (next item)
Anyone have any thoughts on the interface? I was thinking of an Inference
interface that supports the conducting of one- and two-tailed tests as well
as constructing their complementary confidence intervals. Or, if we want to
separate concerns create both a HypothesisTest and a ConfidenceInterval
interface, one for each type of inference. Either way, I would use the
tried-and-true abstract factory way of creating inference instances.
Comments are welcome.
>
> * numerical approximation of the t- and chi-square distributions to enable
> user-supplied significance levels. See above. Someone just
> needs to put a
> fork in this. Tim? Brent?
Done.
>
> * *new* add support for F distribution and F test, so that we can report
> signinficance level of correlation coefficient in bivariate regression /
> signinficance of model. I will do this if no one else wants to.
Done. I'll probably knock out a few more easy continuous distributions to
get them out of the way.
>
> * Framework and implementation strategie(s) for finding roots or
> real-valued
> functions of one (real) variable. Here again -- largely done. I
> would prefer
> to wait until J gets back and let him submit his framework and R. Brent's
> algorithm. Then "our" Brent's implementation and usage can be integrated
> (actually not much to do, from the looks of the current code) and
> I will add my
> "bean equations" stuff (in progress).
Sounds good.
>
> * Extend distribution framework to support discrete distributions
> and implement
> binomial and hypergeometric distributions. I will do this if no
> one else wants
> to. If someone else does it, you should make sure to use the log
> binomials in
> computations.
Binomial can easily be obtained using the regularized beta function that is
already defined. Hypergeometric will be a little more work as I don't think
there's a compact formula to compute the cpf. One thing to note, since the
discrete distributions do not have nice invertible mappings for critical
values to probabilities like those found for continuous distributions, how
should the inverseCummulativeProbability method work? For a given
probability, p, should the method return one value, x, such that x is the
largest value where P(X <= x) <= p? Or the smallest value, x, where P(X <=
x) >= p. Or should the method return two values, x0 and x1, such that P(X
<= x0) <= p <= P(X <= x1)?
>
> * Exponential growth and decay (set up for financial
> applications) I think this
> is just going to be a matter of finding the right formulas to add
> to MathUtils.
> I don't want to get carried away with financial computations,
> but some simple,
> commonly used formulas would be a nice addition to the package.
> We should also
> be thinking about other things to add to MathUtils -- religiously
> adhering to
> th guiding principles, of course. Al's sign() is an excellent
> example of the
> kind of thing that we should be adding, IMHO.
Things that might be added:
Average of two numbers comes up a lot.
Something similar to JUnit's assertEquals(double expected, double actual,
double epsilon).
Simple methods like isPositive, isNegative, etc. can be used to make boolean
expressions more human readable.
Some other constants besides E and PI: golden ratio, euler, sqrt(PI), etc.
I've used a default error constant several places. It would be nice to come
up with a central location for such values.
In addition to the above, has any thought gone into a set of application
exceptions that will be thrown. Are we going to rely on Java core
exceptions or are we going to create some application specific exceptions?
As I recall J uses a MathException in the solver routines and I added a
ConvergenceException. Should we expand that list or fold it into one
generic application exception or do away with application exceptions all
together?
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] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Al Chou wrote:
>
[deletia]**2
>
>>* Improve numerical accuracy of Univariate and BivariateRegression
>>statistical
>>computations. Encapsulate basic double[] |-> double mean, variance, min, max
>>computations using improved formulas and add these to MathUtils. (probably
>>should add float[], int[], long[] versions as well.) Then refactor all
>>univariate implementations that use stored values (including UnivariateImpl
>>with finite window) to use the improved versions. -- Mark? I am chasing down
>>the TAS reference to document the source of the _NR_ formula, which I will
>>add
>>to the docs if someone else does the implementation.
>
>
> I was starting to code the updating (storage-less) variance formula, based on
> the Stanford article you cited, as a patch. I believe the storage-using
> corrected two-pass algorithm is pretty trivial to code once we feel we're on
> solid ground with the reference to cite.
Yes. I just wanted to propose the refactoring.
>>
>>* Framework and implementation strategie(s) for finding roots or real-valued
>>functions of one (real) variable. Here again -- largely done. I would
>>prefer
>>to wait until J gets back and let him submit his framework and R. Brent's
>>algorithm. Then "our" Brent's implementation and usage can be integrated
>>(actually not much to do, from the looks of the current code) and I will add
>>my "bean equations" stuff (in progress).
>
>
> I may have time to submit my Ridders' method implementation using J.'s
> framework before he returns 2 days hence. Should I bother to try, or should I
> wait until he submits his code as a patch via Bugzilla?
I doubt that J would mind if someone else were to submit the framework
(including his @author of course) from his post to the list. You could
combine his classes and yours into one patch and submit it if you have
time to do this before he gets back.
>
>>* Polynomial Interpolation -- let Al tell us what to do here. Even better,
>>let Al do it (he he).
>
>
> I actually did some research last night (I told myself I was going to bed
> early, hah) on rational function interpolation, trying to find a primary source
> for the algorithm rather than again rely on a secondary source in the form of
> NR. I guess I'll continue along this path, as I really want a clean room
> implementation of it for my own use. I'd feel better using rational functions
> rather than polynomials for their generally larger radius of convergence.
Thanks for looking into this. If you think rational functions are
better, go for it. One more thing to think about is splines. A natural
spline implementation might be easier to document/understand from users'
perspective. We might want to eventually support both (and maybe even
polynomial interpolation).
Phil
>
>
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- "J.Pietschmann" <j3...@yahoo.de> wrote:
> Al Chou wrote:
> > I may have time to submit my Ridders' method implementation using J.'s
> > framework before he returns 2 days hence. Should I bother to try, or
> should I
> > wait until he submits his code as a patch via Bugzilla?
>
> I'm a bit short on spare time anyway.
OK, I'll submit on your behalf.
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] proposed ordering for task list, scope of initial release
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Al Chou wrote:
> I may have time to submit my Ridders' method implementation using J.'s
> framework before he returns 2 days hence. Should I bother to try, or should I
> wait until he submits his code as a patch via Bugzilla?
I'm a bit short on spare time anyway.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> >>* Improve numerical accuracy of Univariate and BivariateRegression
> >>statistical
> >>computations. Encapsulate basic double[] |-> double mean, variance, min,
> max
> >>computations using improved formulas and add these to MathUtils. (probably
> >>should add float[], int[], long[] versions as well.) Then refactor all
> >>univariate implementations that use stored values (including UnivariateImpl
> >>with finite window) to use the improved versions. -- Mark? I am chasing
> down
> >>the TAS reference to document the source of the _NR_ formula, which I will
> >>add
> >>to the docs if someone else does the implementation.
> >
> >
> > I was starting to code the updating (storage-less) variance formula, based
> on
> > the Stanford article you cited, as a patch. I believe the storage-using
> > corrected two-pass algorithm is pretty trivial to code once we feel we're
> on
> > solid ground with the reference to cite.
> >
> >
> OK. I finally got hold of the American Statistician article (had to
> resort to the old trundle down to local university library method) and
Great! Thanks.
> found lots of good stuff in it -- including a reference to Hanson's
> recursive formula (from Stanford paper) and some empirical and
> theoretical results confirming that NR 14.1.8 is about the best that you
> can do for the stored case. There is a refinement mentioned in which
> "pairwise summation" is used (essentially splitting the sample in two
> and computing the recursive sums in parallel); but the value of this
I was wondering what the pairwise method was, and whether it was another name
for a technique we'd already discussed. Sounds sort of like Shell's sort or
other recursive divide-and-occur algorithms.
> only kicks in for large n. I propose that we use NR 14.1.8 as is for
> all stored computations. Here is good text for the reference:
>
> Based on the <i>corrected two-pass algorithm</i> for computing the
> sample variance, as described in "Algorithms for Computing the Sample
> Variance: Analysis and Recommendations",Tony F Chan, Gene H. Golub and
> Randall J. LeVeque, <i>The American Statitistician</i>, 1983, Vol 37,
> No. 3. (Eq. (1.7) on page 243.)
>
> The empirical investigation that the authors do uses the following trick
> that I have thought about using to investigate the precision in our
> stuff: implement an algorithm using both floats and doubles and use the
> double computations to assess stability of the algorithm implemented
> using floats. Might want to play with this a little.
Yes, I skimmed part of the Stanford article and noticed that test technique.
It's interesting, and as you say, we may want to experiment with it to see what
it can tell us.
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] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
>>* Improve numerical accuracy of Univariate and BivariateRegression
>>statistical
>>computations. Encapsulate basic double[] |-> double mean, variance, min, max
>>computations using improved formulas and add these to MathUtils. (probably
>>should add float[], int[], long[] versions as well.) Then refactor all
>>univariate implementations that use stored values (including UnivariateImpl
>>with finite window) to use the improved versions. -- Mark? I am chasing down
>>the TAS reference to document the source of the _NR_ formula, which I will
>>add
>>to the docs if someone else does the implementation.
>
>
> I was starting to code the updating (storage-less) variance formula, based on
> the Stanford article you cited, as a patch. I believe the storage-using
> corrected two-pass algorithm is pretty trivial to code once we feel we're on
> solid ground with the reference to cite.
>
>
OK. I finally got hold of the American Statistician article (had to
resort to the old trundle down to local university library method) and
found lots of good stuff in it -- including a reference to Hanson's
recursive formula (from Stanford paper) and some empirical and
theoretical results confirming that NR 14.1.8 is about the best that you
can do for the stored case. There is a refinement mentioned in which
"pairwise summation" is used (essentially splitting the sample in two
and computing the recursive sums in parallel); but the value of this
only kicks in for large n. I propose that we use NR 14.1.8 as is for
all stored computations. Here is good text for the reference:
Based on the <i>corrected two-pass algorithm</i> for computing the
sample variance, as described in "Algorithms for Computing the Sample
Variance: Analysis and Recommendations",Tony F Chan, Gene H. Golub and
Randall J. LeVeque, <i>The American Statitistician</i>, 1983, Vol 37,
No. 3. (Eq. (1.7) on page 243.)
The empirical investigation that the authors do uses the following trick
that I have thought about using to investigate the precision in our
stuff: implement an algorithm using both floats and doubles and use the
double computations to assess stability of the algorithm implemented
using floats. Might want to play with this a little.
Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Al Chou wrote:
> Having to instantiate an instance of the solver class seemed unnecessary.
Ah!
Well, I imagined somewhat more expensive consistency checks if
accuracy was changed.
Actually there are three accuracies potentially interesting for
root finders:
- the absolute accuracy for the root
- the relative accuracy of the root
- an upper bound on what counts as "f(x) is zero"
Also
> You'd have to
>
> RootFinding.setAccuracy() ;
>
> between calls to different function/solver bound pairs
This can cause headaches in multithreadedd environments.
Static variables should not be used to hold state, and the
accuracy becomes a state variable this way.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- "J.Pietschmann" <j3...@yahoo.de> wrote:
> Al Chou wrote:
> > Finally, having used the Pietschmann root finder framework, I think it
> needs
> > some modification to make it more user-friendly. As a lay user, I would
> have
> > been much happier dealing with Brent W.'s interface than Herr
> Pietschmann's,
> > which was kind of cumbersome. I think, though, with a little slimming
> down, it
> > would be quite workable.
>
> I'm interested in hearung a few more details: what makes the
> framework cumbersome? Admittedly I didn't have time yet to
> look at Brent's framework.
Having to instantiate an instance of the solver class seemed unnecessary.
Brent's approach was to make the solver class' constructor private so that you
simply call
RootFinding.bisection( f, a, b )
rather than do
RootFinding rootFinder = new RootFinding() ;
double root = rootFinder.bisection( f, a, b ) ;
That's a pretty easy change to make, although it prohibits the case of having
two solvers simultaneously with different accuracy requirements or suchlike.
You'd have to
RootFinding.setAccuracy() ;
between calls to different function/solver bound pairs, but I don't see our
users needing to solve two equations with different accuracy requirements
anytime soon.
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] proposed ordering for task list, scope of initial release
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: Phil Steitz [mailto:phil@steitz.com]
> Works like a champ ;-) I am having fun with these. I am thinking about
> publishing some critical value tables with the apache liscense. he he.
We'll definitely have to include those tables in the first edition of
"Jakarta Commons-Math, Unleashed."
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] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Brent Worden wrote:
>
>>-----Original Message-----
>>From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
>>Sent: Tuesday, June 10, 2003 3:06 PM
>>To: Jakarta Commons Developers List
>>Subject: Re: [math] proposed ordering for task list, scope of initial
>>release
>>
>>
>>Al Chou wrote:
>>
>>>Finally, having used the Pietschmann root finder framework, I
>>
>>think it needs
>>
>>>some modification to make it more user-friendly. As a lay
>>
>>user, I would have
>>
>>>been much happier dealing with Brent W.'s interface than Herr
>>
>>Pietschmann's,
>>
>>>which was kind of cumbersome. I think, though, with a little
>>
>>slimming down, it
>>
>>>would be quite workable.
>>
>>I'm interested in hearung a few more details: what makes the
>>framework cumbersome? Admittedly I didn't have time yet to
>>look at Brent's framework.
>>
>>J.Pietschmann
>>
>
>
> For clarification, I never meant for the bisection method to be the end-all
> for root finding. I just needed something to facilitate the distribution
> implementations.
Works like a champ ;-) I am having fun with these. I am thinking about
publishing some critical value tables with the apache liscense. he he.
> I would prefer using J's object approach to the static
> method any day, if for no reason then because of the inflexibility of static
> methods. They can't be overriden, they can't hold on to any state (a nice
> feature in J's work), they can't be subclassed, ..
This is an important point. Despite my recent advocacy for a small set
of static "util" methods, I strongly agree that we should never
implement complex algorithms in static methods and we should in general
avoid statics for the reasons that you give above.
.
>
> That being said, any design can be approved on (sorry J, even yours), but
> the flavor of the object approach is, IMO, more agreeable than the static
> method approach. It also is inline with the direction most of the library
> is beginning to take; complex algorithms encapsulated in strategy type
> objects which are interchangeable through a common interface.
>
I agree. It would be nice to get J's framework in and refactor your
Dist stuff to use it. I would be OK with just including Bisection and
Secant as initial implementations. Other implementations could be added
by us or users later.
Phil
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] proposed ordering for task list, scope of initial release
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: Tuesday, June 10, 2003 3:06 PM
> To: Jakarta Commons Developers List
> Subject: Re: [math] proposed ordering for task list, scope of initial
> release
>
>
> Al Chou wrote:
> > Finally, having used the Pietschmann root finder framework, I
> think it needs
> > some modification to make it more user-friendly. As a lay
> user, I would have
> > been much happier dealing with Brent W.'s interface than Herr
> Pietschmann's,
> > which was kind of cumbersome. I think, though, with a little
> slimming down, it
> > would be quite workable.
>
> I'm interested in hearung a few more details: what makes the
> framework cumbersome? Admittedly I didn't have time yet to
> look at Brent's framework.
>
> J.Pietschmann
>
For clarification, I never meant for the bisection method to be the end-all
for root finding. I just needed something to facilitate the distribution
implementations. I would prefer using J's object approach to the static
method any day, if for no reason then because of the inflexibility of static
methods. They can't be overriden, they can't hold on to any state (a nice
feature in J's work), they can't be subclassed, ...
That being said, any design can be approved on (sorry J, even yours), but
the flavor of the object approach is, IMO, more agreeable than the static
method approach. It also is inline with the direction most of the library
is beginning to take; complex algorithms encapsulated in strategy type
objects which are interchangeable through a common interface.
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] proposed ordering for task list, scope of initial release
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Al Chou wrote:
> Finally, having used the Pietschmann root finder framework, I think it needs
> some modification to make it more user-friendly. As a lay user, I would have
> been much happier dealing with Brent W.'s interface than Herr Pietschmann's,
> which was kind of cumbersome. I think, though, with a little slimming down, it
> would be quite workable.
I'm interested in hearung a few more details: what makes the
framework cumbersome? Admittedly I didn't have time yet to
look at Brent's framework.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by Phil Steitz <ph...@steitz.com>.
Al Chou wrote:
> --- Al Chou <ho...@yahoo.com> wrote:
>
>>--- Phil Steitz <st...@yahoo.com> wrote:
>>[deletia]
>>
>>>OK, long-winded disclaimer aside, here is how I see the task list ordered:
>>
> [deletia]
>
>>>* Framework and implementation strategie(s) for finding roots or
>>
>>real-valued
>>
>>>functions of one (real) variable. Here again -- largely done. I would
>>>prefer
>>>to wait until J gets back and let him submit his framework and R. Brent's
>>>algorithm. Then "our" Brent's implementation and usage can be integrated
>>>(actually not much to do, from the looks of the current code) and I will
>>
>>add
>>
>>>my "bean equations" stuff (in progress).
>>
>>I may have time to submit my Ridders' method implementation using J.'s
>>framework before he returns 2 days hence. Should I bother to try, or should
>>I
>>wait until he submits his code as a patch via Bugzilla?
>
>
> Well, I've just spent some time over the past 3 days reminding myself pf some
> of the things that are so hard about numerics.
>
> BTW, in the process of using Herr Pietschmann's root finder framework, I
> discovered a bug in setMaximalIterationCount (it sets
> defaultMaximalIterationCount instead of maximalIterationCount).
>
>
> So I pulled out Herr Pietschmann's Brent method class and tested it, and it
> threw an exception telling me, "Possibly multiple zeros in interval or ill
> conditioned function."
>
> The morals of the story are:
> - More-sophisticated algorithms that are supposed to converge faster don't
> always do so
> - It's easy to outsmart yourself and create code that's too finicky for
> non-numericist users.
Good thing to keep reminding ourselves.
>
> As someone said recently on the list, a typical user probably is more
> interested in an algorithm that's guaranteed to converge to a root (if there is
> one) than in the rate of convergence, as long as it's not too ridiculously
> slow. Given that we've repeatedly determined that commons-math is not to be a
> general numerical mathematics library, I think now that we should provide only
> a bisection method in the initial release (assuming we achieve one) and spend
> time later making our implementations of the more sophisticated algorithms more
> user-friendly, if we find they're even needed.
+1, but maybe adding Secant method (I think J included this as well, if
memory serves).
>
> Finally, having used the Pietschmann root finder framework, I think it needs
> some modification to make it more user-friendly. As a lay user, I would have
> been much happier dealing with Brent W.'s interface than Herr Pietschmann's,
> which was kind of cumbersome. I think, though, with a little slimming down, it
> would be quite workable.
>
We should let J comment on this. Also, the "bean equations" stuff that
I am working on will be *very* easy to use (though less sophisticated).
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Al Chou wrote:
> So I pulled out Herr Pietschmann's Brent method class and tested it, and it
> threw an exception telling me, "Possibly multiple zeros in interval or ill
> conditioned function."
Caused by an incomplete and much too naive implementation.
I have now a real implementation of Brent (Brent-Dekker)
ready and could try to submit a patch over the weekend.
> - It's easy to outsmart yourself and create code that's too finicky for
> non-numericist users.
Non-numericists (or whatever) tend to underestimate the
traps in numericals calculation because the vast majority
of the problems behave well with modern algorithms most
of the time. Unfortunately, unforseen misbehaviour tends
to come up at the worst possible time, often with the user
barely noticing that something was wrong.
In particular for root finding:
- The function for which a zero is sought could be implemented
badly, with excessive round-off error and/or bit-cancellation,
like naive evaluation of dense high order polynominals.
This may significantly displace the zero point, and it often
leads to multiple numerical roots where only one was
analytically expected.
- The function may be inherently or numerically ill conditioned,
like x*sin(1/x) near zero or ((x-1)^1000)*x^50 for a 50 bit
mantissa.
- It's hard to know in advance when to trade the performance
for robustnesss.
A criterium for root finders is how often the function is
evaluated, and it is generally assumed this is a expensive
compared to any calculation the solver could make.
This can make a difference between bisection, which gives a bit
per evaluation and needs ~53 iterations for an improvement of
10E-16 in accuracy, whether the function is well behaved or not,
and Newton, which ideally doubles the correct bits per evaluation
and needs ~5 iterations (evaluating of *two* functions) for a
10E-16 improvement.
Obviously, if accuracy matters and function evaluation is slow,
fast algorithms are hard to avoid but precisely defining the
necessary accuracy and telling what is "slow" can be time
consuming and hair-rising.
- Detailed knowledge about the function (and other aspects of the
problem) beats all kind of clever guesses by sophisitcated solving
engines all the time. Most algorithms are only really robust if
you can provide a bracket for the zero. For general functions,
this is as hard or harder than nailing down the root itself.
If you know the function has a smooth second derivative and
no zero in the first derivative in a certain interval (like x>1)
just use newton, if necessary with a numerical derivative, or
the secant method without bracketing and you'll get your root,
if it exists.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- Al Chou <ho...@yahoo.com> wrote:
> --- Phil Steitz <st...@yahoo.com> wrote:
> [deletia]
> > OK, long-winded disclaimer aside, here is how I see the task list ordered:
[deletia]
> > * Framework and implementation strategie(s) for finding roots or
> real-valued
> > functions of one (real) variable. Here again -- largely done. I would
> > prefer
> > to wait until J gets back and let him submit his framework and R. Brent's
> > algorithm. Then "our" Brent's implementation and usage can be integrated
> > (actually not much to do, from the looks of the current code) and I will
> add
> > my "bean equations" stuff (in progress).
>
> I may have time to submit my Ridders' method implementation using J.'s
> framework before he returns 2 days hence. Should I bother to try, or should
> I
> wait until he submits his code as a patch via Bugzilla?
Well, I've just spent some time over the past 3 days reminding myself pf some
of the things that are so hard about numerics.
I was testing my Ridders' method implementation and couldn't understand why it
took so many iterations to converge and still not be within the requested
accuracy of the known root I asked it to find. I used a simple quintic
(x+1)(x+0.5)(x)(x-0.5)(x-1) as the function whose roots I want to find, and I
made sure to give upper and lower bounds that I know bracket one and only one
root. When trying to find the roots at x = +- 0.5 my solver had no trouble
(though I didn't ask it how many of the 100 iterations it was allowed that it
actually used, until later), but the root at x = 0 was never within even a
factor of 15 of the requested 1e-6 accuracy even when allowed to take up to 200
iterations (actually, I used this test case first, which was what prompted me
to try the larger-valued roots in case I was seeing some loss of precision or
roundoff error effect).
BTW, in the process of using Herr Pietschmann's root finder framework, I
discovered a bug in setMaximalIterationCount (it sets
defaultMaximalIterationCount instead of maximalIterationCount).
I then decided to try Brent W.'s bisection solver, which converged to the
desired root to within its requested accuracy (1e-9) in 26 or 27 iterations
even for the root at x = 0. At this point I asked my Ridders' method how many
iterations it took to find x = 0.5, and it said 1, and I realized that was
probably because my bracket values were symmetric (or close enough) about the
root, so its midpoint evaluation of the function found the root by coincidence.
When I made sure the bracket values weren't symmetric about that root, I was
back to 146 iterations or more and not getting to within the requested accuracy
of the root location.
So I pulled out Herr Pietschmann's Brent method class and tested it, and it
threw an exception telling me, "Possibly multiple zeros in interval or ill
conditioned function."
The morals of the story are:
- More-sophisticated algorithms that are supposed to converge faster don't
always do so
- It's easy to outsmart yourself and create code that's too finicky for
non-numericist users.
As someone said recently on the list, a typical user probably is more
interested in an algorithm that's guaranteed to converge to a root (if there is
one) than in the rate of convergence, as long as it's not too ridiculously
slow. Given that we've repeatedly determined that commons-math is not to be a
general numerical mathematics library, I think now that we should provide only
a bisection method in the initial release (assuming we achieve one) and spend
time later making our implementations of the more sophisticated algorithms more
user-friendly, if we find they're even needed. I believe we've let ourselves
go down the path of as-yet-unjustified optimization in our designs, because we
know of algorithms that are supposed to be "better". I also have a greater,
first-hand, appreciation of the subtleties in NR's code to make it more robust
for the user, and I believe we can only achieve that level of robustness if we
take enough time -- which we should not prior to the initial release, because
that will be too much time.
Finally, having used the Pietschmann root finder framework, I think it needs
some modification to make it more user-friendly. As a lay user, I would have
been much happier dealing with Brent W.'s interface than Herr Pietschmann's,
which was kind of cumbersome. I think, though, with a little slimming down, it
would be quite workable.
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] proposed ordering for task list, scope of initial release
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <st...@yahoo.com> wrote:
[deletia]
> OK, long-winded disclaimer aside, here is how I see the task list ordered:
>
> * The RealMatrixImpl class is missing some key method implementations. The
> critical thing is solution of linear systems. We need to implement a
> numerically sound solution algorithm. This will enable inverse() and also
> support general linear regression. -- I think that Brent is working on this.
>
>
> * Improve numerical accuracy of Univariate and BivariateRegression
> statistical
> computations. Encapsulate basic double[] |-> double mean, variance, min, max
> computations using improved formulas and add these to MathUtils. (probably
> should add float[], int[], long[] versions as well.) Then refactor all
> univariate implementations that use stored values (including UnivariateImpl
> with finite window) to use the improved versions. -- Mark? I am chasing down
> the TAS reference to document the source of the _NR_ formula, which I will
> add
> to the docs if someone else does the implementation.
I was starting to code the updating (storage-less) variance formula, based on
the Stanford article you cited, as a patch. I believe the storage-using
corrected two-pass algorithm is pretty trivial to code once we feel we're on
solid ground with the reference to cite.
> * Define full package structure and develop user's guide following the
> package
> structure. I have started work on the user's guide, but found this
> impossible
> without the package structure defined. I will post a separate message
> summarizing what has been proposed up to now and making a recommendation.
>
> * t-test statistic needs to be added and we should probably add the
> capability
> of actually performing t- and chi-square tests at fixed significance levels
> (.1, .05, .01, .001). -- This is virtually done, just need to define a nice,
> convenient interface for doing one- and two-tailed tests. Thanks to Brent,
> we
> can actually support user-supplied significance levels (next item)
>
> * numerical approximation of the t- and chi-square distributions to enable
> user-supplied significance levels. See above. Someone just needs to put a
> fork in this. Tim? Brent?
>
> * *new* add support for F distribution and F test, so that we can report
> signinficance level of correlation coefficient in bivariate regression /
> signinficance of model. I will do this if no one else wants to.
>
> * Framework and implementation strategie(s) for finding roots or real-valued
> functions of one (real) variable. Here again -- largely done. I would
> prefer
> to wait until J gets back and let him submit his framework and R. Brent's
> algorithm. Then "our" Brent's implementation and usage can be integrated
> (actually not much to do, from the looks of the current code) and I will add
> my "bean equations" stuff (in progress).
I may have time to submit my Ridders' method implementation using J.'s
framework before he returns 2 days hence. Should I bother to try, or should I
wait until he submits his code as a patch via Bugzilla?
> * Extend distribution framework to support discrete distributions and
> implement
> binomial and hypergeometric distributions. I will do this if no one else
> wants
> to. If someone else does it, you should make sure to use the log binomials
> in
> computations.
>
> * Exponential growth and decay (set up for financial applications) I think
> this
> is just going to be a matter of finding the right formulas to add to
> MathUtils.
> I don't want to get carried away with financial computations, but some
> simple,
> commonly used formulas would be a nice addition to the package. We should
> also
> be thinking about other things to add to MathUtils -- religiously adhering to
> th guiding principles, of course. Al's sign() is an excellent example of the
> kind of thing that we should be adding, IMHO.
Thanks for the compliment! I think I finally understand what you mean with the
exponential stuff: compount interest calculation, for the most part, with
continuous compounding requiring the exponential.
> * Polynomial Interpolation -- let Al tell us what to do here. Even better,
> let Al do it (he he).
I actually did some research last night (I told myself I was going to bed
early, hah) on rational function interpolation, trying to find a primary source
for the algorithm rather than again rely on a secondary source in the form of
NR. I guess I'll continue along this path, as I really want a clean room
implementation of it for my own use. I'd feel better using rational functions
rather than polynomials for their generally larger radius of convergence.
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