On Fri, 2009-02-20 at 20:59 -0800, B. Bogart wrote:
> 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.
what is not elegant about dynamic patching? i find the concept of
dynamic patching actually quite elegant (and i am using for exactly this
kind of problems), but the not elegant part is the fact, that it is not
officially supported yet.
> Has anyone worked on something like a multi-table or nested table?
you might want to try gridflow. there you can have 'tables' with n
dimensions. iirc, this approach would you save some memory, since
gridflow lets you set the number type.
> 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].
i think, this is the least favorable approach. you might trigger some
problems with floating point precision, depending on your table size.
also i haven't found a fast way to transfer a section of a table into a
list.
> 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:
>
> tables of floats (done), tables of symbols, and most importantly tables
> of tables!
yeah, and native nested lists support ('native' != 'implementing it with
some whacky delimiter symbol or prepended number of elements')
roman
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
http://mail.yahoo.de
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
