> I didn't address such issues because there is no point in discussing > them before making the fundamental decision whether to use an abstract > or an exposed data type for array data. That choice dictates the > priorities for everything that follows.
Yes, I agree. > > 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? > > If you can assume the array is well-formed, it is rather easy. > Otherwise it isn't. Can you give an example in code? I really would like to see it. > > 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? > > That's a rather simple recursive function. The only problem is its run- > time cost. Please provide an example. In the meantime, I'll give it a shot myself. > > 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? > > If I were to design an array interface for Clojure, it would consist > of multimethods implemented for both an efficient array data structure > for internal use and for nested vectors. The implementation for the > latter would convert the nested vectors to the efficient structure and > do all the necessary checks. It would be there for convenience and > clarity in user code. Ideally I would then implement the same > interface for Colt arrays and netCDF arrays as well, both for having > an effcient structure for large data sets and for interoperability. > And once we are at it, why not have another implementation for sparse > arrays, using a suitable data structure? Yes, indeed I like your design. Makes sense. > Unfortunately, a good design and implementation represents a lot of > work. At the moment I am not sure if we have the critical mass of > people interested in working on this to get the job done in a > reasonable amount of time. Well. I'm willing to contribute. We can get this started. It won't hurt to give it a try. You never know ... I feel Clojure can and actually should become a language well-suited for scientific computation. It may not have all the prerequisites now, but, hey, this is Lisp, and it can be done, always! :) > On 28 Oct 2009, at 23:07, harrison clarke wrote: > > > maps could also be an option. you can use vectors of ints as keys. > > (and you can stick dimensions and such in there with keywords) > > > i'm not sure how that compares to nested vectors for perforance. you > > have the overhead of the hash function, but you don't have any > > nesting. > > it's also pretty handy if you want to represent a sparse matrix. > > Maps could be a good choice for sparse arrays. For dense ones, they > would represent an enormous waste of memory, and probably time as well. Well sparse arrays should always be treated more specifically I suppose (no use wasting all those resources!), One thing at a time :) Rock --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
