Konrad, I did some thinking about this and I think what's there is actually what I intended for it to be. I did expect for (nth data 1) and (nth m 1) to return similar structures and that was part of the reasoning.
Numpy does things a bit differently, I think in a large part because their format is row major. Based on my understanding of the two formats, in the multidimensional generalization of row and column major the left most and the right most indices vary fastest, respectively. Therefore, if the way you construct your multidimensional array is to flatten the array then index based on one of these principles then you're either going to get a 3x2 or a 2x3 matrix, respectively, for your previous example. If you're constructing a matrix from this nested vector [[1 2] [3 4] [5 6]], then the outer-most brackets can either correspond to the left- most or the right-most indices. In Numpy, it seems that they correspond to the left-most whereas I would prefer that they correspond to the right-most. This is because it's more intuitive to me to think of building a data structure up from the outermost layer and adding either a new dimension to the right or adding 1 to the right most dimension size. For example, say that you wanted to conj the first matrix with [[7 8] [9 10] [11 12]]. I would want the resulting matrix to be a 2x3x2 matrix, which it would be in both this case and in Numpy's case, but for very different reasons. The dimensions for persistentmatrix grow to the right and Numpy's grow to the left. Or, in other words, if I conjed up another matrix [[13 14] [15 16] [17 18]], Numpy would give a 3x3x2 matrix, and persistentmatrix would give a 2x3x3. When in the frame of building up structures, I think it makes sense to keep the left-most index stable and continually representing a particular dimension (rows). Whereas in Numpy, the only way to keep the left-most index stable is to build your data structure from the "inside out". Or in other words, the indices representing 1, 2, 3, 4, 5, and 6 shift to the right in Numpy as you build up a structure with increasing amounts of nesting. In the last example with a 2x3x3 matrix, calling (nth m 2) should return the last thing that was conjed (ie. [[13 14] [15 16] [17 18]]). So to sum it up, in my current frame of thinking, the printing is backwards, but nth should return an item from the "last" or right-most dimension. -Adler On May 26, 12:31 am, Konrad Hinsen <konrad.hin...@laposte.net> wrote: > On 26.05.2009, at 00:31, aperotte wrote: > > > I don't expect to yield the same results. I would expect (.index m > > (int-array [0 1])) and (-> m (nth 1) (nth 0)) to yield the same > > results. This is because the first is equivalent to taking item 0 in > > the first dimension (always rows) and item 1 in the second dimension > > (always columns), whereas the second type of statement would say (in > > your example) take item 0 of the last dimension (columns in this case) > > and then take item 1 of next to last dimension (rows in this case). > > The documentation of nth does indeed say "last dimension", but I > thought that was just a typo... > > Given my example > > (def data [[1 2] [3 4] [5 6]]) > (def m (PersistentMatrix/create (int-array [1]) true)) > > I'd certainly expect > > (nth data 1) > > and > > (nth m 1) > > to return equivalent data structures, but that requires nth to select > along the first dimension. And that's indeed what it does at the moment. > > > On a related note, I am currently representing the matrices in column- > > major order, which is different from how C and Numpy represent > > matrices internally. Thinking about matrices in column major order > > came more naturally to me (and I think the Colt library also > > represents in column major order), but I have been thinking about > > changing it. > > Column-major order smells like Fortran... but there is nothing wrong > with it, of course. It's an arbitraray convention, just like row- > major order. Anyway, this shouldn't be visible to the user of the > Clojure interface except when reshaping an array. > > Konrad. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
