[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.


> 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