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 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. 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 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 -~----------~----~----~----~------~----~------~--~---
