commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Updated] (MATH-928) Alternative approach to matrix implementations
Date Sat, 24 Aug 2013 17:53:53 GMT


Gilles updated MATH-928:

    Fix Version/s: 3.3
> Alternative approach to matrix implementations
> ----------------------------------------------
>                 Key: MATH-928
>                 URL:
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Priority: Minor
>              Labels: api
>             Fix For: 3.3
>         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 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