So I am committing a new version of MASON with additional simplified versions of these functions, so you do not need to pass in any of the IntBags or Bags.  These functions are likely the best choice for you. Thus instead of saying (for example)

	getMooreNeighbors(x, y, distance, mode, includeOrigin, resultBag, xBag, yBag)

you'd just say

	getMooreNeighbors(x, y, distance, mode, includeOrigin)

I hope this is helpful.  This excercise also kicked up one or two bugs which I've fixed as well.

Sean

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

> Yeah, I understand. If you call ...NeighborsAndLocations the null values 
> will be removed from the xPos and yPos bags in reduceObjectsAtLocations. 
> Missed that one.
> 
> Thank you very much for making this clear.
> 
> Best regards,
> Christian
> 
> On 23.01.2015 15:00, Sean Luke wrote:
>> 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