Ihat implementation is useless for image processing, then. I guess row&(col&(f;._3);._3) would be a factor-of-7 wasteful rather than a factor-of-49, so maybe that'll work on my smaller pictures.
'Twould be nice to apply u inside the loop rather than creating all the input sets first. Henry Rich > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Roger Hui > Sent: Tuesday, July 29, 2008 4:57 PM > To: Programming forum > Subject: Re: [Jprogramming] Memory inefficiency in ;.3 ? > > Judging from the following: > > y=: i.1e3 > 7!:2 '3 0:;._3 y' > 178944 > 7!:2 '0:&> 3 <;._3 y' > 179264 > > I would guess that the second expression closely > approximates how the first is implemented. > > > > ----- Original Message ----- > From: Henry Rich <[EMAIL PROTECTED]> > Date: Tuesday, July 29, 2008 13:12 > Subject: [Jprogramming] Memory inefficiency in ;.3 ? > To: 'Programming forum' <[email protected]> > > > I have a computation (details below) which boils down to > > > > x big_ugly_f;.3 y > > > > y has shape (n,m,3) and big_ugly_f returns a list of shape ,3 . > > > > Now I would expect that the memory used by big_ugly_f would be > > returned to the free pool after each use, so that the overall > > space used would be the space needed for an input subarray of > > shape ($x),((#$x)}.$y), plus a float result of > > shape (n,m,1 3), plus some smallish multiple of the space > > needed for one invocation of big_ugly_f. > > > > But it actually uses much more space than that, and I > > fail with out of memory. > > > > The details: > > > > lpfhuesize =: '7' > > cutsize =. >: <.&.-: ". lpfhuesize > > centerpix =. <2 # -: <: cutsize > > huefilt =: (2#cutsize)& > > (((1&|)@(0.5p_1&*)@(12&o.)@:(+/%#)@:,@:(2&{"1 * > > (_12&o.@:(2p1&*))@:(0&{"1)) (0}) centerpix&{);._3) > > 7!:2 'huefilt i. 50 50 3' > > 3013952 > > 7!:2 'huefilt i. 500 500 3' > > 381267520 > > > > It seems that something big is being retained for each subarray > > processed.The subarray itself is 1176 bytes, which is about the > > right size to account > > for the space used, if it isn't rounded up to a power-of-2 > > boundary; is it > > possible that the subarrays or something else are not freed > > until the operation > > completes? > > > > The behavior I expect is what I see from big_ugly_f"3 : > > > > hf =: (((1&|)@(0.5p_1&*)@(12&o.)@:(+/%#)@:,@:(2&{"1 > > * (_12&o.@:(2p1&*))@:(0&{"1)) (0}) > > centerpix&{))"3 > > arg2 =. 0.5 + i. 2 7 7 3 > > arg20 =. 0.5 + i. 20 7 7 3 > > arg200 =. 0.5 + i. 200 7 7 3 > > 7!:2 'hf arg2' > > 7616 > > 7!:2 'hf arg20' > > 8576 > > 7!:2 'hf arg200' > > 15744 > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
