"Useless" covers a lot of ground. I would say that in the domain of image processing f&> x <;._3 y and "useless" are different sets, nor is the former a subset of the latter.
----- Original Message ----- From: Henry Rich <[EMAIL PROTECTED]> Date: Tuesday, July 29, 2008 14:16 Subject: RE: [Jprogramming] Memory inefficiency in ;.3 ? To: 'Programming forum' <[email protected]> > 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
