Hi Konrad, I think I understand your point now. You would like the indexing to match the implicit dimension order of the nested structure.
I was also concerned about storage order because I wanted to at some point integrate this datastructure with colt or parallel colt and the incanter library. It stores matrices in column major order. Also, I thought that column vs row major order did have something to do with both storage order and indexing. I thought the idea was that if while stepping through the backing array the right-most index varied fastest you were in column-major and if the left-most index varied fastest you were in row-major. > If I understand your reasoning correctly, your primary criterion is > that the flattened array should have the elements in the same order > as a flattened version of the nested vectors, which for column-major > ordering leads to indices being reversed compared to the nested > vectors. My main reasoning for doing things this way is so that dimension numbers are stable through data structure building. > I wouldn't know how to define conj in this case, given that for other > collections it adds an element to a collection. But what is an > "element" for a multidimensional structure? > I was considering the slices of the outer-most dimension of the nested array (or the right-most dimension of the matrix) to be the "elements" of the collection when dealing with it in a lispy way. If I start with a 2 dimensional structure with elements in the 0 and 1 dimensions, and I conj it with another 2 dimensional structure, I would not like to see the two structures juxtaposed along a new 0 dimension. I would rather they maintain their original dimensions and be juxtaposed along a new dimension, 2. The two ways of doing this that we're describing are very similar. I think in what you're describing, the outermost layer of the nested structure that goes into the constructor becomes the left-most index and nth operates on that index. In what I'm describing, the outermost layer becomes the right-most index and nth operates on that index. The sole reason for this is to maintain stable dimension numbers when indexing, but since nth operates on the last dimension it maintains the same semantics as what your describing (as well as the same semantics as vectors). I admit it might be a bit confusing to have nth operate in the opposite direction as index, but I think keeping stable dimension numbers is a worthwhile reason. Do you disagree? -Adler --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
