I don't believe this is a bug.

There are three versions of neighborhood functions for some neighborhood type Foo:

1. getFooLocations(...) fills out IntBags for xPos and yPos for coordinates of all locations in the neighborhood.

2. getFooNeighbors(...) fills out a result bag for all non-null objects located in the neighborhood.  It incidentally ALSO fills out IntBags for xPos and yPos for coordinates of all locations in the neighborhood regardless of whether objects are located there, but that's just a side effect..

3. getFooNeighborsAndLocations(...) fills out a result bag for all non-null objects located in the neighborhood, AND IntBags for the xPos and yPos coordinates of those objects.

I agree that #2 is confusing because of its option to pass in xPos and yPos IntBags which aren't intended to be ultimately used (it's for reuse).  But it's not incorrect.  I did notice that there are some errors in the documentation which can make it confusing; I'll fix those.

One thing we could do is make a version of #2 where you do NOT pass in IntBags -- you ONLY have the result bag filled out, which would make the intent of #2 more clear.

Sean


On Jan 23, 2015, at 7:31 AM, Christian Meyer <[log in to unmask]> wrote:

> Hello,
> 
> I stumbled over an issue in ObjectGrid not adding null values to results 
> of neighborhood lookups. Locations for these values were added before 
> and this leads bags with different sizes. If a non-null value is 
> encountered after a null, the index pointing to the object within the 
> results bag will point to a different location in the xPos and yPos bags.
> 
> Best regards,
> Christian