Before we fill JIRA with a bunch of point-counterpoint comments. Perhaps we
can organize our ideas on the list first?
Using Gille's organization:
* Consistency in naming and make explicit the rationale for choosing one or
another naming scheme
What methods are inconsistently named? Name the method and give the new
suggested name, and why its an improvement.
* Consistency of operations (and naming) between "RealVector" and
"RealMatrix"
Which methods? Why?
* Which methods should be added
I would vote to minimize the introduction of new methods. I like the
paradigm of having a general set( * ) function where * is a delegate which
takes the double[][] array which has the matrix or vector's data.
* Which methods should be removed
I will keep quiet here except to say, "Excise with a machete!" Perhaps
methods which are not called internally by commons might be candidates for
excision.
* What API to adopt to let user "create" entry-changing functions
I would argue an interface along the lines of:
public interface MatrixModifier{
public void updateData( double[][] memberData );
}
On Wed, Aug 24, 2011 at 4:54 AM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> Hi.
>
> On Wed, Aug 24, 2011 at 02:12:33AM +0200, Sébastien Brisard wrote:
> > I think this is already implemented as
> > walkInXXXOrder(RealMatrixChangingVisitor). I thought it would be handy
> > (and consistent with RealVector) to have this very method, but it's
> > true a RealMatrixChangingVisitorFactory would do very nicely.
> > Sébastien
>
> This discussion should really be connected to issue
> https://issues.apache.org/jira/browse/MATH-643
> and to the recent thread with subject:
> New method: "addToEntry" in "RealVector"
> and to the thread started some time ago by Greg about simplifying the
> "RealMatrix" interface.
>
> There are several points:
> * Consistency in naming and make explicit the rationale for choosing one
> or
> another naming scheme
> * Consistency of operations (and naming) between "RealVector" and
> "RealMatrix"
> * Which methods should be added
> * Which methods should be removed
> * What API to adopt to let user "create" entry-changing functions
>
> I'd suggest to create a JIRA ticket that would include a general overview
> of
> all those related changes.
>
>
> Regards,
> Gilles
>
> > [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
