You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sujit Pal (JIRA)" <ji...@apache.org> on 2008/12/03 22:19:44 UTC
[jira] Created: (MATH-231) User-extendable Abstract RealMatrix
implementation
User-extendable Abstract RealMatrix implementation
--------------------------------------------------
Key: MATH-231
URL: https://issues.apache.org/jira/browse/MATH-231
Project: Commons Math
Issue Type: New Feature
Affects Versions: 2.1
Environment: Any
Reporter: Sujit Pal
Priority: Minor
Many algorithms are described using Matrices. In some situations, the Matrices for applications are too large to fit into memory, so it makes sense to use custom implementations that are backed by a sparse map or list, or backed by Lucene indexes or database tables, etc. This allows the algorithm implementations (in the application) to be clean and mimic the algorithm itself, making it easy to understand and debug.
However, the only way to make a custom implementation currently is to implement RealMatrix, and to implement all its methods, or to extend and override methods in RealMatrixImpl. The former involves a knowledge of matrix operations, which is not guaranteed for people who are business programmers (which may be the reason they are using commons-math in the first place). The latter involves looking at the existing code and making the overrides where needed, again something that is not expected from a commons-math user. A simpler way would be to have something generic mostly built, except the getEntry() and setEntry() methods which would be declared abstract and hence meant to be overriden, and all the other methods to be pre-built based on getEntry() and setEntry().
This would make the creation of custom matrices very flexible, and would also remove the burden of providing "common matrix impls" from the commons-math project, since clients can very simply create custom versions of their own.
I suggest the following:
<<RealMatrix.java>> <-- RealMatrixImpl
<-- (AbstractRealMatrixImpl)
The SparseRealMatrixImpl I contributed in MATH-230 could be a user-defined custom subclass of AbstractRealMatrixImpl and not have to belong to the commons-math project at all. Or it could be included as an example if there is enough need.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-231) User-extendable Abstract RealMatrix
implementation
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luc Maisonobe updated MATH-231:
-------------------------------
Affects Version/s: (was: 2.1)
2.0
Fix Version/s: 2.0
> User-extendable Abstract RealMatrix implementation
> --------------------------------------------------
>
> Key: MATH-231
> URL: https://issues.apache.org/jira/browse/MATH-231
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 2.0
> Environment: Any
> Reporter: Sujit Pal
> Assignee: Luc Maisonobe
> Priority: Minor
> Fix For: 2.0
>
>
> Many algorithms are described using Matrices. In some situations, the Matrices for applications are too large to fit into memory, so it makes sense to use custom implementations that are backed by a sparse map or list, or backed by Lucene indexes or database tables, etc. This allows the algorithm implementations (in the application) to be clean and mimic the algorithm itself, making it easy to understand and debug.
> However, the only way to make a custom implementation currently is to implement RealMatrix, and to implement all its methods, or to extend and override methods in RealMatrixImpl. The former involves a knowledge of matrix operations, which is not guaranteed for people who are business programmers (which may be the reason they are using commons-math in the first place). The latter involves looking at the existing code and making the overrides where needed, again something that is not expected from a commons-math user. A simpler way would be to have something generic mostly built, except the getEntry() and setEntry() methods which would be declared abstract and hence meant to be overriden, and all the other methods to be pre-built based on getEntry() and setEntry().
> This would make the creation of custom matrices very flexible, and would also remove the burden of providing "common matrix impls" from the commons-math project, since clients can very simply create custom versions of their own.
> I suggest the following:
> <<RealMatrix.java>> <-- RealMatrixImpl
> <-- (AbstractRealMatrixImpl)
> The SparseRealMatrixImpl I contributed in MATH-230 could be a user-defined custom subclass of AbstractRealMatrixImpl and not have to belong to the commons-math project at all. Or it could be included as an example if there is enough need.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-231) User-extendable Abstract RealMatrix
implementation
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luc Maisonobe resolved MATH-231.
--------------------------------
Resolution: Fixed
fixed in trunk as of r724141
> User-extendable Abstract RealMatrix implementation
> --------------------------------------------------
>
> Key: MATH-231
> URL: https://issues.apache.org/jira/browse/MATH-231
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 2.0
> Environment: Any
> Reporter: Sujit Pal
> Assignee: Luc Maisonobe
> Priority: Minor
> Fix For: 2.0
>
>
> Many algorithms are described using Matrices. In some situations, the Matrices for applications are too large to fit into memory, so it makes sense to use custom implementations that are backed by a sparse map or list, or backed by Lucene indexes or database tables, etc. This allows the algorithm implementations (in the application) to be clean and mimic the algorithm itself, making it easy to understand and debug.
> However, the only way to make a custom implementation currently is to implement RealMatrix, and to implement all its methods, or to extend and override methods in RealMatrixImpl. The former involves a knowledge of matrix operations, which is not guaranteed for people who are business programmers (which may be the reason they are using commons-math in the first place). The latter involves looking at the existing code and making the overrides where needed, again something that is not expected from a commons-math user. A simpler way would be to have something generic mostly built, except the getEntry() and setEntry() methods which would be declared abstract and hence meant to be overriden, and all the other methods to be pre-built based on getEntry() and setEntry().
> This would make the creation of custom matrices very flexible, and would also remove the burden of providing "common matrix impls" from the commons-math project, since clients can very simply create custom versions of their own.
> I suggest the following:
> <<RealMatrix.java>> <-- RealMatrixImpl
> <-- (AbstractRealMatrixImpl)
> The SparseRealMatrixImpl I contributed in MATH-230 could be a user-defined custom subclass of AbstractRealMatrixImpl and not have to belong to the commons-math project at all. Or it could be included as an example if there is enough need.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.