On Nov 17, 2007 11:43 PM, Raul Miller <[EMAIL PROTECTED]> wrote: > F=: (nsum, nmin, cresult f. >. nsum-nmin)/@,&0
Nice trick :) But what if I needed accumulator to be of some different, non numeric, type? Or, say, the same example but let's make initial value equal to "1 2 3"? :) Besides, it still runs too slow in comparison to pure Insert case. And even slower than my foldr version: in=:[EMAIL PROTECTED] 0 0 0 (((],~[>.-~/@:])`(<.,])`(+/))/@:,~) foldr in 2087264 _55681 1760334 F in 1760334 _55681 2087264 6!:2 '0 0 0 (((],~[>.-~/@:])`(<.,])`(+/))/@:,~) foldr in' 0.646621 6!:2 'F in' 1.56227 mcs=:>./@:(-<./\)@:(0:,+/\) 6!:2 'mcs in' 0.00530626 And although F does consumes less memory than mcs while operating on memory mapped file (see my older post here: http://www.jsoftware.com/pipermail/programming/2007-October/008606.html) anyway there is linear dependency (and I am not sure why) between the size of the file and the size of the memory shown in 7!:2 execution (for example there is no similar dependency in simple +/ execution) but apart from it your F is much better in terms of memory consuming than mcs (in exact 3 times, by the way ). Unfortunately it still does not solve my problem with large files (as normal Hakell-like foldr solution should have). But thank you for your post, for interesting trick! :) ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
