[PD] Best way to deal with many tables.
Jonathan Wilkes
jancsika at yahoo.com
Sun Feb 22 03:04:14 CET 2009
--- On Sat, 2/21/09, B. Bogart <ben at ekran.org> wrote:
> From: B. Bogart <ben at ekran.org>
> Subject: [PD] Best way to deal with many tables.
> To: "PD list" <pd-list at 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:
1. rgb values [struct rgb float value]
2. histogram with array of rgb values [struct histogram array values rgb]
3. 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list
mailing list