Re: [PD] Best way to deal with many tables. - Roman Haefeli - at.iem.pd-list

11 messages in at.iem.pd-listRe: [PD] Best way to deal with many t...

From	Sent On	Attachments
B. Bogart	Feb 20, 2009 8:59 pm
Roman Haefeli	Feb 21, 2009 1:59 am
cyrille henry	Feb 21, 2009 2:51 am
David Doukhan	Feb 21, 2009 4:32 am
B. Bogart	Feb 21, 2009 9:52 am
cyrille henry	Feb 21, 2009 12:48 pm
Mathieu Bouchard	Feb 21, 2009 3:36 pm
Jonathan Wilkes	Feb 21, 2009 6:03 pm
David Doukhan	Feb 22, 2009 5:00 am
marius schebella	Feb 22, 2009 2:05 pm
cyrille henry	Feb 22, 2009 4:50 pm

Subject:	Re: [PD] Best way to deal with many tables.
From:	Roman Haefeli (redu...@yahoo.de)
Date:	Feb 21, 2009 1:59:09 am
List:	at.iem.pd-list

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

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets