commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Created] (MATH-928) Alternative approach to matrix implemenations
Date Sat, 12 Jan 2013 16:02:12 GMT
Gilles created MATH-928:

             Summary: Alternative approach to matrix implemenations
                 Key: MATH-928
             Project: Commons Math
          Issue Type: New Feature
            Reporter: Gilles
            Priority: Minor

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
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:

View raw message