On Mon, 19 Nov 2007 00:35:24 -0500, Troy Rollins wrote:
> Ken, I notice that the article, while correct, isn't actually
> representative of how arrays are *actually* used in Director.
> While constructs like "getAt(getAt(myList,2),1)" would in fact work,
> I have *never* seen anyone do that. Wh
On Nov 18, 2007, at 9:43 PM, Ken Ray wrote:
This might help as well; it was an article I wrote trying to compare
Director's arrays with Revolution's, but it gives an "inside peek" on
how Revolution sees/works with arrays:
http://www.sonsothunder.com/devres/revolution/tips/arry001.htm
Ken,
Thanks!!
On Nov 18, 2007, at 8:43 PM, Ken Ray wrote:
On Sun, 18 Nov 2007 11:31:41 -0600, Petrides, M.D. Marian wrote:
Thanks, Richard! This is very helpful.
This might help as well; it was an article I wrote trying to compare
Director's arrays with Revolution's, but it gives an "inside peek
On Sun, 18 Nov 2007 11:31:41 -0600, Petrides, M.D. Marian wrote:
> Thanks, Richard! This is very helpful.
This might help as well; it was an article I wrote trying to compare
Director's arrays with Revolution's, but it gives an "inside peek" on
how Revolution sees/works with arrays:
http://
Thanks, Richard! This is very helpful.
On Nov 18, 2007, at 11:24 AM, Richard Gaskin wrote:
Petrides, M.D. Marian wrote:
Speaking of arrays... Am I correct in understanding that Rev only
supports one dimensional arrays or am I misreading the dox?
Rev currently supports associative arrays.
Petrides, M.D. Marian wrote:
Speaking of arrays... Am I correct in understanding that Rev only
supports one dimensional arrays or am I misreading the dox?
Rev currently supports associative arrays. Unlike numerically indexed
arrays, associative array keys are not restricted to integers only,
Nice! I had expected a lot more of a memory issue. This will work
out grand :-)
I'm getting excited, doing the array this way solves some other
problems I was pondering.
Shari
I think you'd have to have a much bigger amount of data to run into
memory issues on a modern computer. Watching
I think you'd have to have a much bigger amount of data to run into
memory issues on a modern computer. Watching Activity Monitor while
the script runs, I saw only a small increase (1MB) in the amount of
active memory being used by Rev. I have 2 gigabytes on this machine,
but my past experi
In fact (note to shari), depending on your particular application,
you may find it more efficient to have an array with 300 * 1000
elements than to have an array with 300 elements of 1000 items each.
Though rev's chunk expressions are extremely efficient, accessing
the thousandth item in a list
Yes, but you can make the keys sort of multi-dimensional: someArray
[a,b,c], so for some purposes this works just as well.
In fact (note to shari), depending on your particular application,
you may find it more efficient to have an array with 300 * 1000
elements than to have an array with 30
Speaking of arrays... Am I correct in understanding that Rev only
supports one dimensional arrays or am I misreading the dox?
On Nov 17, 2007, at 7:54 PM, Mark Smith wrote:
Shari, I think this can be somewhat dependent on how much ram is
available, but in my experience, rev handles fairly la
Shari, I think this can be somewhat dependent on how much ram is
available, but in my experience, rev handles fairly large arrays very
well. I've had arrays consisting of 500 or so elements, each
containing 2000+ items without any problem. So I'd stick with the one
big array.
Best,
Mark
How big of an array have you created without noticing any reduction in speed?
I'm pondering the best way to store a large conglomerate of data, and
was hoping for a general guideline as to how humungous of an array I
could create without tripping over it.
I'm currently set up to break it into
13 matches
Mail list logo
