But then again ... Thinking this over, one idea that comes to mind:
What if we created a structmap (a sort of class), where we have a flattened out one-dimensional clojure vector containing all the data of our potentially multidimensional (rank n) array, together with its dimensions and possibly other info? I believe the C scienitific library, GSL, does something similar (with structs of course), even though C (especially C99) has pretty good support for multidimensional arrays per se. I think such an approach could be more flexible. You can have the vector as a data pool, and the rest would be sort of like a view on that data (which can be changed at runtime if one chooses to). For instance, a 5 x 3 x 2 array could also be a simple 5 x 6 matrix or just a 30 element vector. You can access that info at runtime, like the current size, rank, and dimensions of the array, and build a whole set of multimethods to manage this data structure. This way, we can have the power of Clojure vectors and the flexibility all wrapped up in one coherent package. What do you think? Rock On Oct 26, 7:32 pm, liebke <lie...@gmail.com> wrote: > I agree, use Clojure vectors whenever it's feasible. Even within > Incanter, which uses Parallel Colt extensively, I try never to convert > Clojure vectors into Colt vectors/matrices unless it's absolutely > necessary. > > David > > On Oct 26, 2:23 pm, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: > > > On 26 Oct 2009, at 17:14, Rock wrote: > > > > Just one more thing. It's still not really clear to me if I am better > > > off using Java arrays (make-array ...) or clojure vectors especially > > > when dealing with multidimensional arrays. I know that if use Java > > > libraries such as Colt, I have no choice. But in general? What do you > > > think? > > > Using Clojure's built-in data structures is almost always the best > > choice until you have a good reason to use something else. In the case > > of arrays, that good reason is likely to be > > 1) memory usage, once your data sets become big, > > 2) performance, either because of the size of the data sets or because > > some algorithm needs very frequent access > > 3) interoperability with Java libraries such as Colt. > > > As long as you work with small enough datasets, stick to Clojure > > vectors. > > > 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 -~----------~----~----~----~------~----~------~--~---
