Konrad, Thanks for hashing this through with me. I thought about it for a while and I think you're right. When I start working on this project again, I'm going to implement it so that index order is consistent across all operations.
-Adler On May 27, 12:11 pm, Konrad Hinsen <konrad.hin...@laposte.net> wrote: > On May 27, 2009, at 1:03, aperotte wrote: > > > I think I understand your point now. You would like the indexing to > > match the implicit dimension order of the nested structure. > > Right. > > > 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. > > Both handle only 1D and 2D arrays, so they look rather limited. But > compatibility for those is of course a nice feature to have. > > > 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. > > True, but as you say this is ultimately a feature of the backing > array, not of the client interface to the N-D array. > > > My main reasoning for doing things this way is so that dimension > > numbers are stable through data structure building. > > They are always stable at one end and not on the other. To me it > doesn't really matter which end gets to be variable. > > > I was considering the slices of the outer-most dimension of the nested > > array (or the right-most dimension of thematrix) 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. > > That's certainly a nice operation to have, but I wouldn't call it > conj, because conj takes a collection and an element, whereas what > you describe is the combination of two elements into a new collection. > > One way to create a higher-dimensional collection would be to first > add a new dimension to the future elements (this is a low-cost > operation, as only the shape information is updated), and then use > concat or an n-d generalization of it. > > > 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. > > Right. > > > 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? > > Let's say my priorities are different: I consider it more important > to have consistent index order across all operations, and I don't > attach much importance to which end of the shape array remains stable > when higher-dimensional structures are built. > > 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 Note that posts from new members are moderated - please be patient with your first post. 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 -~----------~----~----~----~------~----~------~--~---
