From kevin.hendricks at sympatico.ca  Sat Jul 29 06:32:21 2006
From: kevin.hendricks at sympatico.ca (Kevin B. Hendricks)
Date: Sat, 29 Jul 2006 00:32:21 -0400
Subject: [Rd] Any interest in "merge" and "by" implementations
	specifically for sorted data?
In-Reply-To: <Pine.GSO.4.56.0607281725120.28145@durian.statsci.com>
References: <Pine.GSO.4.31.0607280805550.24504-100000@markov.stats>
	<FFDE23C5-EA11-4E16-B372-012DB00BD589@sympatico.ca>
	<971536df0607281112j43c4ffc0s96d3b4743b93b690@mail.gmail.com>
	<D5EA9DD0-BFC7-45A6-A541-65E8A9E8192C@sympatico.ca>
	<Pine.GSO.4.56.0607281229290.28145@durian.statsci.com>
	<5A40DD7D-3BF4-4451-AC91-9B121BE9901F@sympatico.ca>
	<Pine.GSO.4.56.0607281725120.28145@durian.statsci.com>
Message-ID: <AAC5E1FB-71BB-46C8-9D51-A72DD25C735E@sympatico.ca>

Hi Bill,

>>>    sum : igroupSums

Okay, after thinking about this ...

# assumes i is the small integer factor with n levels
# v is some long vector
# no sorting required

igroupSums <- function(v,i) {
   sums <- rep(0,max(i))
   for (j in 1:length(v)) {
       sums[[i[[j]]]] <- sums[[i[[j]]]] + v[[j]]
   }
   sums
}

if written in fortran or c might be faster than using split.  It is  
at least just linear in time with the length of vector v.  This  
approach could be easily made parallel to t threads simply by picking  
t starting points someplace along v and running this routine in  
parallel on each piece.  You could even do it without thread locking  
if "sums" elements can be accessed atomically or by creating multiple  
copies of "sums" (one for each piece) and then doing a final addition.

I still think I am missing some obvious way to do this but ...

Am I thinking along the right lines?

Kevin



[Rd] Any interest in "merge" and "by" implementations specifically for sorted data?
Kevin B. Hendricks