There is a lot to like in the WalkInOrder* set of methods. However, it is
also very constricting. What if I want to set a whole row with a
Arrays.copyTo() call? Also, the interface is a push interface. Data is
pushed to the delegate. This is very troublesome to me. I might need random
access to the whole storage space. I suppose you could solve this by
stashing a copy of the data in your RealMatrixPreservingVisitor
implementation. That seems clunky and likely to cause very obtuse coding. If
you are changing the data rapidly, you will need to constantly update your
cached matrix data.
On Wed, Aug 24, 2011 at 10:44 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
> On 8/24/11 7:27 PM, Greg Sterijevski wrote:
> > 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.
>
> Or decide that the visitor stuff that Sebastien pointed out above
> provides the functionality and do nothing. If we don't like the
> names of the walk* methods we can talk about changing them, but the
> setup is flexible and powerful and pretty much does what you are
> describing in the MatrixModifier already. I think what Gilles was
> looking for was a shorthand for a common use case, which I
> personally see as no big deal and OK to add. The more general
> machinery is there for more general uses.
>
> Phil
> >>
> >>
> >> Regards,
> >> Gilles
> >>
> >>> [...]
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
