Your analysis is crystal clear and very helpful Konrad. But you haven't addressed the issue of dealing with useful information regarding the data structure itself. What if, for example, a function wanted to know the rank and dimensions of a multidimensional array it was being passed, and that array were represented by means of a nested vector? Suppose we're dealing with rank n objects. Do you think it would be an easy task to figure all that out dealing with nested vectors? And by the way, How would you go about implementing in detail a check to see if a nested vector is actually an authentic multidimensional array or not? I personally can't come up with a simple straightforward solution. I imagine you'd have to scan each dimension one by one, and make sure the various lengths are consistent. Not a tremendously efficient perspective especially when you're dealing with huge data sets, and you're forced to perhaps redundantly check the same objects over and over during operations.
I honestly prefer your first case scenario. Seems much more efficient, less resource-consuming, and just straightforward. But I really would like to know what your preference is. If you had to choose, which way would you go? Thanks so much for your help. Rock On Oct 28, 7:54 pm, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: > On 27.10.2009, at 18:07, Rock wrote: > > > these things. Why? Because they're just that: nested vectors. They're > > not truly multidimensional vectors, and the more I think about them, > > the more they really suck from that point of view. For instance, first > > of all they're not that safe to use (for these purposes): you could > > potentially have a RAGGED nested vector, which you might end up > > passing to a function that's expecting a true multidimensional array! > > That's indeed one of the arguments against the use of multidimensional > Java arrays (which are nested arrays) for this purpose. > > > What is one to do? Implement checks all over the place just to make > > sure that it's ok? Don't like that. > > "All over the place" would be a call to a single test function. But > this need is not specific to a nested vector representation. > Basically, there are two approaches to dealing with Clojure data > structures representing multidimensional arrays: > > 1) Make them an abstract data structure. Client programs are not > supposed to know the internal representation, they create arrays > exclusively by calling factory functions provided for this purpose. > Functions that expect array arguments can then assume that the data > structure is consistent and needn't do any checks. The tightness of > the abstraction can be enforced to various degrees, but that's a > different issue. > > 2) Expose the internal representation to client code. Since any > representation in terms of standard Clojure data structures could be > invalid, all array functions need to do some check on their arguments. > > In fact, the second approach would be the best argument for the use of > nested vectors, as it is a rather simple and intuitive representation > from the user's perspective. With the first approach, the internal > representation would be chosen exlusively for the convenience of the > implementation. > > > But it gets worse. I imagine, when > > dealing with nested vectors, that there's no guarantee that the data > > will be contiguous as when you're dealing with a linear vector. So, as > > far as efficiency is concerned, maybe they're not that good, but I'm > > not sure about that (don't know the implementation details.) > > I don't think there is a difference. A Clojure vector is never a > contiguous block of storage. > > 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 -~----------~----~----~----~------~----~------~--~---
