[
https://issues.apache.org/jira/browse/MATH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-928:
------------------------
Fix Version/s: (was: 3.3)
4.0
> Alternative approach to matrix implementations
> ----------------------------------------------
>
> 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
> Fix For: 4.0
>
> Attachments: basic_matrix.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 was sent by Atlassian JIRA
(v6.1.5#6160)
