Skip to main content
Best answer by Werner_E

Even shorter and faster and most important - not memory hungry anymore!

Not that I would fully understand whats going on, but representing the picture as a simple matrix rather than as a nested vector of three matrices seems to do the job. Memory usage stays nearly constant throughout.

You don't habe to put the calculating expression in the picture place holder as I did - you might as well assign it to a variable.

I guess that your original sheet would perform nearly as well if you just change the data structure of the picture to a simple matrix.

Any explanation for that effect would be welcome.

At least you now can make animation using larger picture like here http://communities.ptc.com/videos/5467 (made from the attached sheet LizT_WE_5) and/or use more frames - whatever your intention is.

6 replies

S
StuartBruff23-Emerald V
23-Emerald V
November 12, 2014

Looks interesting, Valery! Unfortunately, I've just opened it and I'm just about to go home, so can't play with it. However, it looks like you may be able to speed up some of the operations by making use of the default array initialization. For example, in (X Y) and M1, initialize Mb and the nMx arrays by setting their 'last' elements to zero, and add 255 to each nMx array.

I might have a play tomorrow when I get access to Mathcad again.

Stuart

W
Werner_E25-Diamond I
25-Diamond I
November 12, 2014

Mathcad had a very bad garbage collection, so we ever so often run into memory problems.

Here is a worksheet which saves a little bit of memory but in no way satisfactory enough.

When I watch the memory consumption in the task manager, noth sheets start at approximately 71000K and at the end of the animaton (0..199) your sheet will use up approx. 544000K and mine still 385000K. So its not the desired big step foreward, I guess.

W
Werner_E25-Diamond I
25-Diamond I
November 12, 2014

Here is yet another different approach but still no significant improvement over my first one.

BTW, in my last sheet I thought that avoiding the creation of a worksheet variable would make for a better memeroy usage, but I gave Stuarts sheet a try and it uses up pretty much the same amount of memory than mine. So it seems to be the default array initialization which accounts for the slight improvement.

W
Werner_E25-Diamond I
25-Diamond I
November 13, 2014

So here is very short and faster approach, but only a very tiny bettering (if any) and no significant success concerning memory usage.

W
Werner_E25-Diamond IAnswer
25-Diamond I
November 13, 2014

Even shorter and faster and most important - not memory hungry anymore!

Not that I would fully understand whats going on, but representing the picture as a simple matrix rather than as a nested vector of three matrices seems to do the job. Memory usage stays nearly constant throughout.

You don't habe to put the calculating expression in the picture place holder as I did - you might as well assign it to a variable.

I guess that your original sheet would perform nearly as well if you just change the data structure of the picture to a simple matrix.

Any explanation for that effect would be welcome.

At least you now can make animation using larger picture like here http://communities.ptc.com/videos/5467 (made from the attached sheet LizT_WE_5) and/or use more frames - whatever your intention is.

S
StuartBruff23-Emerald V
23-Emerald V
November 13, 2014

You can squeeze a few more milliseconds out of the process by changing the way the 'selection' matrix R is generated. Surprisingly, generating all the possible row-column indices and randomly sorting them is quicker than waiting for the while loop to find a 'vacant' pixel. If one is prepared to sacrifice a degree of granularity, then it's quicker again to generate a normalized random vector and reshape it.

I haven't checked to see how it affects memory usage.

Stuart

PS. The problem you were having with invalid indices is probably caused by rnd returning 0, which will make ceil(rnd(x)) = 0.

W
Werner_E25-Diamond I
25-Diamond I
November 13, 2014

StuartBruff wrote:

You can squeeze a few more milliseconds out of the process by changing the way the 'selection' matrix R is generated. Surprisingly, generating all the possible row-column indices and randomly sorting them is quicker than waiting for the while loop to find a 'vacant' pixel.

Yes, the creation of R can be optimized - unfortunetely(?) its only called once and not everytime in the process of creating an animation. I like you method 2 of random sorting the indices. Its not tha tbig a surprise for me that its more efficient. After all the original routine may, if we have really bad luck, run endless. Probabiity that this will happen is very low but not zero. But even if the routine finishes it will have made a large number of unnecessary random number creations and assignments which obviousy can easily be beaten by your random sorting.

Your third method sure does not guarantee that the some number of points in the pic get visible for every frame, but I guess given the number of total points in the pic this will not be noticed and thanks to reshape the routine is captivatingly simple and elegant.

I haven't checked to see how it affects memory usage.

I haven't checked either, but I see no reason why it shold effect memory usage during animation.

PS. The problem you were having with invalid indices is probably caused by rnd returning 0, which will make ceil(rnd(x)) = 0.

Thanks for pointing that out. Sure! We have 0<=rnd(c)<c so eventually once in a while we would get 0. So using trunc(rnd(c))+1 is the way to go.

Werner

V
24-Ruby IV
ValeryOchkov24-Ruby IVAuthor
24-Ruby IV
September 2, 2017

MM-Color.gif

Terms & ConditionsCookie settingsAccessibility statement