commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <>
Subject Re: [math] RealMatrix.set(double)
Date Fri, 26 Aug 2011 14:38:22 GMT

When you say

"Functions are good, but giving a tiny  bit
more information to the function is also a great idea"

do you mean information on indexing and shape of the data?

One thought I had, I am not sure if this is 100% applicable is the

1. You have two types of data (in matrix) : structured and sparse.
2. Structured data is a collection of elements that fits a certain pattern.
Some of which are
   i.) General matrix, stored rowwise
  ii.) General matrix, stored columnwise
 iii.) Diagonal matrix
 iii.) Upper/Lower triangular
 iv.) Symmetric stored in either upper triangular or lower triangular
compressed format
  v.) Banded

  The visitor should know the pattern and be given an indexer function. The
pattern designation eliminates superfluous calls to the indexer. You would
not ask for element i,j when i ne j, if the matrix is diagonal. Knowing the
pattern allows you develop highly optimized operators. This works for small
matrices as well as large (to speak to Luc's point). The implementor of
"visiting" function can use all of this info or act blindly. In the case of
the diagonal matrix, you can still ask for element i = 0 , j = 1. However,
it is stupid to do so, given you already know the matrix is diagonal.

The sparse structure is very important, but since you are unsure of how the
sparseness occurs, whether there is a pattern or not, you could make blind
calls to the indexer, or the indexer itself could be class (in this case)
which returns to you a collection of acceptable tuples ( eg, element
locations which might or might not be zero...)

In cases of very small problems, Luc's 3x3 or 6x6 matrix, it makes sense to
have subclasses of the general matrix, with rows and columns fixed to be 3
or 6, respectively.


On Fri, Aug 26, 2011 at 1:19 AM, Ted Dunning <> wrote:

> Well, in turn, I have flipped a bit on the visitor.  I just think that the
> name of the method that accepts the visitor should be the same so that
> users
> think of it as the same thing.  Functions are good, but giving a tiny  bit
> more information to the function is also a great idea.  It will still
> effectively be a visitor, but users won't have to know that is what it is.
> On Thu, Aug 25, 2011 at 10:45 PM, Phil Steitz <>
> wrote:
> > Thanks, Ted.  That does look very flexible and approachable too.  I
> > am sorry to flip-flop on this issue; but I am now thinking it might
> > actually be better to replace the visitor setup that we have with
> > something like the above, partly due to Greg's comments as well on
> > the limitations of the current code.  I encourage others to have a
> > look at the Mahout code and consider the pros and cons of
> > refactoring.  I don't think the visitor machinery is really used
> > internally, so refactoring would not be cataclysmic.  Now is the
> > time to do it if we want to go to a model based more on views and
> > the functional approach.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message