[jira] [Updated] (MATH-928) Alternative approach to matrix implementations
[ https://issues.apache.org/jira/browse/MATH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-928: -- Fix Version/s: (was: 4.0) 4.X > 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.X > > 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.3.15#6346)
[jira] [Updated] (MATH-928) Alternative approach to matrix implementations
[ 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)
[jira] [Updated] (MATH-928) Alternative approach to matrix implementations
[ https://issues.apache.org/jira/browse/MATH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-928: Fix Version/s: 3.3 > 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: 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: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-928) Alternative approach to matrix implementations
[ https://issues.apache.org/jira/browse/MATH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-928: Attachment: basic_matrix.tar.gz > 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 > 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: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-928) Alternative approach to matrix implementations
[ https://issues.apache.org/jira/browse/MATH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-928: Attachment: (was: bm.tar.gz) > 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 > 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: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-928) Alternative approach to matrix implementations
[ https://issues.apache.org/jira/browse/MATH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-928: Summary: Alternative approach to matrix implementations (was: Alternative approach to matrix implemenations) > 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 > 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
