Ted, 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 following: 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. -Greg On Fri, Aug 26, 2011 at 1:19 AM, Ted Dunning <ted.dunn...@gmail.com> 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 <phil.ste...@gmail.com> > 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. > > >
