Mahout
  1. Mahout
  2. MAHOUT-790

Redundancy in Matrix API, view or get?

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: 0.6
    • Component/s: None
    • Labels:
      None

      Description

      We have a bunch of redundant methods in our matrix interface. These include things that return views of parts of the matrix:

        Matrix viewPart(int[] offset, int[] size);
        Matrix viewPart(int rowOffset, int rowsRequested, int columnOffset, int columnsRequested);
        Vector viewRow(int row);
        Vector viewColumn(int column);
      

      and things that do the same but call refer to getting stuff

        Vector getColumn(int column);
        Vector getRow(int row);
        double getQuick(int row, int column);
        int[] getNumNondefaultElements();
        Map<String, Integer> getColumnLabelBindings();
        Map<String, Integer> getRowLabelBindings();
        double get(String rowLabel, String columnLabel);
      

      To my mind, get implies a get-by-value whereas view implies get-by-reference. As such, I would suggest that getColumn and getRow should disappear. On the other hand, getQuick and get are both correctly named.

      This raises the question of what getNumNondefaultElements really does. I certainly can't tell just from the signature. Is it too confusing to keep?

      Additionally, what do people think that getColumnLabelBindings and getRowLabelBindings return? A mutable map? Or an immutable one?

      Under the covers, viewRow and viewColumn (and the upcoming viewDiagonal) have default implementations that use MatrixVectorView, but AbstractMatrix doesn't have an implementation for getRow and getColumn.

      In sum, I suggest that:

      • getRow and getColumn go away
      • the fancy fast implementations fo getRow and getColumn that exist be migrated to be over-rides of viewRow and viewColumn
      • there be a constructor for AbstractMatrix that sets the internal size things correctly.
      • that the internal cardinality array in AbstractMatrix goes away to be replaced by two integers.
      • viewDiagonal() and viewDiagonal(length) and viewDiagonal(row, column) and viewDiagonal(int row, column, length) be added.

      I will produce a patch shortly.

      1. MAHOUT-790.patch
        197 kB
        Ted Dunning

        Issue Links

          Activity

          Hide
          Lance Norskog added a comment - - edited

          Cardinality array: definitely- it is mutable from outside.
          final int row;
          final int column;

          viewColumn v.s. getColumn: the question here is deep v.s. shallow copy?
          I would go with
          getColumn(int column) and getColumn(int column, Vector v)
          where getColumn(int column) is assumed to give a shallow copy.

          Diagonals: are they really needed now? Should there be triangular or symmetric? They have enough of their own behavior to be a separate subclass rather than some magic thing held by the main class. Example: DiagonalMatrix.invert() is a valid method, because it either blows up if there is a 0 value, or returns 1/values.

          getNumNondefault: this requires being able to produce the number, which is a "design load". It is not used much in "real code". I suspect most of those users could track/deduce the number in some other way, rather than expect the object to remember it.

          Show
          Lance Norskog added a comment - - edited Cardinality array: definitely- it is mutable from outside. final int row; final int column; viewColumn v.s. getColumn: the question here is deep v.s. shallow copy? I would go with getColumn(int column) and getColumn(int column, Vector v) where getColumn(int column) is assumed to give a shallow copy. Diagonals: are they really needed now? Should there be triangular or symmetric? They have enough of their own behavior to be a separate subclass rather than some magic thing held by the main class. Example: DiagonalMatrix.invert() is a valid method, because it either blows up if there is a 0 value, or returns 1/values. getNumNondefault: this requires being able to produce the number, which is a "design load". It is not used much in "real code". I suspect most of those users could track/deduce the number in some other way, rather than expect the object to remember it.
          Hide
          Ted Dunning added a comment -

          viewColumn v.s. getColumn: the question here is deep v.s. shallow copy?
          I would go with
          getColumn(int column) and getColumn(int column, Vector v)
          where getColumn(int column) is assumed to give a shallow copy.

          Neither of these produce a copy. Both return references. Your reaction is similar to mine that get implies a copy. I don't plan to add code to create a copy so I plan to just reduce current function to a single entry point.

          Show
          Ted Dunning added a comment - viewColumn v.s. getColumn: the question here is deep v.s. shallow copy? I would go with getColumn(int column) and getColumn(int column, Vector v) where getColumn(int column) is assumed to give a shallow copy. Neither of these produce a copy. Both return references. Your reaction is similar to mine that get implies a copy. I don't plan to add code to create a copy so I plan to just reduce current function to a single entry point.
          Hide
          Ted Dunning added a comment -

          Diagonals: are they really needed now?

          It really helps some algorithms to be able to pull the primary diagonal of a matrix out as a vector. So yes, that is needed.

          Regarding a DiagonalMatrix, I do have a need for that as well and will include that in the SSVD patch. Since that is a pure addition, I don't think it needs the same level of discussion.

          Should there be triangular or symmetric? They have enough of their own behavior to be a separate subclass rather than some magic thing held by the main class.

          Possibly. So far, this isn't a big deal although I do have a triangular solver in my CholeskyDecomposition. If we see some more uses, it might be worth pulling out as a separate class.

          I don't see that a SymmetricMatrix is an important thing yet. Yes, there are important mathematical properties there, but these aren't necessarily something worth reflecting in the type structure. Good use cases would change my mind.

          Example: DiagonalMatrix.invert() is a valid method, because it either blows up if there is a 0 value, or returns 1/values.

          I prefer solve methods rather than invert methods. It is already much too hard to cure people of trying to invert matrices. Introducing an invert method anywhere would just make that harder.

          Show
          Ted Dunning added a comment - Diagonals: are they really needed now? It really helps some algorithms to be able to pull the primary diagonal of a matrix out as a vector. So yes, that is needed. Regarding a DiagonalMatrix, I do have a need for that as well and will include that in the SSVD patch. Since that is a pure addition, I don't think it needs the same level of discussion. Should there be triangular or symmetric? They have enough of their own behavior to be a separate subclass rather than some magic thing held by the main class. Possibly. So far, this isn't a big deal although I do have a triangular solver in my CholeskyDecomposition. If we see some more uses, it might be worth pulling out as a separate class. I don't see that a SymmetricMatrix is an important thing yet. Yes, there are important mathematical properties there, but these aren't necessarily something worth reflecting in the type structure. Good use cases would change my mind. Example: DiagonalMatrix.invert() is a valid method, because it either blows up if there is a 0 value, or returns 1/values. I prefer solve methods rather than invert methods. It is already much too hard to cure people of trying to invert matrices. Introducing an invert method anywhere would just make that harder.
          Hide
          Sean Owen added a comment -

          I think that all sounds great!

          Show
          Sean Owen added a comment - I think that all sounds great!
          Hide
          Ted Dunning added a comment -

          So the getRow/getColumn vs viewRow/viewColumn merge exercise is turning out good. I have found a number of bugs that relate to the confusion between whether getRow returned a copy or not.

          But I am also finding that getRow is much more popular than viewRow. My tendency is to still change the name to make clear that the result is a view.

          Any thoughts?

          Show
          Ted Dunning added a comment - So the getRow/getColumn vs viewRow/viewColumn merge exercise is turning out good. I have found a number of bugs that relate to the confusion between whether getRow returned a copy or not. But I am also finding that getRow is much more popular than viewRow. My tendency is to still change the name to make clear that the result is a view. Any thoughts?
          Hide
          Ted Dunning added a comment -

          I have also found a number of instances where from.addTo(to) is used instead of to.assign(from, Functions.PLUS). I am changing these usages to the latter form and removing addTo as redundant?

          Any comment on that change?

          Show
          Ted Dunning added a comment - I have also found a number of instances where from.addTo(to) is used instead of to.assign(from, Functions.PLUS). I am changing these usages to the latter form and removing addTo as redundant? Any comment on that change?
          Hide
          Ted Dunning added a comment -

          I have also found an odd function called slice(int). It seems to be used variously to describe a column or row view. This non-specificity seems disastrous to me so I am deleting that function and replacing it with viewRow.

          Can somebody say what this is for?

          Jake? Were you involved with this? It seems to appear in the distributed row matrix stuff a fair bit.

          Show
          Ted Dunning added a comment - I have also found an odd function called slice(int). It seems to be used variously to describe a column or row view. This non-specificity seems disastrous to me so I am deleting that function and replacing it with viewRow. Can somebody say what this is for? Jake? Were you involved with this? It seems to appear in the distributed row matrix stuff a fair bit.
          Hide
          Ted Dunning added a comment -

          Here is a monster patch that cleans up the matrix classes as suggested. The remaining nit is the iterator in SparseColumnMatrix.

          Show
          Ted Dunning added a comment - Here is a monster patch that cleans up the matrix classes as suggested. The remaining nit is the iterator in SparseColumnMatrix.
          Hide
          Ted Dunning added a comment -

          This build should fail for now. The fix will be forth coming.

          Show
          Ted Dunning added a comment - This build should fail for now. The fix will be forth coming.
          Hide
          Lance Norskog added a comment -

          It really helps some algorithms to be able to pull the primary diagonal of a matrix out as a vector. So yes, that is needed.

          This sounds like a utility method? The different Matrix data structures may want to have different implementations of viewing it; I can see a disastrous clash between a 'sequential' Matrix and pulling diagonals in one go. It may be one of those cases where each use of this is somewhat customized, and the surrounding code knows the matrix implementation. That is, an algorithm for sequential matrices is carefully coded around this fact, and so how it uses a diagonal will also have this profile.
          So, static utility method and "you know the problem space" are the two uses for this?

          I go on about this because I tried to make a generic read-only Matrix and Vector, and then random sub-classes of those. This exercise showed the design tensions so I'm now wary of adding more features which subclasses must consider.

          Show
          Lance Norskog added a comment - It really helps some algorithms to be able to pull the primary diagonal of a matrix out as a vector. So yes, that is needed. This sounds like a utility method? The different Matrix data structures may want to have different implementations of viewing it; I can see a disastrous clash between a 'sequential' Matrix and pulling diagonals in one go. It may be one of those cases where each use of this is somewhat customized, and the surrounding code knows the matrix implementation. That is, an algorithm for sequential matrices is carefully coded around this fact, and so how it uses a diagonal will also have this profile. So, static utility method and "you know the problem space" are the two uses for this? I go on about this because I tried to make a generic read-only Matrix and Vector, and then random sub-classes of those. This exercise showed the design tensions so I'm now wary of adding more features which subclasses must consider.
          Hide
          Lance Norskog added a comment -

          While you've got the scissors out, I would reconsider clone().

          • clone() requires every subclass to implement its own version
            • The "which class do I use for the clone()" problem is handled better by like().
          Show
          Lance Norskog added a comment - While you've got the scissors out, I would reconsider clone(). clone() requires every subclass to implement its own version The "which class do I use for the clone()" problem is handled better by like().
          Hide
          Lance Norskog added a comment -

          addTo v.s. apply(Functions.PLUS)

          If performance is really a problem, the apply implementation can do instanceof, but keep the interface clean.

          Show
          Lance Norskog added a comment - addTo v.s. apply(Functions.PLUS) If performance is really a problem, the apply implementation can do instanceof, but keep the interface clean.
          Hide
          Ted Dunning added a comment -

          The diagonal support consists of a viewDiagonal method on Matrix on the one hand and a DiagonalMatrix implementation on the other. As the name suggests viewDiagonal is a view method so it would be bad to make it read-only. It does make certain operations like computing the determinant very simple:

            determinant = new CholeskyDecomposition(matrix).viewDiagonal().aggregate(Functions.TIMES)
          

          or setting the diagonal of a matrix to all zeros:

           
             m.viewDiagonal().assign(0)
          

          The diagonal matrix is handy when reconstructing SVD's. You get this:

             u.times(new DiagonalMatrix(singularValues)).times(v.transpose())
          

          Since the DiagonalMatrix is marked as sparse, efficiency is good.

          Show
          Ted Dunning added a comment - The diagonal support consists of a viewDiagonal method on Matrix on the one hand and a DiagonalMatrix implementation on the other. As the name suggests viewDiagonal is a view method so it would be bad to make it read-only. It does make certain operations like computing the determinant very simple: determinant = new CholeskyDecomposition(matrix).viewDiagonal().aggregate(Functions.TIMES) or setting the diagonal of a matrix to all zeros: m.viewDiagonal().assign(0) The diagonal matrix is handy when reconstructing SVD's. You get this: u.times( new DiagonalMatrix(singularValues)).times(v.transpose()) Since the DiagonalMatrix is marked as sparse, efficiency is good.
          Hide
          Ted Dunning added a comment -

          yeah, I hate our use of clone as well. But I am not going to change it on this pass. I have already touched 80 files with > 200 changes. That will be enough to commit cleanly.

          Show
          Ted Dunning added a comment - yeah, I hate our use of clone as well. But I am not going to change it on this pass. I have already touched 80 files with > 200 changes. That will be enough to commit cleanly.
          Hide
          Sean Owen added a comment -

          On clone() vs like(): there are two logical operations we might want to support here. There's an operation that gives a separate, identical copy with all the same values. There's also an operation that gives a separate, identical copy with no data or values.

          The first should certainly be called clone(), since that's what it is, in Java.

          Lance, is your objection that we simply should not have the first operation? or that you don't want to use clone() per se for some reason?
          I don't see that either of these two has an easier time deciding what class to return, or that one or the other must or must not be implemented in subclasses. These are like any other OO method.

          I can imagine both are useful, and so would support keeping both. If someone has a good argument that one or the other really isn't used, that's good too. And certainly if we're finding they're implemented incorrectly, and I did find several instances of that in the past, we should fix it.

          Show
          Sean Owen added a comment - On clone() vs like(): there are two logical operations we might want to support here. There's an operation that gives a separate, identical copy with all the same values. There's also an operation that gives a separate, identical copy with no data or values. The first should certainly be called clone(), since that's what it is, in Java. Lance, is your objection that we simply should not have the first operation? or that you don't want to use clone() per se for some reason? I don't see that either of these two has an easier time deciding what class to return, or that one or the other must or must not be implemented in subclasses. These are like any other OO method. I can imagine both are useful, and so would support keeping both. If someone has a good argument that one or the other really isn't used, that's good too. And certainly if we're finding they're implemented incorrectly, and I did find several instances of that in the past, we should fix it.
          Hide
          Ted Dunning added a comment -

          Sean,

          We definitely need both operations. The first can be expressed, however, as a.like().assign(a) so it isn't quite as necessary as it might seem.

          The problem with clone itself is that there are serious restrictions on how you have to do it based on Java requirements. That makes it a royal pain some days of the week. This may be easier after this JIRA gets resolved since the only information at AbstractMatrix level is the number of rows and columns and they are trivial to deal with.

          We definitely also have some bugs in our test suite in that it is assumed that like() has to return the same type of object. That isn't really true. For instance, m.viewPart(0,3,2,5).like() should return the same thing that m.like() returns. But viewPart probably returns some kind of view object so these aren't the same.

          I can deal with those issues another day.

          If we can get eyes on this monster patch, I would like to commit it shortly. The only big issues I know about are:

          a) getRow and getColumn is a more common name than viewRow and viewColumn. Does everybody promise not to be confused by the loss of getRow?

          b) what should the iterator of a matrix do? Right now SparseColumnMatrix iterates over columns and everything else by rows. Unless there is some very clear way to tell what the iteration is doing, I would like to go on record as grumpy about that.

          Show
          Ted Dunning added a comment - Sean, We definitely need both operations. The first can be expressed, however, as a.like().assign(a) so it isn't quite as necessary as it might seem. The problem with clone itself is that there are serious restrictions on how you have to do it based on Java requirements. That makes it a royal pain some days of the week. This may be easier after this JIRA gets resolved since the only information at AbstractMatrix level is the number of rows and columns and they are trivial to deal with. We definitely also have some bugs in our test suite in that it is assumed that like() has to return the same type of object. That isn't really true. For instance, m.viewPart(0,3,2,5).like() should return the same thing that m.like() returns. But viewPart probably returns some kind of view object so these aren't the same. I can deal with those issues another day. If we can get eyes on this monster patch, I would like to commit it shortly. The only big issues I know about are: a) getRow and getColumn is a more common name than viewRow and viewColumn. Does everybody promise not to be confused by the loss of getRow? b) what should the iterator of a matrix do? Right now SparseColumnMatrix iterates over columns and everything else by rows. Unless there is some very clear way to tell what the iteration is doing, I would like to go on record as grumpy about that.
          Hide
          Ted Dunning added a comment -

          Github branch MAHOUT-790 available at git://github.com/tdunning/mahout.git

          That provides more details on successive changes.

          Show
          Ted Dunning added a comment - Github branch MAHOUT-790 available at git://github.com/tdunning/mahout.git That provides more details on successive changes.
          Hide
          Sean Owen added a comment -

          I know the clone() contract well – why wouldn't, as you say, like() + assign() satisfy the contract? That's why I questioned the objection that, well, every class has to implement it. I don't think so. If like() does the hard part of figuring out what class to return, this is a breeze. It would be nice to have clone() even if it can be accomplished with like() and assign() as a convenience method, to match developer expectations.

          I don't necessarily think m.like() and m.viewPart().like() return the same class. I might well expect that m and m.viewPart() are of the same class! which would make this true.

          erm, in terms of actionable changes, I think I was arguing against more change rather than for more, so proceed and we can sort it later. Don't remove clone() unless it's really painful given the road you've gone down with this patch.

          Show
          Sean Owen added a comment - I know the clone() contract well – why wouldn't, as you say, like() + assign() satisfy the contract? That's why I questioned the objection that, well, every class has to implement it. I don't think so. If like() does the hard part of figuring out what class to return, this is a breeze. It would be nice to have clone() even if it can be accomplished with like() and assign() as a convenience method, to match developer expectations. I don't necessarily think m.like() and m.viewPart().like() return the same class. I might well expect that m and m.viewPart() are of the same class! which would make this true. erm, in terms of actionable changes, I think I was arguing against more change rather than for more, so proceed and we can sort it later. Don't remove clone() unless it's really painful given the road you've gone down with this patch.
          Hide
          Ted Dunning added a comment -

          I don't necessarily think m.like() and m.viewPart().like() return the same class. I might well expect that m and m.viewPart() are of the same class! which would make this true.

          You might expect that, but you would be wrong.

          Seriously, I would expect that mostly like() should preserve isSparse, but not necessarily much else. Much better is to have like() encode the judgement of the implementor and look below any facades to the truth of the matter.

          I am not touching clone for now.

          Show
          Ted Dunning added a comment - I don't necessarily think m.like() and m.viewPart().like() return the same class. I might well expect that m and m.viewPart() are of the same class! which would make this true. You might expect that, but you would be wrong. Seriously, I would expect that mostly like() should preserve isSparse, but not necessarily much else. Much better is to have like() encode the judgement of the implementor and look below any facades to the truth of the matter. I am not touching clone for now.
          Hide
          Sean Owen added a comment -

          I may misunderstand: Do you expect m and m.viewPart() to be the same class in an ideal world or not? I don't expect that, myself, and indeed that's not the case. So all the less would I expect that m.like() and m.viewPart().like() ought to be the same class. I thought you were suggesting they ought to be.

          I agree with your last point here so I think we must be agreeing.

          Show
          Sean Owen added a comment - I may misunderstand: Do you expect m and m.viewPart() to be the same class in an ideal world or not? I don't expect that, myself, and indeed that's not the case. So all the less would I expect that m.like() and m.viewPart().like() ought to be the same class. I thought you were suggesting they ought to be. I agree with your last point here so I think we must be agreeing.
          Hide
          Dmitriy Lyubimov added a comment -

          It might help to introduce interface maturity annotations (similar to what they do in Hadoop) to indicate our opinion of still-evolving apis to the user.

          I have tons of outside code locked to the Matrix api already. I probably would've used it anyway even if it were marked as evolving. but we definitely have various levels of api maturity. So it might help to indicate it.

          Show
          Dmitriy Lyubimov added a comment - It might help to introduce interface maturity annotations (similar to what they do in Hadoop) to indicate our opinion of still-evolving apis to the user. I have tons of outside code locked to the Matrix api already. I probably would've used it anyway even if it were marked as evolving. but we definitely have various levels of api maturity. So it might help to indicate it.
          Hide
          Ted Dunning added a comment -

          Great idea. I doubt it would have helped here since I thought this interface was pretty stable.

          Maybe it would focus our minds as we add the @stable annotation.

          Show
          Ted Dunning added a comment - Great idea. I doubt it would have helped here since I thought this interface was pretty stable. Maybe it would focus our minds as we add the @stable annotation.
          Hide
          Ted Dunning added a comment -

          So Dmitriy, how badly are the changes I am pushing going to hit you?

          I am about to add a merge of numCols and columnSize as well (same for numRows).

          Show
          Ted Dunning added a comment - So Dmitriy, how badly are the changes I am pushing going to hit you? I am about to add a merge of numCols and columnSize as well (same for numRows).
          Hide
          Dmitriy Lyubimov added a comment -

          Thanks, Ted.

          I am working off a frozen snapshot in production (just built my own private release of a suitable functionality snapshot i use), so it's no immediate problem. At some point we will refactor. No problem. But it might help in other places where i have less of idea how in flux the api is.

          Show
          Dmitriy Lyubimov added a comment - Thanks, Ted. I am working off a frozen snapshot in production (just built my own private release of a suitable functionality snapshot i use), so it's no immediate problem. At some point we will refactor. No problem. But it might help in other places where i have less of idea how in flux the api is.
          Hide
          Dmitriy Lyubimov added a comment -

          the thing is, i like Mahout's DRM and Matrix apis very much and use them pervasively. I think they are cornerstone for everything else and for custom pipelining. It would be great if we could make them stable rather sooner than later

          Show
          Dmitriy Lyubimov added a comment - the thing is, i like Mahout's DRM and Matrix apis very much and use them pervasively. I think they are cornerstone for everything else and for custom pipelining. It would be great if we could make them stable rather sooner than later
          Hide
          Sebastian Schelter added a comment - - edited

          I like this idea of annotating stuff very much. Maybe it would also make sense to apply that in a broader way to highlight which implementations are mature and production-ready (like most of our recommender code) and which are rather new and experimental (like the graph mining module).

          Show
          Sebastian Schelter added a comment - - edited I like this idea of annotating stuff very much. Maybe it would also make sense to apply that in a broader way to highlight which implementations are mature and production-ready (like most of our recommender code) and which are rather new and experimental (like the graph mining module).
          Hide
          Ted Dunning added a comment -

          @Dmitriy,

          I completely agree. We need to get the basic API's rock solid as soon as possible.

          Show
          Ted Dunning added a comment - @Dmitriy, I completely agree. We need to get the basic API's rock solid as soon as possible.
          Hide
          Lance Norskog added a comment - - edited

          I don't necessarily think m.like() and m.viewPart().like() return the same class. I might well expect that m and m.viewPart() are of the same class! which would make this true.

          Ouch- that twisted my head. But it does show that perhaps viewPart should be done outside of Matrix. You pick a viewer class and give it the delegate Matrix in the constructor. If it's not linear algebra, should it be in Matrix?

          Show
          Lance Norskog added a comment - - edited I don't necessarily think m.like() and m.viewPart().like() return the same class. I might well expect that m and m.viewPart() are of the same class! which would make this true. Ouch- that twisted my head. But it does show that perhaps viewPart should be done outside of Matrix. You pick a viewer class and give it the delegate Matrix in the constructor. If it's not linear algebra, should it be in Matrix?
          Hide
          Ted Dunning added a comment -

          But it does show that perhaps viewPart should be done outside of Matrix.

          I think not. Getting a view of a submatrix or row or column or diagonal is a fundamental operation in linear algebra. The method may delegate to a view class, but to the user, it should appear as a matrix operation.

          Besides, there are are kinds of matrices and vectors where the view is the same type as the matrix. For instance, for dense matrices this is often true because the dense matrix is a one-dimensional storage array combined with an offset plus row and column strides. Any block-wise view of this keeps the same storage and has different offset and strides.

          On the other hand, sparse matrices do better with a view structure.

          In any caes, viewPart should be a method on the matrix. It should return a matrix and preserve sparsity and maybe a few related properties, but not precise type.

          Show
          Ted Dunning added a comment - But it does show that perhaps viewPart should be done outside of Matrix. I think not. Getting a view of a submatrix or row or column or diagonal is a fundamental operation in linear algebra. The method may delegate to a view class, but to the user, it should appear as a matrix operation. Besides, there are are kinds of matrices and vectors where the view is the same type as the matrix. For instance, for dense matrices this is often true because the dense matrix is a one-dimensional storage array combined with an offset plus row and column strides. Any block-wise view of this keeps the same storage and has different offset and strides. On the other hand, sparse matrices do better with a view structure. In any caes, viewPart should be a method on the matrix. It should return a matrix and preserve sparsity and maybe a few related properties, but not precise type.
          Hide
          Ted Dunning added a comment -

          OK. Just committed this.

          When you update, make sure to do [mvn install] in the math module to make sure that you get the update for the rest of Mahout (that threw me for a loop for a while).

          Show
          Ted Dunning added a comment - OK. Just committed this. When you update, make sure to do [mvn install] in the math module to make sure that you get the update for the rest of Mahout (that threw me for a loop for a while).
          Hide
          Ted Dunning added a comment -

          Checked in. We will want to make sure that Jenkins concurs that it works.

          Show
          Ted Dunning added a comment - Checked in. We will want to make sure that Jenkins concurs that it works.
          Hide
          Hudson added a comment -

          Integrated in Mahout-Quality #1012 (See https://builds.apache.org/job/Mahout-Quality/1012/)
          MAHOUT-790 - kill the cardinality array and size() for matrices. Use rowSize() and columnSize() instead.

          MAHOUT-792 - Fix RTM to avoid size() and cardinality array.
          MAHOUT-790 - More get/view changes
          MAHOUT-790 - collapse get

          {Row,Column} to view{Row,Column}

          , kill addTo
          MAHOUT-790 - Fixed copyright and license on QRDecomposition and SVDDecomposition
          MAHOUT-790 - Copyright format cleanup
          MAHOUT-790 - Matrix cleanups.
          MAHOUT-790 - Add some vector and matrix types to simplify certain manipulations.
          MAHOUT-790 - Add view for diagonal of a matrix.

          tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164016
          Files :

          • /mahout/trunk/core/src/main/java/org/apache/mahout/cf/taste/hadoop/als/eval/InMemoryFactorizationEvaluator.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/bayes/InMemoryBayesDatastore.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/discriminative/LinearTrainer.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/naivebayes/NaiveBayesModel.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/naivebayes/training/TrainUtils.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/sequencelearning/hmm/HmmUtils.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/MatrixWritable.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/decomposer/EigenVerificationJob.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/UpperTriangular.java
          • /mahout/trunk/core/src/test/java/org/apache/mahout/cf/taste/hadoop/als/ParallelALSFactorizationJobTest.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/DenseMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/DiagonalMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/Matrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/MatrixView.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/PermutedVectorView.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/PivotedMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/RandomAccessSparseVector.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/RandomTrinaryMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/SequentialAccessSparseVector.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseColumnMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseRowMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/HebbianSolver.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/AbstractTestVector.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/MatrixTest.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestMatrixView.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestSparseColumnMatrix.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestSparseMatrix.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestSparseRowMatrix.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestVectorView.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/als/AlternateLeastSquaresSolverTest.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/decomposer/SolverTest.java

          tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164015
          Files :

          • /mahout/trunk/core/src/main/java/org/apache/mahout/clustering/lda/LDAInference.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/DiagonalMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/PivotedMatrix.java

          tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164014
          Files :

          • /mahout/trunk/core/src/main/java/org/apache/mahout/cf/taste/hadoop/als/eval/InMemoryFactorizationEvaluator.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/AbstractVectorClassifier.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/discriminative/LinearTrainer.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/naivebayes/NaiveBayesModel.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/naivebayes/training/WeightsMapper.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/sgd/AbstractOnlineLogisticRegression.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/sgd/GradientMachine.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/sgd/PassiveAggressive.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/clustering/AbstractCluster.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/clustering/RunningSumsGaussianAccumulator.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/common/mapreduce/VectorSumReducer.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/MatrixMultiplicationJob.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/TimesSquaredJob.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/GivensThinSolver.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/SSVDPrototype.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/UJob.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/UpperTriangular.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/VJob.java
          • /mahout/trunk/core/src/main/java/org/apache/mahout/vectorizer/common/PartialVectorMergeReducer.java
          • /mahout/trunk/core/src/test/java/org/apache/mahout/cf/taste/hadoop/als/ParallelALSFactorizationJobTest.java
          • /mahout/trunk/core/src/test/java/org/apache/mahout/classifier/discriminative/PerceptronTrainerTest.java
          • /mahout/trunk/core/src/test/java/org/apache/mahout/classifier/discriminative/WinnowTrainerTest.java
          • /mahout/trunk/core/src/test/java/org/apache/mahout/classifier/sgd/OnlineBaseTest.java
          • /mahout/trunk/core/src/test/java/org/apache/mahout/clustering/TestGaussianAccumulators.java
          • /mahout/trunk/core/src/test/java/org/apache/mahout/math/hadoop/decomposer/TestDistributedLanczosSolverCLI.java
          • /mahout/trunk/core/src/test/java/org/apache/mahout/math/hadoop/stochasticsvd/SSVDPrototypeTest.java
          • /mahout/trunk/examples/src/main/java/org/apache/mahout/clustering/display/DisplayMeanShift.java
          • /mahout/trunk/integration/src/test/java/org/apache/mahout/clustering/TestClusterDumper.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractVector.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/Algebra.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/DenseMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/DenseVector.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/Matrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/MatrixVectorView.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/MatrixView.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/NamedVector.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/RandomAccessSparseVector.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseColumnMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseRowMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/Vector.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/VectorView.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/als/AlternateLeastSquaresSolver.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/HebbianSolver.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/TrainingState.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/MatrixTest.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestMatrixView.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/VectorTest.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/decomposer/SolverTest.java

          tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164013
          Files :

          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/QRDecomposition.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/SingularValueDecomposition.java

          tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164012
          Files :

          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestSingularValueDecomposition.java

          tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164011
          Files :

          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/MatrixTest.java

          tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164010
          Files :

          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/ConstantVector.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/DiagonalMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/PermutedVectorView.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/PivotedMatrix.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/PermutedVectorViewTest.java
          • /mahout/trunk/math/src/test/java/org/apache/mahout/math/PivotedMatrixTest.java

          tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164009
          Files :

          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractMatrix.java
          • /mahout/trunk/math/src/main/java/org/apache/mahout/math/Matrix.java
          Show
          Hudson added a comment - Integrated in Mahout-Quality #1012 (See https://builds.apache.org/job/Mahout-Quality/1012/ ) MAHOUT-790 - kill the cardinality array and size() for matrices. Use rowSize() and columnSize() instead. MAHOUT-792 - Fix RTM to avoid size() and cardinality array. MAHOUT-790 - More get/view changes MAHOUT-790 - collapse get {Row,Column} to view{Row,Column} , kill addTo MAHOUT-790 - Fixed copyright and license on QRDecomposition and SVDDecomposition MAHOUT-790 - Copyright format cleanup MAHOUT-790 - Matrix cleanups. MAHOUT-790 - Add some vector and matrix types to simplify certain manipulations. MAHOUT-790 - Add view for diagonal of a matrix. tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164016 Files : /mahout/trunk/core/src/main/java/org/apache/mahout/cf/taste/hadoop/als/eval/InMemoryFactorizationEvaluator.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/bayes/InMemoryBayesDatastore.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/discriminative/LinearTrainer.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/naivebayes/NaiveBayesModel.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/naivebayes/training/TrainUtils.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/sequencelearning/hmm/HmmUtils.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/MatrixWritable.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/decomposer/EigenVerificationJob.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/UpperTriangular.java /mahout/trunk/core/src/test/java/org/apache/mahout/cf/taste/hadoop/als/ParallelALSFactorizationJobTest.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/DenseMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/DiagonalMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/Matrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/MatrixView.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/PermutedVectorView.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/PivotedMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/RandomAccessSparseVector.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/RandomTrinaryMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/SequentialAccessSparseVector.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseColumnMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseRowMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/HebbianSolver.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/AbstractTestVector.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/MatrixTest.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestMatrixView.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestSparseColumnMatrix.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestSparseMatrix.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestSparseRowMatrix.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestVectorView.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/als/AlternateLeastSquaresSolverTest.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/decomposer/SolverTest.java tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164015 Files : /mahout/trunk/core/src/main/java/org/apache/mahout/clustering/lda/LDAInference.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/DiagonalMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/PivotedMatrix.java tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164014 Files : /mahout/trunk/core/src/main/java/org/apache/mahout/cf/taste/hadoop/als/eval/InMemoryFactorizationEvaluator.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/AbstractVectorClassifier.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/discriminative/LinearTrainer.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/naivebayes/NaiveBayesModel.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/naivebayes/training/WeightsMapper.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/sgd/AbstractOnlineLogisticRegression.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/sgd/GradientMachine.java /mahout/trunk/core/src/main/java/org/apache/mahout/classifier/sgd/PassiveAggressive.java /mahout/trunk/core/src/main/java/org/apache/mahout/clustering/AbstractCluster.java /mahout/trunk/core/src/main/java/org/apache/mahout/clustering/RunningSumsGaussianAccumulator.java /mahout/trunk/core/src/main/java/org/apache/mahout/common/mapreduce/VectorSumReducer.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/MatrixMultiplicationJob.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/TimesSquaredJob.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/GivensThinSolver.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/SSVDPrototype.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/UJob.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/UpperTriangular.java /mahout/trunk/core/src/main/java/org/apache/mahout/math/hadoop/stochasticsvd/VJob.java /mahout/trunk/core/src/main/java/org/apache/mahout/vectorizer/common/PartialVectorMergeReducer.java /mahout/trunk/core/src/test/java/org/apache/mahout/cf/taste/hadoop/als/ParallelALSFactorizationJobTest.java /mahout/trunk/core/src/test/java/org/apache/mahout/classifier/discriminative/PerceptronTrainerTest.java /mahout/trunk/core/src/test/java/org/apache/mahout/classifier/discriminative/WinnowTrainerTest.java /mahout/trunk/core/src/test/java/org/apache/mahout/classifier/sgd/OnlineBaseTest.java /mahout/trunk/core/src/test/java/org/apache/mahout/clustering/TestGaussianAccumulators.java /mahout/trunk/core/src/test/java/org/apache/mahout/math/hadoop/decomposer/TestDistributedLanczosSolverCLI.java /mahout/trunk/core/src/test/java/org/apache/mahout/math/hadoop/stochasticsvd/SSVDPrototypeTest.java /mahout/trunk/examples/src/main/java/org/apache/mahout/clustering/display/DisplayMeanShift.java /mahout/trunk/integration/src/test/java/org/apache/mahout/clustering/TestClusterDumper.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractVector.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/Algebra.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/DenseMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/DenseVector.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/Matrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/MatrixVectorView.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/MatrixView.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/NamedVector.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/RandomAccessSparseVector.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseColumnMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/SparseRowMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/Vector.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/VectorView.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/als/AlternateLeastSquaresSolver.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/HebbianSolver.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/TrainingState.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/MatrixTest.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestMatrixView.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/VectorTest.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/decomposer/SolverTest.java tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164013 Files : /mahout/trunk/math/src/main/java/org/apache/mahout/math/QRDecomposition.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/SingularValueDecomposition.java tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164012 Files : /mahout/trunk/math/src/test/java/org/apache/mahout/math/TestSingularValueDecomposition.java tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164011 Files : /mahout/trunk/math/src/test/java/org/apache/mahout/math/MatrixTest.java tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164010 Files : /mahout/trunk/math/src/main/java/org/apache/mahout/math/ConstantVector.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/DiagonalMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/PermutedVectorView.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/PivotedMatrix.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/PermutedVectorViewTest.java /mahout/trunk/math/src/test/java/org/apache/mahout/math/PivotedMatrixTest.java tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1164009 Files : /mahout/trunk/math/src/main/java/org/apache/mahout/math/AbstractMatrix.java /mahout/trunk/math/src/main/java/org/apache/mahout/math/Matrix.java
          Hide
          Dmitriy Lyubimov added a comment -

          Hm. i can't seem to make trunk to build.

          building math produces

          Results :

          Failed tests:
          testIterate(org.apache.mahout.math.TestSparseColumnMatrix): iterator:

          {0:1.1,1:2.2}

          , randomAccess:

          {2:5.5,1:3.3,0:1.1}

          expected:<

          {0:1.1,1:2.2}

          > but was:<

          {2:5.5,1:3.3,0:1.1}

          >

          Show
          Dmitriy Lyubimov added a comment - Hm. i can't seem to make trunk to build. building math produces Results : Failed tests: testIterate(org.apache.mahout.math.TestSparseColumnMatrix): iterator: {0:1.1,1:2.2} , randomAccess: {2:5.5,1:3.3,0:1.1} expected:< {0:1.1,1:2.2} > but was:< {2:5.5,1:3.3,0:1.1} >
          Hide
          Ted Dunning added a comment -

          Hmph... that test should have been commented out.

          Let me take a look. My final merges may not have been quite right.

          Show
          Ted Dunning added a comment - Hmph... that test should have been commented out. Let me take a look. My final merges may not have been quite right.
          Hide
          Ted Dunning added a comment -

          Definitely due to last minute regression. My local history shows that this
          changed right as I checked stuff in.

          Show
          Ted Dunning added a comment - Definitely due to last minute regression. My local history shows that this changed right as I checked stuff in.
          Hide
          Ted Dunning added a comment -

          Lost a change. Re-opening to commit the fix.

          Show
          Ted Dunning added a comment - Lost a change. Re-opening to commit the fix.
          Hide
          Ted Dunning added a comment -

          Really fixed now.

          Show
          Ted Dunning added a comment - Really fixed now.
          Hide
          Ted Dunning added a comment -

          Found the missing commit. It had other changes as well.

          Applied them. Should be fixed (finally)

          Show
          Ted Dunning added a comment - Found the missing commit. It had other changes as well. Applied them. Should be fixed (finally)
          Hide
          Lance Norskog added a comment -

          What should happen to labels in PivotedMatrix.java? Should they point to the row number as they do now? Should they track the movements of rows & columns?

          Show
          Lance Norskog added a comment - What should happen to labels in PivotedMatrix.java? Should they point to the row number as they do now? Should they track the movements of rows & columns?
          Hide
          Lance Norskog added a comment -

          Inverting a diagonal matrix is 1/the values in the diagonal. This is trivial if all the diagonals are non-zero, but impossible if any are 0. Should DiagonalMatrix track whether any values are 0?

          Show
          Lance Norskog added a comment - Inverting a diagonal matrix is 1/the values in the diagonal. This is trivial if all the diagonals are non-zero, but impossible if any are 0. Should DiagonalMatrix track whether any values are 0?
          Hide
          Ted Dunning added a comment -

          Lance,

          Ideally labels should follow the rows and/or columns as the matrix pivots. Since the pivoted matrix is just a view, this should be easy to make happen. It probably doesn't happen correctly now.

          Yes, the inverse of a non-zero diagonal is easy. Commonly a diagonal matrix with zeros is truncated before inverting. The definition of zero is an application specific thing and thus should not be included in the DM itself.

          Show
          Ted Dunning added a comment - Lance, Ideally labels should follow the rows and/or columns as the matrix pivots. Since the pivoted matrix is just a view, this should be easy to make happen. It probably doesn't happen correctly now. Yes, the inverse of a non-zero diagonal is easy. Commonly a diagonal matrix with zeros is truncated before inverting. The definition of zero is an application specific thing and thus should not be included in the DM itself.
          Hide
          Lance Norskog added a comment -

          Ideally labels should follow the rows and/or columns as the matrix pivots. Since the pivoted matrix is just a view, this should be easy to make happen. It probably doesn't happen correctly now.

          Matrix row&column labels are string->index maps. If you write code that knows it has a permuted matrix, it can pull the labels and the permutation lists and do the indirection. If it does not know it has a permuted matrix, it will get non-tracking outputs.

          Show
          Lance Norskog added a comment - Ideally labels should follow the rows and/or columns as the matrix pivots. Since the pivoted matrix is just a view, this should be easy to make happen. It probably doesn't happen correctly now. Matrix row&column labels are string->index maps. If you write code that knows it has a permuted matrix, it can pull the labels and the permutation lists and do the indirection. If it does not know it has a permuted matrix, it will get non-tracking outputs.
          Hide
          Sean Owen added a comment -

          Ted looks like you are done with this one?

          Show
          Sean Owen added a comment - Ted looks like you are done with this one?

            People

            • Assignee:
              Ted Dunning
              Reporter:
              Ted Dunning
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development