You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2003/10/21 22:51:41 UTC
[math] Isn't it about time?
I just want to PING the group again for some status.
How close does everyone think we are to a release?
Maybe its getting time for a Vote?
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Isn't it about time?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Brent Worden wrote:
> I am of the opinion that everything we've been discussing should be held
> over to the next release.
No problem. The Decomposer could be added without incompatible changes
itself, the only problem would be that in order to take full advantage,
RealMatrix will have to be changed into an interface and a bunch of
GeneralRealMatrix, TridiagonalRealMatrix, SymmetricRealMatrix and so
on have to be added (only the first for a start).
I'll try to get another shot at completing the documentation next week.
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] Isn't it about time?
Posted by Brent Worden <br...@worden.org>.
>
> Pietschman,
>
> I like your Decomposer API idea too. I think this is something we can
> consider as having commonalities with what I've been in discussion with
> Paul about equation solvers for integration etc. I think there's some
> room for common api's in both these cases. Do you?
The decomposition API looks quite solid and well thought out.
>
> -Mark
>
> p.s. I still think we will want to make decisions concerning see this
> stuff in this release vs the next release. I'm sure there are pros and
> cons to going in either direction. But, I think it important we try to
> get a release up of what we've accomplished so far, before moving too
> far forward.
>
I am of the opinion that everything we've been discussing should be held
over to the next release. The functionality currently implemented by
commons-math goes far beyond what was envisioned in the project proposal.
Before going to much further, I would like to receive some user opinions
about the current API to help drive us for future functionality and
enhancements. Also, since I'm not known to be humble, it would be nice to
be rewarded with a release after all of our hard work.
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] Isn't it about time?
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Pietschman,
I like your Decomposer API idea too. I think this is something we can
consider as having commonalities with what I've been in discussion with
Paul about equation solvers for integration etc. I think there's some
room for common api's in both these cases. Do you?
-Mark
p.s. I still think we will want to make decisions concerning see this
stuff in this release vs the next release. I'm sure there are pros and
cons to going in either direction. But, I think it important we try to
get a release up of what we've accomplished so far, before moving too
far forward.
J.Pietschmann wrote:
> Mark R. Diggory wrote:
>
>> How close does everyone think we are to a release?
>>
>> Maybe its getting time for a Vote?
>
>
> Most of the stoppers have been sorted out. Open issues
> - a Complex class
> - providing more flexibile framework for solving linear
> equation systems.
>
> I think of RealMatrix as Data holder only, and providing
> a decomposer class with an associated factory, a decomposition
> class holding the decomposition and providing the backward
> pass of the solving algorithms.
> Like
> class RealMatrix {
> // get a matrix specific decomposer factory
> DecompositionFactory getDecompositionFactory();
> }
>
> class DecompositionFactory {
> // get overall default factory
> static newInstance();
>
> // construct a new default decomposer
> Decomposer newDecomposer();
>
> // example for a specific decomposer (Householder or QR)
> Decomposer newQRDecopmposer();
> }
>
> Decomposer {
> Decomposition decompose(RealMatrix);
> }
>
> Decomposition {
> // solve A*x=b
> RealVector solve(RealVector b);
>
> // solve matrix equation
> RealMatrix solve(RealMatrix b);
>
> RealMatrix invert();
> }
>
> This way it would be possible to
> a) take advantage of special matrix forms, like symmetric
> or tridiagonal matrices, thereby using simple and more
> stable methods
> b) use different solvers in case one solver proves to be
> unsatisfactory (like QR or even SVD instead of the standard LR
> decomposition, or post-iterations)
> c) reuse the decomposition for solvong multiple systems with
> differend right hand sides
> The decomposition objects could provide for an error estimate, if
> available for this decomposition.
>
> Any comments regarding numerical integration methods?
> Minimizing functions?
>Optimization (linear and non-linear programming)?
>
> Regards
> J.Pietschmann
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Isn't it about time?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Mark R. Diggory wrote:
> How close does everyone think we are to a release?
>
> Maybe its getting time for a Vote?
Most of the stoppers have been sorted out. Open issues
- a Complex class
- providing more flexibile framework for solving linear
equation systems.
I think of RealMatrix as Data holder only, and providing
a decomposer class with an associated factory, a decomposition
class holding the decomposition and providing the backward
pass of the solving algorithms.
Like
class RealMatrix {
// get a matrix specific decomposer factory
DecompositionFactory getDecompositionFactory();
}
class DecompositionFactory {
// get overall default factory
static newInstance();
// construct a new default decomposer
Decomposer newDecomposer();
// example for a specific decomposer (Householder or QR)
Decomposer newQRDecopmposer();
}
Decomposer {
Decomposition decompose(RealMatrix);
}
Decomposition {
// solve A*x=b
RealVector solve(RealVector b);
// solve matrix equation
RealMatrix solve(RealMatrix b);
RealMatrix invert();
}
This way it would be possible to
a) take advantage of special matrix forms, like symmetric
or tridiagonal matrices, thereby using simple and more
stable methods
b) use different solvers in case one solver proves to be
unsatisfactory (like QR or even SVD instead of the standard LR
decomposition, or post-iterations)
c) reuse the decomposition for solvong multiple systems with
differend right hand sides
The decomposition objects could provide for an error estimate, if
available for this decomposition.
Any comments regarding numerical integration methods? Minimizing
functions? Optimization (linear and non-linear programming)?
Regards
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org