--- On Sat, 2/21/09, B. Bogart ben@ekran.org wrote:
From: B. Bogart ben@ekran.org Subject: [PD] Best way to deal with many tables. To: "PD list" pd-list@iem.at Date: Saturday, February 21, 2009, 5:59 AM Hey all.
I've managed to get my patches to use less objects, and more messages.
Problem I have now is storing data in an organized way.
Basically the system I'm working on needs to store the RGB hists of many images (10,000 ideally, RAM permitting). RGB hists are concatenated into tables of 768 elements each.
What is the best way to deal with this number of tables? There are the usual thoughts of using dynamic patching and such, but really I'd like a more elegant solution.
Has anyone worked on something like a multi-table or nested table?
I could put everything in one giant table, but each chunk needs to be a list in the end and it seems to be iterating over a section of the table to dump it as a list would be a lot slower than using [tabdump].
Just wondering if anyone has any suggestions.
I've already mentioned my wish to have a generic storage system (similar to data-structures but independent of any graphical representation) namely:
What about nesting arrays in data structures without using drawing instructions? For example, three templates, something like the following:
- rgb values [struct rgb float value]
- histogram with array of rgb values [struct histogram array values rgb]
- master-list with array of histograms [struct histograms float dummy-variable array master-list histogram]
Traversing would only happen once for [append histograms dummy-variable]. You could then get and set everything else (e.g., array sizes and rgb value) using [setsize] and [element]. And maybe use [until] with a counter to dump the rgb values of a given histogram from the master-list.
-Jonathan
tables of floats (done), tables of symbols, and most importantly tables of tables!
.b.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list