[jira] [Updated] (MATH-928) Alternative approach to matrix implemenations

["Gilles (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MATH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gilles updated MATH-928:
------------------------

    Attachment: bm.tar.gz

Here are the files.
There are several interfaces and one concrete implementation ("SimpleDenseMatrix").
"BasicMatrixUtils" is an example of how functionality could be transparently provided to applications.

                
> Alternative approach to matrix implemenations
> ---------------------------------------------
>
>                 Key: MATH-928
>                 URL: https://issues.apache.org/jira/browse/MATH-928
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Priority: Minor
>              Labels: api
>         Attachments: bm.tar.gz
>
>
> Old and recent discussions on the "dev" ML bought different, and incompatible, viewpoints on how to provide matrix and linear algebra features in Commons Math.
> Problems with the current API have been summarized in MATH-765.
> Those sometimes contributes to putting the CM matrix implementations into the category of "bloated" code (too many methods that rebuff would-be contributors from creating new subclasses that only need specific functionality).
> It also poses the question of "purpose": Which implementations are good for a given usage? Or which should be avoided.
> The Commons Math's development model assumes that the implementations were created to answer some specific need of the contributor(s). But eventually, the limitations of the ad-hoc implementations (often) do not make it to the description (Javadoc, user guide, unit test, use cases); and the new tool just becomes an additional "low-level" components of the library.
> Such building blocks are then reused (as a black box) in another context, e.g. another par of the library (which is a good thing), sometimes with unforeseen (and not so good) consequences (cf. MATH-924).
> It seems that Commons Math could either provide more building blocks (to try and cover use cases that need different features), or "restrict" usage of the classes that were maybe primarily developed for a specific usage.
> As I hinted above, the former might be rendered more difficult by imposing a relatively complex interface.
> In this issue, I attempted to explore an alternative approach (which was briefly mentioned more than a year ago, IIRC) by which matrix functionality would be built up by mixing and matching simple (and more or less independent) components.
> As an example, I've implemented a new matrix class with a focus on immutability. Certain uses might benefit from such a feature, while for others, this will be drawback.
> However, my hope would be that "elementary" building blocks could lend themselves to "combinations" by which some algorithm would convert between the various matrix implementations so as to use to most appropriate for a given sequence of operations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira