 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
93 messages in org.apache.commons.devRe: [math] Re: commons-math, matrix-t...| From | Sent On | Attachments |
|---|---|---|
| Sam Halliday | May 14, 2009 3:17 am | |
| Ted Dunning | May 14, 2009 11:17 am | |
| Luc Maisonobe | May 14, 2009 12:08 pm | |
| Ted Dunning | May 14, 2009 12:12 pm | |
| Luc Maisonobe | May 14, 2009 12:46 pm | |
| Sam Halliday | May 14, 2009 1:54 pm | |
| Ted Dunning | May 14, 2009 3:12 pm | |
| Phil Steitz | May 15, 2009 6:22 pm | |
| Ted Dunning | May 15, 2009 6:41 pm | |
| Phil Steitz | May 15, 2009 7:19 pm | |
| Luc Maisonobe | May 16, 2009 1:37 am | |
| Sam Halliday | May 16, 2009 7:21 am | |
| Sam Halliday | May 16, 2009 7:40 am | |
| Sam Halliday | May 16, 2009 7:44 am | |
| Sam Halliday | May 16, 2009 7:56 am | |
| Sam Halliday | May 16, 2009 8:14 am | |
| Luc Maisonobe | May 16, 2009 8:43 am | |
| Phil Steitz | May 16, 2009 8:55 am | |
| Sam Halliday | May 16, 2009 9:25 am | |
| Sam Halliday | May 16, 2009 9:30 am | |
| Luc Maisonobe | May 16, 2009 9:40 am | |
| Luc Maisonobe | May 16, 2009 9:43 am | |
| Sam Halliday | May 16, 2009 9:48 am | |
| Sam Halliday | May 16, 2009 9:52 am | |
| Sam Halliday | May 16, 2009 10:07 am | |
| Luc Maisonobe | May 16, 2009 10:09 am | |
| Luc Maisonobe | May 16, 2009 10:13 am | |
| Luc Maisonobe | May 16, 2009 10:26 am | |
| Sam Halliday | May 16, 2009 10:39 am | |
| Luc Maisonobe | May 16, 2009 10:57 am | |
| Sam Halliday | May 16, 2009 11:11 am | |
| Ted Dunning | May 16, 2009 1:01 pm | |
| Ted Dunning | May 16, 2009 1:03 pm | |
| Bill Barker | May 16, 2009 3:49 pm | |
| Luc Maisonobe | May 17, 2009 1:12 am | |
| Phil Steitz | May 17, 2009 8:07 am | |
| Phil Steitz | May 17, 2009 8:14 am | |
| Phil Steitz | May 17, 2009 8:34 am | |
| Phil Steitz | May 17, 2009 8:56 am | |
| Luc Maisonobe | May 17, 2009 9:06 am | |
| Phil Steitz | May 17, 2009 5:13 pm | |
| Sam Halliday | May 18, 2009 4:28 am | |
| Bill Barker | May 18, 2009 8:13 pm | |
| Sam Halliday | May 19, 2009 1:26 am | |
| Jin Mingjian | May 19, 2009 2:59 am | |
| Ted Dunning | May 19, 2009 11:17 am | |
| Phil Steitz | May 20, 2009 11:05 am | |
| Bill Barker | May 20, 2009 6:52 pm | |
| Sam Halliday | May 21, 2009 3:13 am | |
| Luc Maisonobe | May 21, 2009 5:18 am | |
| sebb | May 21, 2009 5:46 am | |
| Luc Maisonobe | May 21, 2009 6:03 am | |
| sebb | May 21, 2009 7:09 am | |
| Sam Halliday | May 21, 2009 8:31 am | |
| Sam Halliday | May 21, 2009 8:34 am | |
| James Carman | May 21, 2009 8:35 am | |
| Sam Halliday | May 21, 2009 8:42 am | |
| Luc Maisonobe | May 21, 2009 8:44 am | |
| Luc Maisonobe | May 21, 2009 9:03 am | |
| Sam Halliday | May 21, 2009 10:08 am | |
| Sam Halliday | May 21, 2009 10:13 am | |
| Ted Dunning | May 21, 2009 12:08 pm | |
| John Bollinger | May 21, 2009 1:53 pm | |
| Edward J. Yoon | May 21, 2009 7:14 pm | |
| Bill Barker | May 21, 2009 8:19 pm | |
| Ted Dunning | May 21, 2009 8:52 pm | |
| Sam Halliday | May 22, 2009 1:18 am | |
| Luc Maisonobe | May 22, 2009 1:25 am | |
| Phil Steitz | May 22, 2009 3:22 am | |
| Sam Halliday | May 22, 2009 3:37 am | |
| Luc Maisonobe | May 22, 2009 4:05 am | |
| sebb | May 22, 2009 4:13 am | |
| Luc Maisonobe | May 22, 2009 4:19 am | |
| Luc Maisonobe | May 22, 2009 4:21 am | |
| sebb | May 22, 2009 4:36 am | |
| Luc Maisonobe | May 22, 2009 6:11 am | |
| Luc Maisonobe | May 22, 2009 6:14 am | |
| Edward J. Yoon | May 22, 2009 10:13 am | |
| Ted Dunning | May 22, 2009 11:16 am | |
| Bill Barker | May 23, 2009 12:11 am | |
| Edward J. Yoon | May 23, 2009 1:22 am | |
| Jin Mingjian | May 23, 2009 6:28 am | |
| Ted Dunning | May 23, 2009 10:32 am | |
| Bill Barker | May 24, 2009 6:10 pm | |
| Ted Dunning | May 24, 2009 11:46 pm | |
| Luc Maisonobe | May 25, 2009 12:38 pm | |
| Bill Barker | May 25, 2009 2:22 pm | |
| Bill Barker | May 25, 2009 4:32 pm | |
| Ted Dunning | May 25, 2009 4:51 pm | |
| Bill Barker | May 25, 2009 6:21 pm | |
| Sam Halliday | May 28, 2009 10:19 am | |
| Sam Halliday | May 28, 2009 12:00 pm | |
| Phil Steitz | May 30, 2009 10:46 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [math] Re: commons-math, matrix-toolkits-java and consolidation | Actions |
|---|---|---|
| From: | Phil Steitz (phil...@gmail.com) | |
| Date: | May 17, 2009 8:56:09 am | |
| List: | org.apache.commons.dev | |
Luc Maisonobe wrote:
Sam Halliday a écrit :
I've had a quick look at the 2.0 API and the only changes I'd like to request are:-
- create interfaces RealSparse{Matrix, Vector} to indicate a sparse storage implementation. Can be empty (for now).
I suppose these interfaces would extend Real{Matrix, Vector} ?
- rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}. Implement above interfaces.
I have no opinion on that. What do others think ?
+1 for "dethroning" ;)
With the new interfaces, we could also drop the "Sparse" from the name - i.e, "OpenMapRealMatrix"
I am wondering now whether similar marking and "dethroning" should happen on the dense side - i.e DenseReal{Matrix, Vector}, BlockRealMatrix (currently DenseRealMatrix), ArrayRealMatrix (currently RealMatrixImpl)?
- implementations should subclass the return type of some methods in the Real{Matrix, Vector} API. e.g. RealVectorImpl.copy() returns a RealVector, but could declare that it returns a RealVectorImpl. This will avoid needless user casts. In future APIs, this could be a powerful way to define the return type of matrix-matrix computation when the storage classes are known... e.g. declaring that you return a DiagonalMatrix.
I didn't know changing the return type to a subtype was allowed when implementing an interface! This is for sure a good thing to do and could probably be used in many other places too.
+1 in general, but need to realize that when implemented, this changes locks us in. In the specific cases mentioned above, this is a no-brainer, but there are others (mostly in the decomp classes) where it is not so obvious.
- is it too late to define a Norm enum and take that as a parameter, rather than explicit methods for each Norm type?
There are many places where we use the same pattern outside of linear algebra. I'm reluctant to change this because if we extend the enum later, we may forget to add a new case in all implementations (somewhere in a switch statement), so we should add an exception for defensive programming. A method name enforced in an interface prevent such errors, you cannot compile your implementation if you forget a method.
Agree with Luc on this, but more from a Java style than maintenance standpoint. We have tried in general to stay away from "behavior flags" in method signatures up to now.
Phil