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
